algorithmic modeling for Rhino
(Edit. David sez: Please append your (well explained) ideas/suggestions/wishes. I don't care much for what you want, I care why you want it.)
Perhaps this topic has been covered recently, but I don't see any active threads. We're looking for a plugin project and I'd like to get some feedback from the power users before choosing something.
What is missing from grasshopper?
What would you like to connect to that you can't already connect to?
What kind of bottlenecks do you run into?
What secret wish do you have for Grasshopper that doesn't even seem possible?
What project have you been meaning to undertake but haven't had/won't have the time?
Just trying to brainstorm a few ideas here. There are so many great and useful plugins out there, it's hard to discover the gaps anymore.
Looking forward to your thoughts!
I've created a plugin call elephant some time ago,
It contains a select folder component, source available https://github.com/arendvw/ExportTools/blob/master/Components/Selec...
I use clustering quite a lot, because its a handy way to reuse complex parts of a GH doc or to just clean up a bit.
But somehow I dont get how the Cluster Input works. So I mark a few nodes and cluster them. It automatically generates Cluster Inputs, which usually have weird names. Some are just letters and some are full words, which is the first thing I dont get.
Then I can double click a Cluster Input and give it a Name, Nickname and Description. Entering a name doesnt do anything. Entering a nickname changes what it says in the cluster input, but if I save and close the cluster, the input names have not changed. Description also doesnt work.
All the inputs it creates automatically cant be changed, even though the edit screen opens when double clicking them and weirdly is empty. For inputs I have created myself I can change them, but only what I FIRST enter is kept. Changing them later will leave them as they were before. That way once I change something, I can never tell where it came from if somehow i have entered something wrong. So i need to delete the input and create a new one, being careful to FIRST enter all the correct info when double clicking it and THEN connecting it to whereever I need.
I dont know if this is some weird behaviour put in there on purpose, but its really annoying. Don't protect me and make things illogical - we know what we are doing - even if it is changing an input name of cluster that might be used in multiple places already. First it can just stay connected but change the name, nickname and description. Or if its a problem, just disconnect inputs I have changed.
If I enter a Name and a Nickname, then it makes sense that the Nickname is the short version and name the long version, but even if I enter both and swith Display to "Draw full Names" it still just shows the Nickname and not the Name as one would expect.
It adds so much complexity to the task of clustering, because pretty much every time I of course want to change the input and output names, nicknames and description to something more meaningful and right now it means, deleting the ones it creates, recreating them and deleting and recreating every time i want to change a name, nickname or description. Deleting an input or output to recreate it means it gets disconnected in the parent, which adds another step. It adds complexity to something that is there to reduce it. I actually avoid clustering until it makes sense to invest time into setting up inputs and outputs, but if it was a little more clever or as one would expect I would use it much more. Take a hint from vvvv. They have subpatching, which works similar to clustering, but things just work as expected.
Maybe I am doing it wrong, but right now it just seems totally backwards!? David, why did you OK this like that?
one thing comes into my mind immediately:
- split the grasshopper window into several views (see image)
also nice would be:
- make better use of multi-core processors
- a make2d-component as already mentioned here
thanks for asking!
I realize that I'm late here, but there is another thing - will there be a chance to change the font sizes for all the Menus, Tooltips etc (for people with bad eyes or super-density monitors...)
Yes, I'll make sure that GH2 has a freely zoomable UI so that it can be used on a wide variety of screen resolutions.
When you zoom out the text and icons on the tools fade as they get very small, that's ok but could that be dependent on the text size being displayed? So that when you use a panel to display a big text, it doesn't get faded away when still readable.
Please see my latest and only post so far. I touched on the "why I want it".
I am building wheels for Saleen and I am interested in creating a "rig" in Grasshopper for fast iterations. I am curious to see if Grasshopper can be fast enough to justify the time to build rigs for this in the first place. I am currently poking blindly trying to figure out how to do this on my own.
I have made several setups to make design explorations for wheels and similar components.
Depending on what you are trying to achieve it is certainly possible to build a rig. Here are a couple of considerations:
- Since some of the advanced surfacing tools are not available in Grasshopper (Blend Surfaces, Fillet Edges, etc.), the Grasshopper definition has to be structured so that you don't need these functions - which may limit your design possibilities. Then it is almost always necessary to finalize the model "manually"
- Grasshopper is great for generating standard/modular components - like the rim bolt patterns and/or the basic wheel structure
- Using Grasshopper is also great for design explorations: if the definition is properly structured it is possible to change parameters and watch the result almost "in real-time" - for instance for deforming the spokes, etc.
- I have found some interesting results using meshes (with some custom definitions and plug-ins like Weaverbird and even T-Splines), which are generally much faster to compute. In this case you'll have a "concept model" that can make use of the SubDiv meshes, which can be transferred to MODO.
- I have played a bit with Grasshopper in combination with MODO's MeshFusion plug-in and that's another very interesting option - the only drawback is that you end up with a SubDiv model.
Some additional help in keeping definitions easy to read and neatly arranged (snap to grid for components anyone?)
Also this is quite cool, but perhaps unnecessary http://dynamobim.org/cleanup/
I think the cleanup utility might be a very powerful addition to Grasshoppper (probably a lot of users of my example files might appreciate this).
There are also some very interesting possibilities for converting other file formats (such as IFC) to grasshopper scripts.
Who else would be interested in this functionality?