Per component transform

[chaynabors]

I have a micro-crate which I use across many different crates that adds a per component transform. It's essentially an Affine3/Affine3A with explicit rotation (Quat) and scale (Vec3). If I contributed this to glam would there be an interest in merging it? What could we call the type? It technically represents a similarity, but I'd propose simply Transform3/Transform3A. Not the most rigorous name but has very clear precedent.

I have a number of libraries I want to push to open source (procedural mesh generation, scene graph, graphics state machine, a bunch of collision functions, etc), but it's a little weird they all depend on this helper type. I think it should arguably exist in glam itself, which is a hard dependency in all my libs, but I want to check to see if this fits the design goals before I do the work to contribute it.

[bitshifter]

Hi, so this has come up before way back in glam's past and ultimately I decided not to include this kind of type (If I'm understanding the type you are proposing correctly).

This comment talks about some of the issues with these types #25 (comment)

And this one was where I ultimately decided to remove them from glam #25 (comment)

The relevant parts of the discussion were

So (A * B) * C != A * (B * C) (for rotation and non-uniform scales) which is highly surprising. One effect of this is that transforming a vector by first A and then B is not the same as transforming it by the product A * B. I think this is a big footgun that will cause many people to lose toes. I would suggest that Transform3A * Transform3A -> Affine3A to avoid this.

and

A Transform type, expressed as a separate rotation, not uniform scale and translation is an extremely common data structure in game engines, (e.g. https://forum.unity.com/threads/transform-matrix-elements.18836/#post-128496, https://github.com/defold/defold/blob/1ae302ec33d4514408c04ad3ae5d3c1efe2057bd/engine/dlib/src/dlib/transform.h, https://docs.unrealengine.com/en-US/API/Runtime/Core/Math/FTransform/index.html, https://docs.aws.amazon.com/lumberyard/latest/userguide/component-transform.html). It is specifically for positioning entities in a 3d scene and supporting a parent child relationship between entities, i.e. a child transform is relative to a parent entity and if there is no parent the transform is relative to the origin. The order of operations follows the parent child relationship, so A * (B * C) does not necessarily make any sense with these types. I think one of the reasons they are quite commonly used in game engines is rotation is stored separately from scale.

I guess because this is more of an engine specific type, in that it is tightly coupled with how a game engine represents a game world, perhaps it doesn't make sense to be a type in a math library.