Plane/Transform/Axis musings

I wrote a Grasshopper Component that creates a mesh (geodome), and would like to allow the user (me : ) to transform the mesh into place in some way - parametrically (position, rotation, and maybe scale).
For that I use a GH ‘Plane’ object of course, which can be placed interactively by ‘Set one Plane’, position and rotation (no scaling, though).
But what when the plane should be derived from some scene object instead of interactively placing it? And what if I need scaling, too?

Basically, a GH Plane is a transformation matrix, right?
There seems to be no 1:1 equivalent to the GH Plane in Rhino. If I bake it, I end up with a ‘PlaneSurface’, a NURBS surface - that’s seemingly as close at it gets.
Yet, vice versa, when I create a ‘Plane Surface’ (command ‘Plane’) in Rhino, I cannot pick it from the GH ‘Plane’ component.
Isn’t that somewhat inconsistent?

So, I could use a ‘GH Surface’ node to get the plane surface. But how do I derive a transform from it?
Access it’s Gumball? How is that done in code?

Then, in the SDK, there’s the Rhino.Geometry.Transform object (which I use in Python), but it, too, has no 1:1 equivalent in the Rhino scene, has it? (From a Python component, I tried to bake an output variable of type ‘Transform’, but got nothing)

In most other 3d-programs, ‘transforms’ exists and is shown as an axis cross or tripod.
In Cinema4D or Softimage this is called a ‘Null’.
In 3ds Max and Maya, this is called ‘Point’ (unlike the Rhino Point is contains a complete 4x4 matrix).

Ain’t this missing in Rhino? (I know, i know, CAD-program and such… )
However, there seems to be a paradigm to avoid such a thing. Is there a reason for this?

Thanks for reading!
Best regards

No, a Grasshopper plane is a Rhino.Geometry.Plane (an origin point, three axis vectors, and a plane-equation). A transformation is a 4x4 matrix of numbers. There are however strong theoretical overlaps and it is easy to create a transformation which maps coordinates in one plane-space to another. There is no plane object in Rhino itself, although CPlanes and clipping planes get close. They do not however behave like typical Rhino objects such as points, curves and meshes.

The closest thing Rhino has to transform objects are the gumballs, but again they act more like control-points than individual objects in their own right. There’s lots of data types that the Rhino SDK can deal with that are not in fact available as Rhino Objects, planes and vectors are amongst them, numbers and matrices and colours would also count.

Planes in the Rhino SDK are somewhat more flexible than the planes in Grasshopper. The axes need not be perpendicular and the axes need not have unit length. If you were to create a plane that has much longer axes (say, 20.0 units instead of 1.0), then you could combine orientation and scaling transformations into a single plane. You’d then need to construct a ‘Change of basis’ transformation from the original plane (probably World XY) to your custom oriented and scaled plane.

Another solution would be to create two transformations, one that scales your geometry to the correct size, and another that orients it in space somewhere. You can then multiply these two transformation (careful, the order matters!) and end up with a single transformation matrix that does both.