Transparent objects not writing to depth buffer (setDepthBufferWrites missing)

[Rellik]

Hello jPCT is great so far, but it seems like there might be an oversight in not bringing Object3D.setDepthBufferWrites over to the Android version.

My project makes use of textures with embedded alpha channels to allow for easily rendering skeletally-animated "paper dolls" using only a quad per limb or so.  Unfortunately Object3D's that have transparency enabled (using setTransparency(1)) don't write to the depth buffer - you can see the result of this in the attached image.



On the left is without transparency enabled (you see the correct draw order, with the legs behind the skirt) and on the right transparency enabled but draw order is out of whack (for instance the legs are in front of the skirt).

The documentation for Object3D.setDepthBufferWrites specifies that "This is only important when using the software renderer." so I imagine that it was left out for the Android port because there's no software renderer.  However, I think this function would save me here, because I don't want to do my project demo on Wednesday with wrong z-order  - am I wrong in my assessment, or is there any other workaround, or would it be possible to get a version that includes this function?

[EgonOlsen]

The behaviour for transparent objects is, that they will be rendered back to front sorted by the object's center in camera space. In your case, these points are either the same or very similar so that rounding errors may stack up.
Making transparent objects write into the zbuffer usually isn't a good idea, because it's not limited to the opaque areas, which means that any area that is black in your first picture would exclude anything sorted behind it from being drawn at all. For the software renderer in desktop jPCT, this is different because i have full control of the pipeline and can exclude the black areas from writing into the depth buffer.
You might want to try to use Object3D.setSortOffset() on each limb to guarantee a sort order as it seems to me, that the order in which the parts should be drawn is more or less fixed and may change only if orientation changes!?

[Rellik]

Really useful info - thanks for the help!

I think ultimately the problem was that I wasn't calling Object3D.build on the Animated3D's deserialized from raft's Bones system.  That meant that Object3D.calcCenter was never called, meaning getCenter always returned 0,0,0, hence the arbitrary ordering.