9 replies to this topic

[jameszhao00]

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, 28 October 2012 - 08:51 PM.

[Ohforf sake]

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.

[Hodgman]

causes the rendered image to float right/bottom

That does sound like a half-pixel offset issue as mentioned above, however, this is a DX9 specific problem. Which graphics API are you using?

Edited by Hodgman, 02 November 2012 - 07:07 AM.

[jameszhao00]

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, 06 November 2012 - 12:15 PM.

[Hodgman]

Do you deal with texture coordinates at all, or is it all integer indexing? Likewise for the screen -- are pixels indexed, or do you paint to floating point positions?

[jameszhao00]

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, 06 November 2012 - 07:49 PM.

[Hodgman]

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.

[jameszhao00]

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, 06 November 2012 - 11:22 PM.

[Ohforf sake]

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.

[jameszhao00]

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.