You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!The text was updated successfully, but these errors were encountered: