Inquiry about the viewmat

[RayYoh]

In this issue, I have noticed that the viewmat should be the world to camera matrix for gsplat rasterization.

I know that gsplat also provides a wrapper for the original implementation of 3DGS rasterization_inria_wrapper, which seems to have a similar input as the gsplat rasterization. However, I am wondering why there is a transpose operation here.

[RayYoh]

Additionally, a confused comment in gsplat/cuda/_wrapper.py says that viewmat is camera to world matrix in fully_fused_projection here.

[BenQLange]

Additionally, a confused comment in gsplat/cuda/_wrapper.py says that viewmat is camera to world matrix in fully_fused_projection here.

Have you resolved it? The documentation about viewmat in fully_fused_projection seems incorrect. Based on the code, viewmat should be a world-to-camera transformation. Am I missing something?

[kaikai23]

Same quesiton here, is the viewmat in fully_fused_projection w2c or c2w?

According to documentation it is c2w, but I've seen some code using it by passing a w2c camera (I meet this problem when reading OctreeGS code that used the fully_fused_projection).

[Ru1zhi]

In general, viewmat refers to the transformation from world space to camera space, i.e., w2c. c2w and w2c are inverse matrices to each other, not transposed. Only the part of the rotation matrix, because it is an orthogonal matrix, has the relationship c2w_R.I = c2w_R.T.
The cuda implementation of the original 3DGS uses many of the matrix operations from opengl math (glm). glm's matrices are stored in column-major order by default, while torch stores matrices in row-major order.
Most of these transpose operations are to ensure that the matrix calculations are correct. In fact you can find in the original 3DGS cuda code that the matrix is on the right when transforming spatial points, this is because of the use of column-major order matrices.