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.
So...
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!
Cheers,
Marc
Tags:
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?)
Oh great!
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.
Here are some petty complaints and unreasonable wishes:
Numerically placing several points or vectors is a bit of a pain point
Right click on Vector > Manage Vector Collection > Add Item
Once I click Add Item, I then have to hit escape, telling GH that I do not want to input the vector manually, and then I am allowed to input the numbers to define my point or vector.
This is small, but drives me crazy.
Boolean Operations rarely function as expected. If I have to do a boolean operation, I bake to Rhino and do it in Rhino.
The Help feature found on each grasshopper block seems to only give me information that is already available by mousing over the inputs and outputs. Also, all Tutorials and primers are for entry level GH users. Can you create advanced tutorials? I'm worried that I'm missing things sometimes.
Thanks,
Tom Geo
You could write your points or vectors in a text panel and connect it to a point or vector component. Or did I misunderstand the problem?
/ola
All components that uses the global coordinate system should have a ZUI local coordinate system input. e.g. "construct point". In general a lot more ZUI features! :-D
Thanks, I know, but why have two components at all? Why not one component with ZUI that do both? I believe David introduced the oriented point component when he removed the plane input from the "normal" construct point component. If there is a construct oriented component shouldn't there also be a deconstruct point oriented component.. (or a ZUI input to the existing deconstruct point)?
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by