Transparency versus depth buffer

Engines, Libraries and Tools Xith3D Forums
#1

It looks for me that there is a small incompatibility in xith3d versus java3d. AFAIK, in java3d, setting TransparencyAttributes marked shape as transparent, which meant checking depth buffer, but not updating it. In xith3d, I need to explicitly set RenderingAttributes to avoid writing to depth buffer.

While this workaround is not hard, does it make sense to have transparent objects which at the same time write to depth buffer ? If not, it might be good to automagically avoid writes to depth buffer for anything with transparency set to BLENDED.

#2

Hi,

In Java3D there is also View-level option for that:

Quote from Java3D JavaDoc:

[quote]public void setDepthBufferFreezeTransparent(boolean flag)

Enables or disables automatic freezing of the depth buffer for objects rendered during the transparent rendering pass (i.e., objects rendered using alpha blending) for this view. If enabled, depth buffer writes will be disabled during the transparent rendering pass regardless of the value of the depth buffer write enable flag in the RenderingAttributes object for a particular node. This flag is enabled by default.
[/quote]
In Java3D, behavior of RenderingAttributes.setDepthBufferWriteEnable can be overriden by option in View, but I don’t think this is a good idea, because of if option in View is set, we loose fine-grained control over transparent pass.

[quote]does it make sense to have transparent objects which at the same time write to depth buffer ?
[/quote]
Just in some rare cases.

[quote]If not, it might be good to automagically avoid writes to depth buffer for anything with transparency set to BLENDED.
[/quote]
Two points:

  1. In this case, we will loose some predictability of behavior, where single OpenGL state flag controlled from different places, which may cause some confusion (say, “I enable writing to depth buffer, and it is still disabled”).

  2. In current Xith3D implementation, Transparency and Rendering attributes are independent units and handled by separate independent shaders. Introducing dependency of RenderingAttributes on TransparencyAttributes will also require non-trivial change in OpenGL state management code.

Yuri

#3

…and, as of simple user-side code, maybe we should provide some factory methods/constructors for easy creation of RenderingAttributes based on TransparencyAttributes, or something like this?

Yuri

#4

Maybe just something like a bit of automagic to transparency attribute setter - if RenderingAttributes is null, create new one with depth-writer-disabled, in other case, leave it as it is. Unfortunately, we would also probably need to remember if it is auto set, so if transparency attributes are cleared later, it will be also cleared if not modified.