Hi,
I have some problems with the rendering order of objects in the transparency queue. It looks like the render order is decided by the distance to the object’s center and not by the objects geometry? This seems to cause some unfortunate cases where objects behind other objects are drawn in front instead.
In the images below I’ve tried to illustrate the problem. The scene contains 3 Quads, all with the same texture blended with different colors. The red Quad is on top, the green is in the center and the blue is at the bottom. In all four images below, the red Quad should actually show in front of the other two, and the green in front of the blue, but as you see, when I change the angle of the view, the rendering order gets messed up.
Is this a problem with JME? I saw a mention about a fix in this post: http://hub.jmonkeyengine.org/groups/development-discussion-jme3/forum/topic/transparency-problem-2/, but I’m not sure if it’s the same problem or not. If it is, does this mean it only works for the latest version of JME3?
Now I have to mention that the application I’m working on is a few years old, and is still using the old JME1. We’re planning on porting to JME2 or maybe 3, but for certain reasons we can’t do that just yet. I know JME1 is outdated, but if anyone knows if theres some workaround for this problem that might work for JME1 as well, that would be great. If no workaround is available, it would still be very nice to know if this problem will be solved by making the change to JME2 or 3.
Thanks in advance for any help.
This one should be fairly easy, jME3 and jME1 still use the same RenderQueue system, so all you have to do is port the TransparentComparator from jME3 to jME1.
Thanks for the quick reply!
I looked up the TransparentComparator from JME3, and “stole” the new distanceToCam method where you check for distanceToEdge instead. However, this does not solve my problem, it actually makes it worse in my case. If you look at the images in my previous post, in both image 3 and 4, using the distance to the closest edge will tell us that both the blue and green quad is in front of the red one, although the red one should actually be in front.
I’ve been thinking abit about this, and I’ve been wondering… I’m no expert in 3D graphics, but I have a few general ideas. I know that the transparent queue is rendered back to front, and the “opaque queue” is rendered front to back. You’d still need some sort of render order to get the solid objects rendered correctly. If I don’t put my quads in the transparent queue, I get a few artifacts with the alpha along the edges and stuff, but the render order is always correct… How come JME gets the render order for solid objects correct, but not for transparent objects?
Is there a way to force the render order? In my particular application, because of the camera angle I allow the user, I know with a 100% certainty which objects will be in front and which will not. If therender order can be forced, that might actually be a workaround in my case.
I get the feeling this might be a hard nut to crack, but if there are any other suggestions, I’d be thankful.
Simply there is no correct way. For any order you can come up with, it is trivial to create a example that fails. You could rewrite the sorting part in your case I guess.
Well, you got me looking in the right direction when you mentioned the TransparentComparator. Although the method used in JME3 didn’t give me the desired results, it got me thinking about a way to make it work for my application. What I ended up doing was using the same method for deciding render order in the transparent queue as used in ortho. I just checked for Z-order. As I said, in my particular application I always know the order I want to render my objects, so being able to set the Z-order worked wonders for me. 
And this is why I have an uncommitted JME3 contribution to allow users to set their own transparent sort object. Though… now that I can commit I should probably check that in myself. (d’oh)