Transform Matrix shows unpredicted results

Attached is a photo of the definition which is separated into three main components. All three components do the exact same thing; the only difference is that the scalar value is different. All three components also reference the same square. For whatever reason, the translation or homogeneous coordinates of the transformation matrix seems to react to a scaling transformation which I can’t seem to wrap my head around.

Shouldn’t the scaling transform only affect the magnitude of the X,Y, and Z components (columns) of the matrix while leaving the W component untouched? I also moved the square to the world origin in Rhino as a benchmark, and it seems to be displaying fine, but maybe I’m just misunderstanding how the transforms are applied in Rhino/Grasshopper. Any thoughts?

Thank you! (24.7 KB)

Hi @mbblack,

By providing a center point, the component is also adding in a translation transformation. If you only want scale, then you can do something like the attached. (7.5 KB)

– Dale

1 Like

Thank you for your response, Dale.

I see what you were doing and it is helpful to know that adding a center implicitly adds translation data to the transform. Would there be anyway; however, to essentially change what the transformation references as the “world origin”, though.

I guess an example might help. So, in the example that I posted, I am trying to scale the square while staying in the same plane (in the case of the attached definition, the XZ plane) whereas your C# example shows the square being projected. This way, I could ultimately set my own temporary world origin that the transform data references from. In this sense, the transformation data would reference my own temporary origin as the world origin.

Obviously, I could then just base the square in the origin, but I will be composing other affine transforms on the square which will inevitably move the square from the origin.

Does that make sense? If not, I can attach more examples so that we’re not speaking so generally.

*EDIT: Also, I suppose I could just manually reset the ‘W’ values back to zero before applying other transforms



I believe I found my issue. I’m essentially trying to replicate a local CPlane in Grasshopper; however, this feature (as far as I am aware) isn’t available. Grasshopper seems to always only reference the default World XYZ origin regardless of whatever CPlanes are currently used in the Rhino Document. My workaround for the time being is to just center my basis object around the world origin.

This isn’t ideal for more complicated scenes where I wish to use multiple basis points, but I guess it beats manually typing in matrix values.

I’ll attach my most current working file for anyone interested. The component marked (1) is the basis geometry that the transforms are based around. (2) is transformed geometry, and (3) generates text based into the Rhino doc. This might not be visible; however, as it is part of the “Elefront” plugin for GH.

_mason (38.2 KB)