Menu
▾
▴
#1 Support custom sorting for transparent surfaces
The transparent surface renderer broke when the new view
transform API was added. Vertices outside the frustum can become
undefined, leading to infinite point errors and jumbled geometry.
This may also adversely affect the sorting algorithm.
Some other issues that may or may not be related involve an
errant lighting state. Transparent objects may inherit the
illumination style of other objects in the scene rather than use their
own, and faceted geometry (interpolation style none) always
appears with null shading.
Logged In: YES
user_id=439944
It looks like this isn't related to the transform changes: as far as I can
see, things are sorted as well in frustum space as they were in world
coordinates (i.e., attached model also renders with flicker under 1.6d18).
It looks like the problem is in the sorting choices made when triangles
overlap in z: that overlap can be in world coordinates or frustum
coordinates, but removing the current selection choice gives us a much
more stable selection (for this case, but that won't be a fix).
I can't see any problems with sorting in frustum coordinates when the
vertices are outside the frustum - those vertices will be clipped later on,
but being outside the frustum won't affect the sort.
The lighting flicker appears to be due to the triangle order jumping
around from frame to frame - if you still see any illumination problems
when this bug is closed, can you log them as separate bugs?
Test model
Logged In: YES
user_id=439944
After trying various techniques, I haven't really been able to improve the
appearance of this scene. There's a discussion of the "best you can do"
for painters-algorithm style rendering at:
<http://groups.google.com/groups?
&selm=5qmkhg%24mhh%241%40java.imsa.edu>
One thing mentioned there is to perform a cheap test on x/y extents first
before looking at overlaps in z. We now do this, and it improves the test
boxes slightly - but not enough to classify them as resolved.
I've attached some sample models to this bug, which might be useful for
further debugging - from these you can see that at least some of the
boxes have an inconsistent orientation (some faces are CW, some are
CCW) which accounts for some of the flicker.
Probably the only way to resolve this arbitrarily is to allow for a custom
sorting callback, so that an application which can't use the default
approach can supply its own callback to resolve overlaps and produce a
determinant ordering.
Sorting test cases