yeah … I can’t wait to finally use the new “Rhino” tab in Grasshopper.
But most of my workflow is scripting. Currently scripting in 8 is incomparable with scripting in 7.
Funny thing is, every request I’ve done is by not even using 8. Too less productive.
When I’ll start using 8 daily (at like SR .10 … or sooner hopefully) , any details i’ll find while working, any new request for UI change or bug fixed, will be likely pushed to 9.x.
Am I being too pessimistic?
With the Branch names option, the content is baked to a parent which has the same name as the current cache and a child layer which equals the object type. So in this example, baking a curve, the child layer is named ‘Curves’.
Without a cache name, the content is baked to a parent layer called ‘Grasshopper’ and also a child layer ‘Curves’.
If the object is passed through a Model Object component, a layer can be specified like this:
In my view a new user needs some clarity (in layman’s terms) on which GH nodes bring Rhino objects into GH for manipulation and which nodes generate new geometry and send it back to Rhino.
There is a bit of a clue. All “parameters” (ie. Grasshopper objects which are containers for bringing Rhino data into Grasshopper) have icons that are drawn with a dark grey hexagonal background. They are also primarily placed under the Params tab. “Components” on the other hand are Grasshopper objects which actually “do” something with incoming data - like create a circle or loft a set of curves. Components make up the bulk of the objects available in the Grasshopper menu.
That’s why I don’t use GH more. I learned to use it, at a basic level, at least three times since it came out. And if I need to use it again in the future I will have to learn it again.
The problem is that each time either some components change name or are drawn differently or their behavior change, a plug-in is not available anymore (or there’s a new version that works differently), or what I need is a little bit different but needs a completely different approach and I will loose hours trying to work with a component I’m familiar with.
All you say is that somehow params link to Rhino objects. This “somehow” is not discoverable. Whatever clue you guys think there is. It’s not evident. I tried drag-drop of the curve on that little GH knobby thing node, but doesn’t accept it. I righ-clicked the node looking for an “select rhino curve to attach”, but didn’t see it (is it the “set one curve” thing ? I don’t want to set anything, I am looking to select, or import something).
Ah, I see. Thank you for clarifying. Yeah, I guess I can see how this is opaque the first time you use it. Grasshopper tends to rely a lot on menus that can be instantiated by right-clicking on the middle of a component/parameter. In this instance, a right-click menu reveals a couple of options to "Set one curve" (for example) or "Set multiple curves". By selecting either of those menu items, it would cause Grasshopper to fade away and you would be directed to the Rhino viewport where you could select one or multiple curve objects in your Rhino document. From then on, that parameter would contain references to the curve objects that you selected. This process is done so frequently that it becomes a bit like muscle memory so many users tend to look under the right-click menu to see if the options they’re looking for are there… But, I can definitely see how this would not be apparent for a first time user. This is usually covered in many of the “Getting Started” guides that were linked above in the thread… but you’re right that it should be more intuitive so that’s definitely something we can improve.
I looked into that menu, and
a) “Set one curve” did not seem relevant (so we have a language issue). I was expecting “import”, or “select Rhino curve”
b) The idea of selecting “one” or “multiple” seemed bizarre. If a user makes a selection it’s easy to tell programmatically if they selected one or many. Bothering the user to make such distinction implies there’s a complex reasoning behind it.
I’ve been using Rhino since 2009, and investigated Grasshopper soon after. At the time the “introduction to Grasshopper” material available from McNeel presented Grasshopper a way to use sliders to control geometry, with little to nothing about creating algorithms or similar. Also my recollection is it was explicitly stated that Grasshopper had no conditional branching and no recurssion or looping. I did not see how Grasshopper would be useful for me.
A long time ago I did a lot of Fortran programing for number crunching including algorithm development. My guess is it would be more efficient for me to learn C# (or similar) in a modern coding enviornment and create plug-ins directly than to use the Grasshopper graphical interface.
Why is it bizarre to have the option to set just one object? If you had used GH for a moment, you’d realize that setting a single object does not require a confirmation by right clicking / spacebar / enter. It only sets one object and basically saves you a click / interaction.
“Link a curve” “Link a list of curves” or something similar would make more sense… you are right here.
There could be also “a tree of” … by how Grasshopper works.
Object can be already selected on rhino. If that is the case, this:
does not happens, or almost.
What would be the default? Use the pre-selected geometries? Clear selection and ask again to select?
If you use “Set one” but more than one object is selected, it will clear the selection and prompt you to select something.
If you use “Set multiple” , if you have one or more object pre-selected it will use those.
But! This way you are missing the order.
Picking one by one your object will ensure the order. If you want to ensure the order, deselect before referencing.
Not simple. But we can agree the UI is not obvious for the “referencing” part.
There is a bit of a distinction because Grasshopper components do tend to work with data stored as an “item”, “lists”, and “data trees”. Knowing how to control your data can be instrumental in how to work with Grasshopper. Parameters which contain only 1 object is thought of as containing an “Item”. Parameters which contain more than 1 item is thought of containing a “List”. And a data tree is closer in concept to a “jagged array” where a parameter can contain a list of branches where each branch can contain a list of objects. Grasshopper has many different tools for manipulating lists and data trees and as you work more and more in Grasshopper, learning how to use those different tools can become really important. Again, usually this stuff is covered in some of the documentation that is listed above. There is a chapter in the Grasshopper Primer which covers “Designing with Lists” and another chapter which covers “Designing with Data Trees”.
Rhino doesn’t really know anything about Data Trees. That is a concept that David Rutten invented for Grasshopper. We could I guess create some intricate “selectors” for this, but I imagine it would get very tedious very fast trying to figure out which items you selected and which branch their supposed to go on.
