Transparent Object and ZBuffer

[Jakes]

Hello,

I've been working with transparent objects (in this case, sprites with transparent cutout, like leaves and branches), and knowing that transparency doesnt write to zbuffer, I was expecting to experience some known cases, but instead I'm experiencing different results, as you can see below:

Expected results:

Right: Good Result.
Left:   it is known that this scenario could happen when the red circle in the back is drawn last, so the area of the blue circle will then occlude the red circle due to the zbuffer.

Experienced results:

Right: Good Result.
Left: This wasn't what I was expecting, mainly because the red circle in the back should be depth tested and therefore be drawin behind the blue circle, even when using transparency, the only artifcat I should expect would be clipping and not overlapping. Is there any ZbufferCheck not being made when using transparent objects?

Regards,
Jakes

[EgonOlsen]

Not sure what you mean exactly. Transparent objects don't write into the zbuffer, just like you've mentioned. If the red circle is depth tested, it's only depth tested against objects that are present in the depth buffer. If both objects are transparent, they will both be tested, but none will write into the depth buffer, so their order depends on their sorting which be correct in some cases but wrong in others. Or didn't I get your question correctly?

[Jakes]

Yes, but how do I know if they are being delph checked? is there any option to set that per object?
or are all the objects ignoring the zbuffer when set to transparent by the Object.setTransparent()?

because I'm having the last behaviour instead of the first one, which would be expected, right?

[EgonOlsen]

They are all checked but they don't write. Regarding your examples, I'm still sure how to read them. Are these red and blue disc both transparent or just one of it?

[Jakes]

Both are transparent planes one in front of the other regarding the camera position.
the order would be:

Red Circle Plane
      ⬆️
Blue Circle Plane
      ⬆️
Camera

[Jakes]

You saíd that they dont write to zbuffer, is that it? is there any reason why? aside from not writing the alpha values of course, they should write their values as being a normal plane, no?

[EgonOlsen]

They can't write into the depth buffer and that causes the effect that you see here. Imagine a tree with lots of foliage. Depending on the view angle, the drawing order of it's polygons might be back to front (fine for transparency) or front to back or something in between (most likely). If they would write into the depth buffer, all foliage that's rendered first would block everything that's behind it and that just doesn't look right. That includes completely transparent areas, because depth checks and writes happen before the actual rendering. That's just how it works, I'm afraid. Your planes are being sorted (if they are different objects) by using the simple, so called, painter's algorithm, but that's never perfect. If there is a set order that's the same in every case, you can apply a zsort-offset with some method in Object3D, but that's not applicable in most applications.
Another way to fight this problem, is to use a custom shader that doesn't do transparency but some kind of stippling instead. I did that for some trees in my game Naroth. Birch and oak trees are rendered as transparent objects, so that there might be unwanted polygon overlaps, but you hardly notice them if you don't watch closely. Pine trees on the other hand are rendered using stippling.

[Jakes]

Yeah, I know that what I was expecting was the issue with the painters algorithm, and that was what I was expecting, because even if I wanted to used the discard method on a shader, the plane in the back would still overlap with the front plane, so thats why I was asking if there is a way to force those planes to write to the buffer, even if the clipping were to happen, and then I would sort them myself or even use a shader to discard the pixels I dont want to be written to the zbuffer. in that case the rendering would appear fine.

[EgonOlsen]

You really don't want them to write into the buffer, because you would get the exact same problems with ordering, just worse. If you know the order, you can use the mentioned z-offset method to "sort" them beforehand. Or use a custom shader to discard the pixels yourself on non-transparent objects if that's an option.