Hi
I've been
Hmm, hard to say without some code. Can you maybe give a simple example I can test locally?
Okay.
I've spent the last two hour or so cutting my (uhm… "grown") try-out-application down to the really relevant part and doing some more tests.
This is the result:
Two boxes. Not even a texture. Just a setRenderQueue(Renderer.QUEUE_TRANSPARENT) and the problem is there.
The following code creates a small blue box in front of a big red one.
But: the red box always covers the blue one, although being behind it.
This error flips on and off, depending on the viewing angle of the camera. (just slide left and right after starting the app)
public class HelloRenanse extends SimpleGame {
public static void main(String[] args) {
HelloRenanse app = new HelloRenanse();
app.setDialogBehaviour(SimpleGame.NEVER_SHOW_PROPS_DIALOG);
LoggingSystem.getLogger().setLevel(Level.OFF);
app.start();
}
protected void simpleInitGame() {
Node transps = new Node("Transparent Queue Node");
transps.setRenderQueueMode(Renderer.QUEUE_TRANSPARENT);
rootNode.attachChild(transps);
lightState.detachAll();
Box b1 = new Box("red Box", new Vector3f(0,0,17), new Vector3f(2,2,19));
b1.setModelBound(new BoundingBox());
b1.updateModelBound();
b1.setSolidColor(ColorRGBA.red);
b1.setLocalTranslation(new Vector3f(0,0,0));
Box b2 = new Box("blue Box", new Vector3f(0,0,19.1f), new Vector3f(1,1,20));
b2.setModelBound(new BoundingBox());
b2.updateModelBound();
b2.setSolidColor(ColorRGBA.blue);
b2.setLocalTranslation(new Vector3f(1,0,0));
transps.attachChild(b2);
transps.attachChild(b1);
}
}
Notes:
a) In most cases i've tested, the odd rendering order depended on the order of attaching the meshes to the parent node.
(means when i flipped the attaching order, all looked fine from front view, but looked odd again when seen from rear view)
The strange thing is:
In the code sample above, the red box ALWAYS covered the blue one, no matter the attaching order... :?
b) Another thing i already noticed some days ago:
In some tests, the odd behaviour disappears if setLocalTranslation() is called for the objects involved (guess it does some updating which isn't done when creating the objects.)
But this didn't help in my try-out application, nor does it help in the code sample above.
c) I hope this is not just a silly mistake I made, forgetting something or so...
Or should i hope that it was my fault, and not the engine's ? :/
First off, thanks for spending the time to help us debug this issue. Efforts like yours help improve jME every day so again, thanks!
It turns out the problem was a zbuffer bug in the two pass transparency implementation. This issue is fixed and in cvs.
FYI, during fixing, Mojo and I discovered that handling of two transparent objects intersecting is a frustrating issue that requires rendering chunks of objects in different orders. So if your model requires intersecting translucent objects, this fix won't help. We'll keep thinking about the best way to handle this.
Wow. Fast response, as always 
And thanks for the thanks (l
Yeah, I know the issue. If you run the Q3 loader test from a few months ago, you could see the issue in all three engines on the torches from certain camera angles. I'm guessing the moral is the you need to avoid such intersections when building your scene… ie, you need to cut up your intersecting meshes into left and right chunks. I'm sure there is a clever way to have the engine help with that, but it would likely be a solution only for static objects that were locked (resplitting every frame would be… bad.)