Transparency / visibility is determined only by object center, not per face.

[jandanek]

Dear Colleagues,

When trying to use X3DOM in our project, we have realized that transparent objects visibility is determined not "per face", but only based on distances from objects centers, and parts of overlapping transparent objects are not rendered as transparent.

See minimal example below - 3 overlapping semi-transparent spheres have centers in the same distance from the default viewpoint. Navigating a small distance from the default viewpoint (examining etc.) causes abrupt changes in scene rendering.

Please advise if this behaviour can be avoided by some X3D modelling practice, or it is a known bug that will need to be addressed. This might be similar to #437 , but I cannot access thereto associated models anymore.

In the ZIP file there is the X3D file, together with expected - correct rendering of all spheres.

Thanks, Jan

x3dom_transparency_spheres.zip

[jandanek]

Screenshots to illustrate the issue: X3DOM:

The transparency should look similar to this render, without abrupt changes to sphere segments visibility:

[andreasplesch]

also see #1053

[jandanek]

Thanks, I see also #498, very similar if not the same, will try suggestions there (although things should still work without manual fiddling with sort order and texture files opacity, so this is still an issue).

[andreasplesch]

Yes, x3dom does not deal very well with transparency and there is lots of room for improvement. It just would require a deep dive, unfortunately.

The most distracting issue is the total change in per segment visibility which is a result of depth testing. One can disable depth testing with DepthMode:

https://gist.githack.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270/raw/ede3b0f9a2f712a7de4dacde42be25f5495badd9/x3dom_simple_transparency.html

https://gist.github.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270

There is still flipping when back to front sorting changes based on the center of the shape.

But then opaque shapes get overdrawn as well because they are drawn first. A simple workaround is to force sorting by adding some nominal transparency (or sortType='transparent'):

https://gist.github.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270#file-x3dom_simple_opaque_with_transparency-html

https://gist.githack.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270/raw/8a8d703cf2bd22601a61a88f7e64b14f9419edf3/x3dom_simple_opaque_with_transparency.html

[andreasplesch]

https://jcgt.org/published/0002/02/09/ seems like a popular approach for order independent transparency. https://habr.com/en/post/457292/

https://github.com/mrdoob/three.js/issues/9977 https://github.com/mrdoob/three.js/pull/24903

[andreasplesch]

After some study, I found that x3dom does not quite implement the regular transparent rendering process. Rather than disabling the depth test completely, only the writing to the depth buffer should be disabled while rendering transparent objects.

This can be accomplished with a different DepthMode by setting readonly='true' which is rather obscure :

https://gist.github.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270#file-x3dom_simple_realopaque_with_transparency-html

https://gist.githack.com/andreasplesch/ee36e45ed9a3ffbea32ab9d3a0131270/raw/e58ced1e7cc467be2e656c7db96defe11c54cd15/x3dom_simple_realopaque_with_transparency.html

As a result, opaque shapes can be used normally. The readonly DepthMode should probably be the default for transparent objects.

[andreasplesch]

The dev version now has readonly DepthMode by default for transparent shapes. This means that transparent shapes are completely rendered when behind other transparent shapes.

[jandanek]

Hi Andreas, Thanks for your looking into this and for the quick fix. The result above is far better, indeed. The center-based sort order will perhaps take more time to do it proper ;-) All the best, Jan

[andreasplesch]

Let me close this issue since sorting by center is rather standard practice. Please feel to reopen whenever convenient.