Bug: Flexible and transparent draw order issues.

When you have have a transparent flex prim before a nonflex transparent prim, the nonflex prim is drawn before the flex prim.

flex on


flex off


version 1.9.1(21)

seems to have to do with the angle that you look at it

<object classid=\"\"\"\"\"clsid<img\"\"\"\" src="%20images/smilies/biggrin.gif=" alt="" title="Big Grin" class="inlineimg" border="0"> <embed name=\"\"\"\"\"flexbug01\"\"\"\"\" src="http://www.fransinnovations.com/pics/flexbug01.swf" quality="high" bgcolor="#FFFFFF" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" height="100" width="100">
</object>

Transparency-sorting in SL never was an exact science... and likely won't ever be. :/

Yeah I suspect it may be a known alpha issue that's still around, I reported this but it seems to happen in 1.9.0 as well (obviously not for flex prims!). Changing the flex-prim state will likely cause SL to re-render the object, incurring the bug, or the box is shifting ever so slightly to an angle at which the error occurs.

Although I thought Open GL handled the rendering order of 3d objects, but I'm not that knowledgeable, hopefully it'll be fixed, I'm noticing it more and more lately

Traditional modern 3d hardware (whether used by OpenGL, D3D, or whatever) makes Z-ordering relative to opaque objects quite effortlessly correct to the application.

For transparent objects, the hardware suddenly offers very little help for this and it's generally up to the application. Apps that have to deal with this in real-time can do their own sloppy draw-ordering like SL does. Note that such a solution simply rearranging the draw-order of objects, faces, or even the tesselated triangles can never guarantee correctness for many surprisingly simple-seeming cases; the 'correct' solution for these cases involves face-splitting which is not currently a cheap enough technique to do on a large scale in real-time.