It is common to use Matrix4x3f for object matrices, but a (column-major) mat4x3 in GLSL will be treated as a vec3[4], resulting in padding to a vec4[4]. This ruins the benefit of using a mat4x3 instead of a mat4. As a workaround, layout(row_major) mat4x3 can be used to turn the matrix into vec4[3] instead, which is tightly packed. Of course, now the Matrix4x3f needs to be transposed when writing the data to a ByteBuffer, which can be easily accomplished with Matrix4x3f.getTransposed().
The problem is that in my case I am now working with a direct 64-bit memory pointer. Right now, there is only Matrix4x3f.getToAddress(long address), but no Matrix4x3f.getTransposedToAddress(long address). It would be useful to have this for all matrix types (or at least the non-square ones, since they benefit the most).
Less importantly, I can also imagine the same problem when reading back matrices from a buffer. Matrix4x3f.setTransposedFromAddress(long address) would therefore also be nice to have!
Hello!
It is common to use Matrix4x3f for object matrices, but a (column-major)
mat4x3
in GLSL will be treated as avec3[4]
, resulting in padding to avec4[4]
. This ruins the benefit of using amat4x3
instead of amat4
. As a workaround,layout(row_major) mat4x3
can be used to turn the matrix intovec4[3]
instead, which is tightly packed. Of course, now the Matrix4x3f needs to be transposed when writing the data to a ByteBuffer, which can be easily accomplished withMatrix4x3f.getTransposed()
.The problem is that in my case I am now working with a direct 64-bit memory pointer. Right now, there is only
Matrix4x3f.getToAddress(long address)
, but noMatrix4x3f.getTransposedToAddress(long address)
. It would be useful to have this for all matrix types (or at least the non-square ones, since they benefit the most).Less importantly, I can also imagine the same problem when reading back matrices from a buffer.
Matrix4x3f.setTransposedFromAddress(long address)
would therefore also be nice to have!