Legion Transform Design Discussion

A mat3x4 or mat3x3 requires padding when passing to a shader in a uniform as it doesn’t align properly. Just something to consider.

I kinda like the idea of:

struct Parent {
    parent: Entity,

struct Transform {
    local: mat3x4,
    global: mat3x4,  // only updated when transform system runs
    parent: mat3x4, // identity for root entities

As it lets the user dictate how components look vs forcing them into using a transform that might have more than what they need. I would maybe make an additional struct like:

struct SimpleTransform {
    matrix: mat3x4,

For cases where you have an entity without a parent/child.

So, does everyone agree on the latest proposed solution? Who is against or has a better idea?


:+1: for me


I agree aswell. This usability vs performance tradeoff also aligns more with the views expressed in the future vision thread.

But before we proceed I still have one question. Is there really a performance gain by using mat3x4 instead of mat4x4 considering that a system will have to run each frame to convert all 3x4 to 4x4 for GPU?


Is the proposal something that would happen in parallel with integrating legion or after?

If you are SIMD column-based matrices, mat3x4 will take the same space as mat4x4 as each column will be 16-byte aligned and there would be 4 columns. If not SIMD (for example serialized to disk) it would make sense to go 3x4.

I’m not sure having multiple transform components (i.e. one supporting children and one not) is a good way to go. All downstream code would then have to always check for both or know ahead of time which one to expect. I would try to make child/parent logic either integrated with the single transform component or be an additional component rather than replace it. This way any system that is not aware of parent/child will still function. I also think parent/child support is complicated enough that there needs to be a working prototype before settling on any particular solution.

1 Like

You can store the transform as a single component if you wish, but you cannot store the source-of-truth as a mat4 as it accumulates errors over time, see my posting here.