Multiple Transparent Objects

[chilly willy]

Ogre Version: latest
Operating System: macOS 10.15.5
Render System: OpenGL 3+

I have transparent contents inside transparent containers. Each of the contents are implemented as a Mesh/Entity, separate from the container's Mesh/Entity, but on the same SceneNode. Sometimes when I run the program the contents appear very transparent and other times very opaque:

As I understand, when multiple transparent objects are drawn, they need to be sorted by depth, and Ogre automatically does this. I thought the issue might have something to do with that but I noticed a couple peculiarities:

• The transparency/opacity does not change with camera angle or distance. It stays the same for the duration of the program execution.
• The beer in the two glasses are always the same as each other, either both very transparent or both very opaque.
• There are also six beer bottles in a crate. The beer in the six bottles are always the same as each other, but not always the same as the beer in the drinking glasses.

This makes me think that the artifact has to do with the materials (3 of them) rather than the objects (2+2+6+6 of them).

Any ideas? I wanted to try stepping through the depth-sorting code but couldn't even find it.

(I made sure nobody is drinking or diluting the beer!)

[paroj]

This is the sorting code: https://github.com/OGRECave/ogre/blob/3 ... ng.cpp#L36

Note that the sorting is based on the position of the parent node. Since this yields the same distance for all of your objects, it falls back to sorting by the pass pointer, which explains the behavior you're seeing.
While there are several workarounds for this, the best solution is likely the following: https://www.ogre3d.org/2021/08/14/ogre- ... -additions

edit: fixed the run-to-run inconsistency:
https://github.com/OGRECave/ogre/commit ... 257c8b345e

[rpgplayerrobin]

You could also try doing this:

Code: Select all

liquid_entity->setRenderQueueGroup(Ogre::RENDER_QUEUE_MAIN + 1);
container_entity->setRenderQueueGroup(Ogre::RENDER_QUEUE_MAIN);

or:

Code: Select all

liquid_entity->setRenderQueueGroup(Ogre::RENDER_QUEUE_MAIN);
container_entity->setRenderQueueGroup(Ogre::RENDER_QUEUE_MAIN + 1);

That should (I think?) make your sorting deterministic and not random on startup.

Note that this code has nothing to do with performance, it just has to do with which is rendered first, forcing the sorting instead of relying on an automatic one.

I actually use the same code in my game to sort normal solid objects to get a higher FPS, as bigger objects that cover a lot of pixels should be rendered before the ground, etc, which boosted my FPS by maybe 20%.
This can be checked with RenderDoc for example, to see what is being rendered first.

[chilly willy]

Thank you guys for the responses.

Manually setting the render queue worked well for a quick solution (with RENDER_QUEUE_TRANSPARENTS and RENDER_QUEUE_TRANSPARENTS + 1 so both are drawn after the regular materials).

I will learn about WBOIT and probably use it for the long-term solution as it seems like it will also correctly handle the far side of the container behind the contents.

paroj, just out of curiosity, in the new DistanceSort, why compare the pass hashes at all? Why not let equal distances evaluate as equivalent and preserve their original, deterministic input order, regardless of pass hash?

[paroj]

Sorting by pass reduces state changes and should be faster, though this is admittedly a rather narrow corner case.