Point deform only accepts vector input to move the points. Is there anything that can do the same thing, but with a transform input instead of vector input?
Doesn’t sound like I’ve seen it. Anyway, it’s a very simple component to replicate in GH. You extract the points that define the geometry, transform them and create the geometry with the new points.
1 Like
What I’m trying to do is create the same effect I get from sub-object selecting one face of a polyhedron in rhino and scaling or rotating it.
What I like about point deform is that it’s compact. I don’t have to figure out how to put everything back together or risk creating a definition where the success of putting everything back together varies based on input.
I would think that if I can input solid geometry, a flattened branch of points, and a vector into point deform, in effect doing the same thing as moving subobjects in rhino, and get a solid out of the component with no further effort, that it would be possible to make a component that does the same thing but with an x (tranform) input.
I’m into grasshopper because I make things, and the less code I have to do to make things, the better.
Which command do you mean?
Shift-command click. Then rotate, or rotate 3d, or mirror, or scale.
I tried to put up something out of curiosity… it came out a big mess.
“Solid points” functionality is not exposed in rhinocommon, if i’m not wrong.
So this solution try to get the most possible faces from grasshopper point deform, and the rest with some rebuilding of flat faces, and lastly patch.
And that’s the problem: moving out-of-plane a point in a non-triangular face will result in a curve surface, so a patch-like surface is needed… ugly results, open borders (blue in the gif), etc, etc…
Well, if you make simple transformation on the faces, this script could be enough… but if you have only simple transformation you can use a really simplified version of this definition, like what Dani said in the first reply.
transform_face.gh (32.6 KB)
This is just a test.
What you ask, easily end up requiring the patch functionality… and in my personal experience patch is only for last resort.
So… meh! 
2 Likes
I don’t know how Rhino does it, but it’s not exposed in RhinoCommon. Rhino’s geometry is not procedural, you can create a surface by joining faces together but if you modify one face, the adjacent ones will not be updated because there is no such process of internal construction that remakes the surface from the modified face. To achieve this, after transforming a face, you have to remove the adjacent faces and recreate them preserving the topology.
Any linear transformation (like rotating, scaling, reflection…) can be mapped to vectors, where the beginning of the vector is the original state of the points and the end of the vector is the transformed points. So in theory you can use that component to do what you want, but it doesn’t have support for breps.
@DanielPiker developed his own version of something similar with the Mesh Cage Morph component. But the fundamental problem is still there, if you want to transform a part of the geometry and have it affected according to the connected parts, you need to deal with its construction topology.
The example of @maje90 perhaps explains better the idea and limitations of RhinoCommon.
I didn’t share this yet, but I also worked on a general deformer that doesn’t require a cage - it’s actually a form of bone based rigging - the bones can form a connected skeleton, but they can also just be individual floating frames like here:
It uses Rhino’s UDT (by implementing SpaceMorph), so can work on all sorts of geometry, including Breps and trimmed surfaces.
It sounds to me though that @Max3 is looking for something where the new shape is still defined entirely by just the positions of its vertices (with no additional orientation info), more like what @maje90 has done above?
I’m still not sure I entirely follow the original question though - if the deformation is to be defined entirely by the new positions for its corner vertices, then whether those new positions are arrived at by scaling/rotating is irrelevant, since each vertex still has a vector between its original position and its new position. Is the question more about Grasshopper’s Point Deform not working with trimmed NURBS surfaces?
9 Likes
I didn’t realize the question was more about point deform not working with trimmed surfaces when I asked it, but that’s pretty much it.