[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Public WebGL] Centroid sampling makes conformance tests fail?
Hi all,
I'm a contributor to the ANGLE project, which implements OpenGL ES 2.0
on Windows using Direct3D 9, and is used by Chrome and Firefox for
implementing WebGL. Me and others have recently run into some issues
which turn out to be caused by centroid sampling. But it doesn't appear
that ANGLE is strictly speaking at fault, so I'm looking for some input
on how to best deal with the issues...
The first one is that ANGLE "fails" to pass the WebGL conformance test
for OES_standard_derivatives, on some hardware:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/extensions/oes-standard-derivatives.html.
Although the resulting images are very dark, there is actually a
different output along the diagonal. This is due to anti-aliasing being
on (which is the default for WebGL), and Direct3D 9 can use centroid
sampling in this case, which also affects the derivatives (which compute
the difference in varying value between neighboring pixels). The second
issue is closely related:
http://code.google.com/p/angleproject/issues/detail?id=340. Because
centroid sampling moves the location where the pixel is evaluated, and
then applies the result to all covered samples, some places may appear
to have shifted texels. And because the derivatives are also used to
determine the mipmap LOD level, centroid sampling may affect that as well.
Using centroid sampling appears to be entirely within spec. The OpenGL
ES 2.0 specification section 4.3.5 on varyings states that: "If
single-sampling, the interpolated value is for the fragment center. If
multi-sampling, the interpolated value can be anywhere within the pixel,
including the fragment center or one of the fragment samples." Also, the
OES_standard_derivatives extension suggests, but does not require, that
"Functions should be evaluated within the interior of a primitive
(interpolated, not extrapolated)."
This means that when anti-aliasing is enabled, there is a lot of leeway
in what the result can look like! Hence I believe that the majority of
the WebGL conformance tests should not be using anti-aliasing, unless
that's explicitly part of the test. The alternative would be to not test
values near the edges of polygons, although that seems quite haphazard
and there's still no guarantee that all anti-aliasing implementations
will evaluate the pixel at the center even when nowhere near an edge
(think of quincunx anti-aliasing for instance).
It seems rather unfortunate to me that WebGL defaults to enabling
anti-aliasing, given how much it can make the result differ between
fully compliant implementations. Also, while it's possible to prevent
ANGLE from using centroid sampling, it's not an easy thing to do, and
there are actually cases where centroid sampling is valuable (which is
why it exists in the first place).
So I'd like to know what other people's take on this is. Is it correct
that the conformance tests make wrong assumptions and ANGLE is
compliant? Or should we do whatever is necessary to prevent ANGLE from
using centroid sampling? How can the issue of getting unexpected results
because anti-aliasing is on by default be dealt with?
Thank you for your input!
Kind regards,
Nicolas Capens
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------