[RVGL Shader version] Translucent faces issue

Report issues and bugs here.
User avatar
Posts: 116
Joined: Thu Dec 07, 2017 9:04 pm

Re-Volt [RVGL Shader version] Translucent faces issue

Unread post by Kiwi » Mon Jun 25, 2018 7:01 am

Hello RVGL-developers,

I'm experiencing issues with translucent faces in the shader-version of RVGL.

I have big windows in my level. This window-faces have the "translucent" checkbox enabled, and have an alpha-transparency value set. (I think 50% gray).

Outside the window I also have some translucent faces (shower-boxes, plants). As well, I am using makeitgood spark-generator objects for fire and steam effects.

When looking from the inside to the outside through this big windows, the translucent faces on the outside are visible, like there are no windows at all. The same for the spark-generator effects:


Enlarged and brightened, so you can see it better:


It seems, they will be drawn before the windows.

Is this a known issue with the shader version, a bug, or do I something wrong?

Ciao, Kiwi
User avatar
Posts: 85
Joined: Wed Dec 06, 2017 5:54 am
Discord: Huki#1668

Re: [RVGL Shader version] Translucent faces issue

Unread post by Huki » Fri Jul 06, 2018 4:46 pm

Translucent polygons are supposed to be alpha sorted, i.e., rendered from back to front. The shader renderer does not do per-poly alpha sorting, but rather sorts each mesh relative to one another, based on the farthest point on its bounding sphere. The mesh may be a world mesh (internally called "cube") or a model / instance.

Meshes that are completely enclosed within the bounding sphere of another are always drawn in front. For example, if your glass window were to be a huge quad, its bounding sphere will engulf small meshes behind it (like plants) and this results in incorrect sorting. The below sketch can help visualize your problem:


The solution is to chop up your glass window into smaller meshes such that its bounding sphere is reasonably small. Here's a fixed sketch:


Special effects such as sparks and skidmarks are an exception - these are never sorted and will always appear in front of other translucent meshes. This is done for performance reasons, but I can consider enabling it as an option. In fact, it's something I already experimented with. I have some screenshots from precisely an year ago (hey, even the time is close...).


Below is the comparison I did. The numbers say we're processing 8 different objects and we were able to aggregate them into 4 groups before drawing. All the skidmarks together form a single object, and they can't be sorted.


Below is the same scene with sorting enabled. We now have to process each skidmark section individually in order to sort them, resulting in 746 objects in all. Rendering each of them individually would drastically impact performance. Fortunately, we find that we can actually aggregate everything into 5 groups - just one more than before. The skidmarks behind the pickup form one group, and those in front of the pickup form another. So the performance impact in this scenario is minimal.

Post Reply