Update transform type and explicitly state matrix layout about anari-docs HOT 4 CLOSED

Our discussion was a bit inconclusive. In other places ANARI is compatible with OpenGL and glTF (using a right-handed coord system, screen space origin is lower left, ...), thus we should rather consider to move to column-major format (as actually defined in Sec 3.5 for the matrix types).

from anari-docs.

I discussed it with my colleagues at our university. I am joining our thoughts without being bold about them:

• we like column vectors and row-major matrices (as opposed to row vectors and column-major matrices) because majority of scientific papers and books uses them. This might be because of higher convenience, paper space consumption, or something, but anyway, this is what you see on the paper and what you image in your brain.
• column vectors and row-major matrices produce the projection equation: vertexNDC = proj * view * model * vertex
  while row vectors and column-major matrices uses: vertexNDC = vertex * model * view * proj. In some sense, it is the preference of a programmer which one he likes.
• performace view: you might notice that the row-major matrices (vertexNDC = matrix * vertex) is very effective with the respect to the memory access. The matrix is accessed linearly, as stored in the memory, from its first member to the last. In GLSL, we might even store each row in one Vec4 register, making the multiplication just four dot products between five Vec4 registers.
• column-major matrices might be converted to row-major before they are used; This functionality is provided by OpenGL API, for instance, and GLSL code might already use row-major matrices.
• but how is the performance of column-major matrices? Many programmers might be confused here. The computation vertexNDC = vertex * matrix seems like we are jumping in memory of matrix during the multiplication, but, at the end, it is not true. It is just not intuitive. We have matrix columns in Vec4 registers surprisingly, so it is the same effectivity of memory access as in the row-major matrix vector multiplication. It is just not intuitive. In my opinion, these column-major matrices are more confusing for programmers and for students of computer graphics. We naturally expect that rows are stored linearly in the memory, not columns.
• concerning compatibility with other APIs: glTF uses column-major. OpenGL prefers column-major while row major is supported since OpenGL 1.3. Vulkan supports both. However, Vulkan ray-tracing extension made a turn. It uses row-major 3x4 transformation matrix in VkTransformMatrixKHR structure.
• using 3x4 matrices could be beneficial for many applications because they are sufficient for storing rotation+translation+scale. We expect to store them in 48 bytes. However, having them in column-major format, it is once again very confusing: Is it 4x3 matrix instead? 4x3 matrices use padding and consume 4 registers instead of three and 64 bytes instead of 48, etc. Does this apply even to column-major 4x3 matrix? I guess no. To the surprise of many, it still consumes 48 bytes and uses three Vec4 registers. Just asking myself: why all this pain of column-major matrices? If I am wrong, anyone, please, correct me.

In summary, I see row-major matrices much simpler to understand. They are intuitive and very straightforward to use, and they are used in scientific papers and books. On the other hand side, column-major matrices are probably more used because of glTF and OpenGL, although Vulkan raytracing made a turn to row-major matrices.

from anari-docs.

#12 captures the outcome of our WG discussion:

• we like to stick to column-major memory layout of matrices, to keep consistency to OpenGL and glTF
• note that the matrix is still thought to be multiplied from the left to column vectors
• we also removed non-square matrixes and use 4x4 for affine transformations
• interesting point with VkTransformMatrixKHR of VulkanRT: yes, some backends will need to massage transformations

from anari-docs.

Thanks for the summary of the WG discussion. I understand that the consistency with OpenGL and glTF is very strong argument.

from anari-docs.