Hello all, I was wondering if anyone has run into a problem like this in the past:
We’re using Maya to rig and animate characters made of flats (who are viewed through an orthographic lens.) The textures are transparent .pngs. Typically, everything has been working well. However, we sometimes run into the issue seen here (pview):
This isn’t Z-fighting, at least not in the sense that I’m used to seeing it. The planes don’t “fight” with one another, or flicker, it’s just as if the graphics card is looking at the model’s nearest plane and assigning the transparency for the entire model based on that plane.
Here’s a view in Maya from the side. (taken at around the same frame of animation, where hand should be in front of torso and face.) You can see in the pview screenshot above that the hand is correctly not “greying” out the body, but only the head.
I have asked my artist to maintain at least one unit of distance between planes. But this doesn’t seem to be related to distance in a way that I understand.
Any thoughts? Thanks!
Heh, now that i’m reviewing my post, I notice the way the hand’s joint comes off the character’s shoulder instead of elbow. I wonder if that is causing the problem.
This is self-occluding transparency, a common difficulty with 3-D rendering. The problem is described here:
The fundamental problem is that your character is automatically converted as a single Geom, by Panda’s optimization, which means Panda draws the character in one pass, and so cannot sort the parts of your model from back-to-front for correct transparency.
The linked page describes several possible solutions. Three particularly good solutions in your case are:
(a) Use dual mode transparency, either by hand-editing the egg file as suggested in the linked page, or by using the command at runtime:
(b) Turn off depth testing, since your model is just a flat and will be drawn with an orthographic lens anyway, with:
© Override Panda’s default optimization, and separate the individual pieces of the model so that Panda will render them in multiple passes, and can therefore sort the relative pieces back-to-front.
Of the above solutions, only (b) incurs no performance hit at all, but the hits for (a) and © are probably very small.
Thank you kindly, David! I apologize for not searching the manual thoroughly enough… I spent 30 or 40 minutes searching the forums, trying to make sure no one else had asked this question, and didn’t find anything. This should clear it right up!