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!
a few ideas, apologize if these have been covered elsewhere.
1. a trim curves components. given the SDK discussion, perhaps this will be a collection of definitions.
2. an 'encyclopedia' of definitions, a la 'wolfram'. Initially this could be a 'reference' guide, but it might also be useful if these defs were available as an online resource where the defs could simple be pasted into what you are currently working on.
3. a graphical approach to culling and list sequencing; i.e., having a visual based editor to determine culling pattern, for example use a polygon of N faces, and graphical determine which faces become culling pattern
4. a way to use processor multithreading
5. a way to limit max time under grasshopper, i..e, stp and display calcs after, say, 1 minute, or 10 or 60 minutes, to see where you are.
6. and lastly, and more importantly, a way to stop everyone myself included from complaining about what a wonderful tool we have here. Thank you again David
about number 4, you can do it right now with just a little bit of python scripting (you can call specific grasshopper components and multithread them) but at least to my experience and according to the profiler in 90% of the situations it takes longer to sync the results than to compute it on one core. This goes to the very essence of multithreading, some stuff makes sense to be multithreaded some do not. If you are still interested: http://goo.gl/T2SqsK
GH could ask for missing referenced rhino items when opening a file (maybe when opened too). Ideally each referencing component could have a customizable message. Like "Select the first curve to fillet" or whatever hint to explain what you are meant to do.
With this and the remote a user could easily open and use a GH definition.
If you add the ability to bake from the remote, GH could be used almost like a rhino command, only with the added benefit of having live control over the parameters.
If such a GH file could be executed from a button in Rhino, GH could even be invisible. It would ask for references, let you tweak the result form the remote and when you are ready press bake and the remote closes.
Small wish from me.
1) Please, can the 'autosolving/manual solving' state be choosable before reading the file? Several times, I was making this common mistake connecting unflatterned wires to one block, freezing the whole computer. What is even worser, autosaver saved this mistake, so I had to start again from the previous version. It will be really cool if I could switch the file to manual solving before opening it (well, I see it as a switch in the grasshopper menu, either to read file's state or to override it with manual.
2) csv Parser - the real one, with quoteflags
3) snippers. Well, yeah, there are components, but sometimes it is just much more handy to have snippets option instead
First feature is there. You can lock the solution (Press space, click the little lock) and then open the file. It won't start solving.
One wish that comes again and again up is to have synced panels or one panel with split view area (see attched). It would be useful for debuging issues with same data structures. One way is to have some kind of syncing mechanism (what that could be?) or have new component with ZUI input (that accepts more than two inputs and does not have an output). It could be in-file and in-place data viewer, not separate floating window like current data viewer... Is that reasonable wish?
Being able to colour wires to show flow of information would be useful. Either right>click colour, or some way of tagging a component such that all wires it affects get coloured.
Also moving over a large number of wires is hard work. For example I just wanted to change a static number that fed a large number of components to the result of a calculation. I had to follow the wires from the static number to every input, then override with the output of my calculation.
A way to do this would be to have the little white node at the output of a component be detachable (a new one would grow in its place? Plopping it onto a different components output would swap?)
A valid offset is missing from Grasshopper
Bowerbird, Clipper and Grasshopper are not delivering an all around reliable offset.
-Bowerbird seems to not be able to select all my curves and offset from inside.
-Clipper is causing a jitter and change my offset curve in a wrong way.
-Grasshopper is not offseting properly after an offset distance and instead it shows some random curves flying around.
-Rhino offset is working the best way but you have to do it by hand.
And some users that tried to develop their own offset scripts, it is bugging at some values, and not necessarily extreme values as well.