Sign in to follow this  
Followers 0
jameszhao00

Reprojection cache precision

9 posts in this topic

Has anyone experienced major precision issues with the reprojection cache?

I'm currently caching indirect lighting computations temporally, and going from screen->world->screen always gives me some minuscule precision issues in xy (+0.0001 ish in pixel coordinates). I tested this precision issue by leaving the scene alone and not moving the camera. In this situation, using 100% of the cached values causes the rendered image to float right/bottom.

Have people experienced this before? If so, how did you mitigate it? Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
This sounds a bit like a missed half pixel offset. Are you sure it's only off by 0.0001 pixels? That would require 10 000 frames (~5 minutes) for the image to move one pixel.
0

Share this post


Link to post
Share on other sites
[quote name='jameszhao00' timestamp='1351464504' post='4994855']
causes the rendered image to float right/bottom
[/quote]That does sound like a [url="http://msdn.microsoft.com/en-us/library/windows/desktop/bb219690(v=vs.85).aspx"]half-pixel offset issue[/url] as mentioned above, however, this is a DX9 specific problem. Which graphics API are you using? Edited by Hodgman
0

Share this post


Link to post
Share on other sites
I'm doing this reprojection in CUDA with cuda textures (aka cuda Arrays). I'm pretty sure that it's not the half pixel offset issue, because if I use the original screen positions (rather than the screen->world->screen computed ones) the picture is stable.
Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
The previous frame is indexed using floating point pixel coordinates like (300, 400). Thought about this a bit more and I think it's some other issue on my end. Purely positive imprecision like +0.00001 shouldn't make the image float bottom right (as a pixel is only taking stuff to the right/bottom of itself)

Screen is integer coordinates. I'm deriving the floating point read locations from the integer screen coordinates. Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
If the floating point coordinates are "texture coordinates" like in regular D3D/GL terms, and you've got some kind of texture filtering active, then you need to be calculating the coordinates for the centre of each texel.
With regular texture coordinates for a 512px wide texture, 300/512 is the coordinate of the left-hand edge of pixel #300 (and the right-hand edge of pixel #299). To sample pixel #300 directly, you need to use the coordinate of 300.5/512.
0

Share this post


Link to post
Share on other sites
Thank you for the tip. I set CUDA to use unnormalized texture coordinates though. CUDA allows you do to do normalized coordinates [0.0, 1.0-1/N] or unnormalized coordinates [0, N-1]. CUDA normalized coordinates seems a bit different from opengl/dx ones anyways, as to purely sample the 2nd pixel in a 2x1 image using normalized coord, we hit coord (0.5,0) [as anything higher goes into border behavior]

Edit:
Should probably test this... as there might be some undocumented intricacies. Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
With cuda you have to add the half pixel offset in both modes. The 2nd pixel in your 2x1 image is either (1.5, 0.5) or (0.75, 0.5) for unnormalized and normalized coordinates respectively.
0

Share this post


Link to post
Share on other sites
Ah thanks. I think I know why I came to the wrong conclusion with my earlier tests. I was reading + sampling textures in the same kernel, and either it's undefined, or it got optimized out.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0