Bounding Spheres: Alpha Sort

[Michael Lobko-Lobanovsky]

Mesh bounding spheres (radii and center points) stored in the respective mesh structures can be used in real time to sort alpha-transparent meshes based on their current distances from the camera.

In order to let overlapping alpha-transparent materials blend correctly over one another, the most distant of them should be rendered the first, and the closest ones, the last.

Suppose we have a 3D model that comprises three semi-transparent gemstone meshes. When the model is loaded in the viewer, the order in which the meshes are going to be rendered is determined by the order in which they appear in the model file. Thus, if we look at the leftmost screenshot below, we can see that the blue gemstone mesh that appears in the model file the first is always rendered the first in all ObjReaders as well as in FBSL Objector if it has its runtime alpha sorting feature disabled. As a result, the gemstones appear opaque even though they are in fact transparent; wrong rendering order wouldn't allow OpenGL to read its depth buffer correctly when trying to blend the gemstone colors on the screen.

In order to correct this, Objector recalculates the distances between the camera and alpha-transparent mesh centers whenever the model is rotated and/or moved with the mouse. Based on the calculations, the alpha-transparent mesh indices in the mesh array are swapped according to the distances in such a way that the currently most distant alpha mesh would be rendered in the current render frame the first, and the closest one, the last.

The effect of runtime alpha sorting is shown in the rightmost screenshot below. Regardless of how the model is currently orientated with the mouse, the overlapping areas of semi-transparent gemstones will always be color-blended correctly.

The method has certain restrictions though. For example, it can't resolve transparent meshes that appear inside the other transparent meshes, like for example, a volume of beer inside a glass, or if some polygons of one transparent mesh are interleaved with the polygons of another transparent mesh, like for example, separate blades of grass. And also, like in all floating-pont comparisons that can only be so much precise, FPU inexactness can lead to occasional artifacts when OpenGL can't determine correctly exactly which mesh is the farthest, and which one, the closest.

A zip with short AVI sequences to illustrate the technique is also attached below.

(to be continued)

[Patrice Terrier]

Thank you for the video.

It makes obvious that the blue mesh transparency is preserved in the RealTimeAlphaSort, while it is not in AlphaUnsorted mode.

...

[Patrice Terrier]

Mike

In version 1.01

I may have found a small issue with the new bounding sphere alpha sort, the symptom is that a few meshes are not shown at startup, however they become visible as soon as we move the mouse, may be a missing gP.redraw somewhere.

...

[Michael Lobko-Lobanovsky]

Patrice,

1. ObjReader v1.01 does not implement either dynamic alpha sort or nicer-looking inertial rotation/panning/zoom of the model (Objector implements both) because to have them implemented, I need a 100% foolprooof ability to instantly switch the renderer programmatically between unhindered continuous (currently non-existent) and one-frame mouse-button-down-only (currently available) render modes. If you provide a corresponding reliable programmatic toggle between those two modes then I can try and add this functionality to ObjReader as well.

2. ObjReader v1.01 does implement per-draw visibility frustum culling of every mesh in the model though written in C and not in assembler, it performs slower than in Objector. It can be seen in extreme multi-mesh models like the recent Mars One Base I sent you a while ago. It performs about 30K matrix maths visibility tests in each render frame and runs much, much smoother, almost as smooth as a one-mesh model, in Objector because I now have the entire drawUsingPPL() routine written in assembly rather than C or BASIC.

Off the top of my head, there may be three possible causes for the artifact you're pointing out:
-- our renderers may have different minute transitional states while loading the model because neither our code nor programming languages are similar, so that the final initially loaded state of the model (the mesh order in particular) are not the same;
-- our renderers definitely have different alpha mesh sorting routines because yours is based on the C-plusplus-ish vector sort while Objector's is based on standard C quick sort callback, and PowerBASIC is a total black box. Have you noticed that complex alpha models often end up looking different in C++ and PB ObjReaders?
-- nVidia's OpenGL drivers have an ability to buffer render frames on their own accord (see user-defined settings in the nVidia Control Center) so that you cannot always make OpenGL flush its cache in the current frame even if you try and use glFinish()/glFlush() in your code. The driver takes its own decisions in that regard, and you can't always control it programmatically because its a closed-source proprietary software/hardware symbiosis with a generally undocumented API. Certain behaviors can be changed only from the nVidia Control Center and only on the per-application level, alas.

In any case, we will need a simple, reliable and reproducible test case to try and debug this artifact at a finer level.

[Patrice Terrier]

Mike

This is not systematic, it occures while i am changing the meshes, and using drag and drop to update the model shown in ObjReader (mostly because i am in design mode and doing much changes on both material and meshes, with more than 3 millions triangles and 83 meshes).

As i said before, we fall back on our feet as soon as i moving the model, thus the easiest solution would be to force a redraw.

(see in the WIP section the temporary BAC_MONO.zip file)

...