Consider adding transform types

[bitshifter]

When dealing with transforms that only contain position, orientation and possibly scale many operations can be performed more efficiently than using a general purpose matrix.

A while ago I experimented with transform types which contained position and orientation (as a quaternion) much like Unreal's FTransform, but I found these to not be particularly more efficient or to save much space in practice, so they are not enabled by default. They can be enabled using the transform-types feature.

Another option might be to have these kind of transforms backed by a matrix with simplified methods/operators similar to Transform4D described in Foundations of Game Engine Development Volume 1.

[cessen]

Somehow I missed this issue when I was checking for existing issues before filing #62. I think #62 can be merged with this issue, as it falls under the umbrella of the title.

[cessen]

Quoted from issue #62:

I've been poking at Psychopath a bit again, and I realized that in the context of a ray tracer you pretty much never need full projective transforms, you only need affine transforms. And this presents a lot of opportunities for optimization:

• An affine transform matrix only needs to store 4x3 floats, not 4x4, because the fourth row is implicitly known.
• Transforming points/vectors can be further optimized due to the statically-known implicit fourth row.
• Matrix inversion can also be further optimized.
• There are tricks for directly performing inverse transforms on points/vectors that are more efficient than fully inverting the matrix + transforming.

To expand on that: affine transforms cover all of the transforms that are useful for object-space/world-space transforms:

• Translation
• Rotation
• Scale
• Shear

The only thing full 4x4 matrices cover beyond that are projective transforms (e.g. perspective projection), which in the context of graphics are typically only used for camera projections to screen space. So I think affine transforms are useful to have as a separate type: client code can use them whenever object transforms are the concern, and screen space isn't relevant. It both makes the intent clearer and opens a lot of doors for further optimization as noted above.

Lastly, the current implementation of Mat4::transform_point3(), as noted in its comment, is optimized in a way that won't work correctly for perspective projection matrices. That makes a lot of sense given that the common case is likely to be object transforms, but it's a bit unfortunate that it's not correct for the general case. Making that compromise is only necessary because Mat4 is trying to simultaneously serve two different purposes: both affine and projective transforms. If we add a separate affine transform type, then we won't need that compromise: the affine transform type can have the optimized version, and Mat4 can be correct for the general case.

[cessen]

As I mentioned in #62, this is something that I would love to implement for Glam. However, my time at the moment is limited, so I probably won't get around to it for a good while. If someone gets around to it before me, that's also great. I'll come back and comment here if/when I start working on it, so people don't have to worry about duplicating efforts.

[bitshifter]

I may have time to look at it after I've finished with some other issues.

From memory I was planning on basing an implementation on the Transform4D from Foundations of Game Engine Development Volume 1.

If I do start work on it I'll mention it here.

[cessen]

One more thing possibly worth mentioning explicitly: one of the benefits of an affine matrix over e.g. a decomposed translation/rotation/scale representation is the above-mentioned ability to represent shear. And that comes up more often than one might think.

For example, even if an application doesn't directly support shearing, if it supports non-uniform scaling and parent-child relationships, then shear can still easily occur with a non-uniform scaled parent and a rotated child.

So I think a full affine transform matrix type is generally the way to go, because it handles all the corner cases correctly, which a decomposed solution doesn't. Decomposed representations make a lot of sense for user-interaction, simulation, etc. But IMO they don't make much sense for just representing raw transforms for e.g. rendering.

[bitshifter]

For sure, the Transform4D I'm referring to is stored as 4x4 matrix rather than a decomposed solution - sample code is here http://foundationsofgameenginedev.com/FGED1-code.cpp.

The main thing is it's a separate type so can shortcut things like inverse, multiplies and transforming 3d points and vectors.

Once #36 is complete one question that might need to be answered for this type is should it be stored as the 12 byte Vec3 columns or as 16 byte Vec3A16 (or whatever I end up naming it) columns. There's pros and cons to both. Being able to trivially convert the affine type to a Matrix4 could be handy in the game case, but then it's a lot of wasted space.

[cessen]

Maybe I'm brain-farting, but wouldn't you want to just store it as 3 Vec4s? Then, for example, transforming a point is just three dot-products with that point: one with each of the three Vec4s. Moreover, converting to a Mat4 is trivial: just append one more Vec4 with the values [0, 0, 0, 1].

Edit: yeah, I brain farted. That's slower than splatting each of the point's dimensions and doing both the multiplies and sums via SIMD.

[cessen]

I think it comes down to whether the performance or the space savings are more important. IMO the performance is more important, so my vote is for just sticking with four Vec4s, and wasting the last element of each.

And I think I can make a pretty good argument for the space savings not being so important: even though it's wasting 25% of the space of the transform matrices, matrices themselves typically only make up a tiny percentage of the total in-memory data of a game or offline renderer. Meshes, textures, etc. take up way more space. So for the typical use-cases of Glam, it's not really wasting 25% when you look at the big-picture, it's more likely wasting 1%, if even that.

[bitshifter]

I noticed on Embark discord that their macaw library has an affine transform type. It's not public yet but if they have already written one it might be good to use that rather than duplicating the effort.

[lukabavdaz]

I would be interested in a similar type for 2D transforms.
Euclid already uses 3x2 matrices for this and performs more than 70% better than glam at point2 transform benchmarks.

[emilk]

At Embark we have an IsoTransform which represent isometric transforms using a Vec3 translation and Quat for rotation. This is great for expressing poses of objects, and is fast and compact. I can add it to glam if there is interest.

Another type that may be of interest would be conformal transforms: translation, rotation and uniform scale. There are two conformal transform versions that may be of interest: with or without mirroring. The interesting things about these class of transforms is they maintain the shape of things (i.e. don't squash or stretch them), and are also pretty efficient to work with. I have some code for this too that I can clean up and add to glam, if it would be interest. Does need some good name suggestions though.

The final step is affine transforms. 3D affine transforms are best encoded as a 3x4 matrix, while 2D affine transform can use either a 2x3 matrix, or using only four numbers (using only one column of the rotation matrix, which effectively is a complex number rotator).

---

PS: saving space is often more about improving cache locality and thus reducing cache misses, which can have a huge performance impact.

[emilk]

I'll start working on a Mat3x4 that we can try out. Internally it will be row-major for performance (3x Vec4), but the interface will be the same as for Mat4.