boostorg / qvm

Boost Quaternions, Vectors, Matrices library
Boost Software License 1.0
81 stars 43 forks source link

Memory layout consistantency with graphcis APIs #53

Closed felixaszx closed 2 weeks ago

felixaszx commented 2 weeks ago

Looks like qvm has a memory layout differed from common graphics APIs like VK, DX and GL. for matrix that translate to [1, 1, 1] will have a memory layout of {1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 1, 1, 1, 1} in all mentioned apis above which is colum-major despect the fact that DX and GL(VK) have different interpretation base on that. However, seems like qvm will have the layout of {1, 0, 0, 1, 0, 1, 0, 1, 0, 0, 1, 1, 0, 0, 0, 1} which is row-major. Is it possible to ensure a memory layout consistency between qvm and graphics APIs?

zajo commented 2 weeks ago

QVM is independent of any particular memory layout. Logically, access is always in terms of Row, Column, and in a 4x4 matrix the translation occupies elements <3,0>, <3,1>, <3,2> (zero-based). Physically, the data can be stored in row-major, col-major, or only part of the elements may be stored, etc. This is up to the user.

If you're using a graphics API that defines a matrix type, simply specialize the qvm::mat_traits template for that type, and voila -- you can use any compatible QVM operation on that type, and it will use the physical layout of that type.