Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is the projmatrix in cam the same to first frame? #118

Open
Yoona12 opened this issue Jun 17, 2024 · 5 comments
Open

Why is the projmatrix in cam the same to first frame? #118

Yoona12 opened this issue Jun 17, 2024 · 5 comments
Labels
question Further information is requested

Comments

@Yoona12
Copy link

Yoona12 commented Jun 17, 2024

Thanks for your great work!
When i read the code, i have following question.
With camera moving, the viewmatrix of camera is changing,and thus the projmatrix is changing.
But in the code, with camera moving, the cam is the same to the first frame all the time.

@Nik-V9
Copy link
Contributor

Nik-V9 commented Jun 19, 2024

Hi, Thanks for the interest in our work!

In SplaTAM, we fix the viewing camera to the first frame (this is the world frame). For subsequent cameras, rather than defining a new viewing camera, we project the Gaussians to the first frame (that is the world frame). Hence, we don't need to change the viewing camera for the rasterizer.

Please refer to the following comments and let me know if this answers your query:

  1. Confusion about 'transformed_params2depthplussilhouette' function #52 (comment)
  2. Q about pose estimation #28 (comment)

@Nik-V9 Nik-V9 added the question Further information is requested label Jun 19, 2024
@DeepDuke
Copy link

Hi, I have the same question. Before rendering, the Gaussians are transformed to the current frame. If the viewing matrix is fixed to the first frame, shouldn't we render the transformed Gaussians in the current frame? It looks strange to render at the first frame view. Could u please help explain more, thanks a lot! @Nik-V9

@DeepDuke
Copy link

Another question is about calculating the loss. If the rendered images are viewed from the first frame, how do u compute the loss with ground truth images that are observed at different frames?

@Nik-V9
Copy link
Contributor

Nik-V9 commented Aug 29, 2024

Hi, as I mentioned before, the reference frame is fixed to the first frame, and the Gaussians (pointclouds) are just transformed into the frame of the reference frame for rasterization.

"For subsequent cameras, rather than defining a new viewing camera, we project the Gaussians to the first frame (the world frame). Hence, we don't need to change the viewing camera for the rasterizer."

Hence, the renderings for the current view will represent the current camera, and you can apply rendering losses.

@Rashfu
Copy link

Rashfu commented Sep 21, 2024

@Nik-V9 Thank you for your explanation of coordinate transformations in the related issues. However, I'm not sure if my understanding is correct, so I tried to summarize my understanding as follows. Please point out if there are any mistakes.

In the get_pointcloud function, the point cloud for the first frame undergoes c2w @ pts4.T, which means that params['means3D'] always stores the positions in the world coordinate system, rather than treating the first frame directly as the world coordinate system. If the rendered viewpoint is always fixed at the first frame, then the 3D Gaussians in the world coordinate system need to be transformed by the pose of the current frame relative to the first frame for each rendering (similar to relative motion). This is also the meaning of params['cam_unnorm_rots'] and params['cam_trans'] defined here. Therefore, in the transform_to_frame function, rel_w2c here essentially transforms 3DGS to the camera coordinate system of the first frame to get transformed_pts, rather than the camera coordinate system of the current frame.

But based on my understanding, why does transformed_params2depthplussilhouette additionally require curr_data['w2c'], while transformed_params2rendervar does not? Aren't the transformed_pts already in the first frame's coordinate system?

Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants