[ quesa-Feature Requests-895117 ] Support custom sorting for transparent surfaces

[SourceForge.net <no...@so...>]

Feature Requests item #895117, was opened at 2004-02-11 20:13
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=895117&group_id=45158

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Frank Condello (pox)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Support custom sorting for transparent surfaces

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Dair Grant (grantd)
Date: 2004-04-26 20:45

Message:
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.

----------------------------------------------------------------------

Comment By: Dair Grant (grantd)
Date: 2004-02-19 20:45

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442055&aid=895117&group_id=45158