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

Question about rho3, rho2 and depth computation choice #177

Open
fetian-code opened this issue Nov 19, 2024 · 6 comments
Open

Question about rho3, rho2 and depth computation choice #177

fetian-code opened this issue Nov 19, 2024 · 6 comments

Comments

@fetian-code
Copy link

The depth intersection is computed by
float depth = (rho3d <= rho2d) ? (s.x * Tw.x + s.y * Tw.y) + Tw.z : Tw.z;
I understand (s.x * Tw.x + s.y * Tw.y) + Tw.z is the depth according to Eq. (7), but why the depth is Tw.z when the 2D image-space exponential larger than 3D?

Thanks in advance

@hbb1
Copy link
Owner

hbb1 commented Nov 19, 2024

Hi, In my latest commit, I have already made the change, which fixes a minor issue reported by others, see #174

@fetian-code
Copy link
Author

Hi, In my latest commit, I have already made the change, which fixes a minor issue reported by others, see #174

Thanks for your quick reply! I just thought perhaps when we replace object-space Gaussian with screen-space Gaussian, it makes sense to use Tw.z. Because the screen-space filter seems to be equivalent to constructing a 2D Gaussian perpendicular to the image plane at the center of the object-space Gaussian, then the computed depth should be the depth of the Gaussian center, which is Tw.z.

Does it make sense? Or, would you mind to let me know the reason you used Tw.z here at the first.

@hbb1
Copy link
Owner

hbb1 commented Nov 22, 2024

Hi. This is exact what I thought at the beginning and I also aimed to avoid numerical issue (if any). But after a twice think, I believe using the splat depth is more reasonable because the low pass filter is for pre-filtering not a real 3D reconstruction filter. This means, changing the sampling rate (e.g., rendering resolution, FOV) should not affect the underlying 3D scene representation. So that I switch back to the splat depth instead of point depth Tw.z. I also benchmarked on several data and see no significant differences.

@fetian-code
Copy link
Author

I see. Thanks very much for your answer.

@fetian-code
Copy link
Author

Hi. I just came up with a new question about the depth gradient computation when we use the 2D low pass filter. Since we always use s.x * Tw.x + s.y * Tw.y + Tw.z as the depth, why neglect the gradient propagation of s.x and s.y when rho3d > rho2d in the backward code? Or maybe you have tested and found no difference whether we neglect it.

image

@hbb1
Copy link
Owner

hbb1 commented Dec 4, 2024

No obvious differences. The main reason is that low pass filter is a rare case so backpropagating to the center would be sufficient.

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

No branches or pull requests

2 participants