Any idea if Grasshopper 2 will allow sub-object references?
Any idea if Grasshopper 2 will allow sub-object references?
You mean reference the edge of a Brep in Rhino as a Grasshopper curve? Or…?
Reference a solid, then reference any of it’s edges, faces and/or vertices and then move them and have the result create a deformed solid the same as if one selected the subobjects and moved them in Rhino.
Point Deform seems to be able to be used in a similar manner in some circumstances, but it’s not exactly the same.
I’m relatively new Grasshopper user so I don’t know all the components and plugins yet. Maybe there’s a component that already does this and I just don’t know about it?
This is tricky. The functionality to deform a brep by specifying transformations for its edges or vertices is something we can expose, but if data in one part of the file references data in another, it is no longer clear who owns what.
For example imagine a simple case of a Box. We ‘reference’ two of its edges. One referenced edge goes into a Move component and the other into a Rotate component. Is the original box changed? Does each separate operation yield a new box?
The former breaks the immutability rule of Grasshopper data, which states that components are not allowed to modify values made by earlier components. The latter means you cannot combine both edge transformations into a single new shape.
I’m not entirely sure what the best solution here is, but referencing sounds very, very dangerous.
I was thinking that if point deform could be used to move one edge of a cube up an inch by inputting the brep, the endpoints of the edge, and a vector, then it would follow that it should be possible to have a component where once could input a truncated cone as the brep, the planar circle on the top of it as a subsurface to move, and a vector and/or rotation. Similarly, I could see situations where inputting edges and points simultaneously and then scaling them from a point could be useful.
It seems like this would allow for very intuitive transformation of referenced rhino geometry. But of course as a newish user I guess I don’t fully understand the consequences this could create for data flow, or processor strain. Doing lots of simultaneous subsurface moves in rhino can get crashy, after all.
Oh absolutely. Provided the Rhino SDK exposes this functionality that’s a component that could be made today. The Fillet Edge components in GH1 in R7 are very much like this. You input a Brep, a filleting radius and some edge identifiers (other components are used to find the appropriate identifiers), and you get a rounded Brep out the other end.
None of that workflow necessitates data in one place which references data in another place. All the relationships between Breps and edges is entirely encapsulated within the component.
So what makes Point Deform possible without violating immutability is that the point input to that component is used to locate control points, rather than to be those control points?
Would it not follow that a hypothetical Subobject Deform component could operate in a similar way?
Again, in way over my head here. I don’t get how the gears inside the machine work at all, I’m just trying to think in an application-oriented manner, looking for Grasshopper UX that intuitively matches Rhino functions, because in my ideal world a user’s understanding of how both explicit and parametric modeling work in this environment is as seemless as possible.
@Max3 this is actually a bit out of place in a Rhino discussion, let’s start a new topic in the Grasshopper category instead.
I’ll try to come up with some more specific examples of the various ways in which this might make sense tomorrow.
Gotcha. It was definitely a tangent on my part.
The first example that comes to mind for me as a use case is for SubD in general. I see a string user experience argument in favor of creating a component that allows control of a SubD object by transforming it’s faces, edges and vertices without deconstructing it.
Another possibility: parametricize a cabinet design, based on an original cabinet drawn as a set of polysurfaces in Rhino. As far as I understand it, the approach one would tend use now would be to program the entire cabinet in grasshopper. But if I could draw an archetypal cabinet in rhino and then be able to quickly grab, label and move subobjects using Grasshopper, I think that would make the process much faster.
I agree with this, and wished GH was integrated much further inside Rhino than it is currently.
You can achieve this currently by using RhinoPython (probably a c# plugin as well of course).
Yes it wouldn’t be native behavior to GH but it’s feasible launching python scripts affecting Rhino objects via ghpython components.
Probably also working in the scope of rhdoc instead of ghdoc, but I still don’t get that very well.
I imagine GH further integration to replace RhinoHistory completely. Then the datatrees must become some panel showing relations between the objects.
Also the way catia has it e.g. an object A is being translated then we have new object B. If we also need a rotation then we can choose if we wish this rotation to be combined with the translation then we run it on object B and then we have object C being both translated and rotated.
Objects A and B are still there just not active/visible. You can access them by invoking the parent objects of C.
I don’t want Rhino to become catia, don’t get me wrong. Just implement the good stuff of catia
I like where you’re going with this, but just to be clear, I was suggesting a situation where one would reference a rhino-drawn archetype, alter the referenced geometry in Grasshopper, and then bake as needed.
Yes, I got what you meant, but that can’t really happen. Unless Rhino is in the scope of GH and not the other way around.
Ideally, if GH doesn’t depend on Rhino calculations (of the geometry) and becomes separate application. Having its own viewport(s). This will be possible as there will no longer be Rhino objects, everything will be GH objects.
But I doubt this will happen.
My answer to @DavidRutten here is: every transformation should create a new box.
Maybe there would need to be separate components for different transformations? One for move, one for rotate, one for scale?
To move one box edge and then rotate another, you feed the output of a “Subobject Move” component into a “Subobject rotate” component.
I’ve had situations where I’ve cascaded three point deform components in a row, to move various corners of surfaces in different directions. Same principle, expanded.
This is how GH works currently.
If you provide the three points in a list and you set move with a list of directions respectfully, you can do this in one go.
Ah. Every time I’m on this forum I learn a new way to condense my definitions.
But would a “Subobject Transform” component be too cumbersome if it allowed scale, move and rotate in a single component? Seems like determining the order of those operations within a single component could be a little tricky. Maybe an input could accept integers that correspond to permutations of the options of orders of operations?
Or would that actually be better than separate scale, move and rotate components? I could see it also being cumbersome to have to re-identify subobjects after they’ve been scaled in order to rotate them.
As far as I know in Rhino a modification of an object is in fact deconstructing (deleting) the original object applying the modifications and then constructing (creating) the object again.
And in GH this is the same workflow, in order to get to the sub-objects you deconstruct the object modify the sub-objects then create new object out of the modified sub-objects.
So I’d say “subobject transform” is something impossible at this point.
But if you want to avoid placing a lot of components to create complex stuff then use ghpython or other scripting components you can do all that inside a single component.
I guess what I don’t understand here is why if Point Transform is possible, “SubObject Transform” would not be a feasible component to create. Point Transform appears to find an object’s points by accepting input of identical points, and then move the object’s points and thus transform the object. Why can’t we do this with an object’s face or edge? Why can’t we scale or rotate?
In terms if UX, I can see many many applications where this would be preferable to deconstructing an object, altering its parts, and putting it back together.
Here’s two approaches that would work without violating the data ownership rules.
The first does everything inside a single component. You input a brep, a set of edges and a set of transforms (one for each edge you specify). The component then internally makes a duplicate of the input brep, deforms it and outputs this new brep:
This is just regular Grasshopper, no new data types needed, no new concepts. Maybe there’d be a whole range of components for deforming brep edges, brep vertices, brep faces, mesh edges, sub-d vertices… I don’t know. Or maybe it’s just a few components which are individually a bit more complex but more flexible.
The other approach (which is what I originally thought you asked for) depends on the inclusion of a new data type; Brep Edge. This is a type of curve which nevertheless remembers that it is really an edge in a brep. Once you have one of these edges, you can then use that data in any component which accepts curves as input (Length, Transform, Move, Rotate, Divide, Offset, …) but you can then get the underlying brep out again using a second component:
It would not be legal for the three edges which are created in the leftmost group to share their underlying brep shape. So now you’ve got three duplicates of the original brep, one for each edge. When the edge is transformed it behaves just like any kind of curve, but if you want the deformed brep which was implied by the edge transform you need a component (the rightmost group) to extract it.
This second approach is … weird, I guess. It’s not wrong, not even particularly counter-Grasshopper, but there is no other type of data which acts like this Brep Edge type would.
Well my head is exploding a little, but I’m glad I’ve planted a seed.