You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many of our post-processing stages are sampling the rendered framebuffers with a texture coordinate which is off by half a pixel.
Our current post-processing shaders sample the rendered depth and color framebuffers via the v_textureCoordinates varying. This varying takes values in [0, 1] across the full-screen quad.
At each fragment, the value of v_textureCoordinates equal the coordinate of the pixel's boundary, rather than its center. This leads to the following errors:
Depth values do not correspond to the computed X and Y coordinates. The depth buffer (in WebGL2) only supports nearest sampling, meaning that the value sampled from the texture is the depth at the pixel center, whereas X and Y are at the pixel boundary.
Interpolation errors in v_textureCoordinates may lead to unpredictability: the pixel just across the boundary may be selected instead of the expected one.
A better option may be to use gl_FragCoord.xy rather than a varying. gl_FragCoord consistently describes the position of the center of the current fragment. See #12201 for an example of this approach, as well as the impact on the post-processing result.
Many of our post-processing stages are sampling the rendered framebuffers with a texture coordinate which is off by half a pixel.
Our current post-processing shaders sample the rendered depth and color framebuffers via the
v_textureCoordinates
varying. This varying takes values in [0, 1] across the full-screen quad.At each fragment, the value of
v_textureCoordinates
equal the coordinate of the pixel's boundary, rather than its center. This leads to the following errors:v_textureCoordinates
may lead to unpredictability: the pixel just across the boundary may be selected instead of the expected one.A better option may be to use
gl_FragCoord.xy
rather than a varying.gl_FragCoord
consistently describes the position of the center of the current fragment. See #12201 for an example of this approach, as well as the impact on the post-processing result.Some things we need to verify:
The text was updated successfully, but these errors were encountered: