First is Rhino geometry groups.
Second is Grasshopper groups (that still aren’t handled by new gh Beta components…?)
Third is Grasshopper “component grouping” groups, which is totally unrelated to the first 2, yet have the same name and very similar icon.
Geometry groups have been replaced by “tuples” in GH2. Tuples can store all kinds of values, not just shapes. Component groups are still called groups though. Can’t call them ‘boxes’. Can’t call them ‘frames’. They could be called ‘containers’, but I don’t like that word. Suggestions?
I’ve found myselft telling other people “make a group of those” while using grasshopper … and that is vague.
That’s very useful! (It simplify a lot some tree handling, right?)
… still, Rhino have “groups” which simply are selection pre-sets, if i’m not wrong.
Baking geometries already pre-grouped is useful. I still expect to have “groups” in grasshopper somewhere, and I expect them to be the same thing meant in Rhino.
(btw, I can adapt to anything, I’m talking more about putting myself in the shoes of the students, new learners)
I agree. But it’s already better than “groups”…
It’s a portion of the document, the canvas… a “patch”? “rag”?
I don’t know too.
If Grasshopper groups (“containers”) had inputs to control its content
and see video here at 2:35 How to manage a big definition? Any tips?
… that would mean going near to what clusters currently are.
Maybe we could end up with a single object type, the “cluster”, that can be in “packed state” (like current cluster) or “upacked state” (like current groups/containers).
Surely you have a better view of the situation…
Canvas Groups or Code Groups or Component Groups cGroups
I haven’t made up my mind yet whether changing the name is a good idea on balance, but I think I like ‘bundle’ best. Short, semi-descriptive and doesn’t conflict with anything else.
like that thought