Nice.
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.
1 Like
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.
1 Like
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.
2 Likes
Well my head is exploding a little, but Iām glad Iāve planted a seed.