Ok, I know what you’re thinking. “Not another transparency thread!”. I’ve tried searching for this issue but haven’t found anything quite related to the issue I’m having with transparency.
The problem is, I have say 2 Quads both set to use a texture with transparency. I place the 2nd quad directly behind the first. Now, I ensure that the material has the proper blend mode and the quads are thrown into the transparency bucket. Now, the transparency works just fine…until the 2nd Quad (the one behind the first) starts to rotate.
I have modified the HelloMaterial example to reproduce this issue. Note the 2 quads in the center. If you move the camera to about say, 45 degrees or less to the surface plane of the Quads, you will see the alpha flicker effect. This effect has proven to be quite annoying and I’d love some advice on how to fix this, or if this really is a bug with jME3.
Is it flickering or just switching sort as you move around? ie: is there a view you get to where sitting still it flashes? Or is it just that one sorts in front of the other “incorrectly” at some point?
See, transparency is all about the back to front rendering. Otherwise the Z buffer will get messed up. So if you draw the back quad first then it will obscure the front in the Z-buffer and so that part of the front one won’t get drawn. I can’t see any reason that they would sort badly in this case but I thought I’d clarify the behavior. There actually isn’t any universally correct way to sort shapes by Z but at a quick glance it looks like it would sort ok in this case.
Hmmm… I sort of remember having this problem once myself for a 45 degree surface. Can you try changing the lighting direction a little to see if it fixes it?
Yeah, I understand the concepts of z-buffer and transparency but this problem mystifies me. If you load the test class I supplied, you can see that once you move the camera to about < 45 degrees to the quads (moving closer to the quads allows you to see the flickering more clearly but not necessary). Even without moving the camera at all you can see the flicker effect. Changing the lighting direction makes no difference. scratches head
The quads in the example use the Unshaded material so lighting shouldn’t matter ?
I’m pretty sure the quads are being drawn in the wrong order when you see the flicker. If you put the quads in the Opaque bucket the issues goes away (well, the quads are always drawn in the correct order) so I would say it’s an issue with the order in which objects are rendered when in the Transparent bucket… Someone smarter will have to pick up from here …
Then I got nothing. A flashing on and off when sitting still implies that a) the camera isn’t sitting still (probably not the case) or b) there is something with multipass lighting… which also isn’t the case.
I can’t think of any reason that the state would change from one frame to the next, otherwise.
The two quads are too close together… When you move to the side, the back quad gets rendered second, because jME3 thinks it is closer to the camera (one of its edges is closer, since it is rotated). Because its closer to the camera, jME3 has to render everything behind it so it blends with this quad, but it is wrong in your case because the front quad is still in the front.
The only way to fix it is to set your own transparent comparator that says that the front quad is always in the front, but of course you have to know the exact order things have to render otherwise it won’t work. Also you have to consider that the order can change if you look at the scene from the back rather than the front.
Wouldn’t it make sense for a Quad to be rendered based on its center and not on the various vertices? What you are mentioning makes sense why after about 45 degrees of viewing the Quad behind the first from the side causes the flickering because one point of the Quad might technically be closer…but if Quads are always sorted based on their center I don’t see how this issue could ever happen. I’ve played around with the test case I posted, but even moving at an angle from the bottom edge, I still see flickering…and all points of the 2nd Quad really are furthest away from the camera, so this doesn’t make sense.
To clarify, the flickering occurs regardless of whether the camera is moving or not. Once the camera is viewing the quads at <=45 degrees of incidence, the flickering occurs (because the 2nd Quad is rotating). I have effects in my game that rely on my Quads being rotated constantly and it’s annoying that when the camera gets to be certain angles from these Quads everything starts to flicker.
There is no perfect way to sort shapes based on Z. It’s not a solvable problem. JME currently sorts based on point closest to the camera of the bounding shape which can be better in many situations where a center point sort would not.
It’s exactly because there is no correct way to sort that I lobbied for and implemented the ability to set your own comparator. In some cases, I even use a comparator that allows me to bias the results with a value set on the geometry’s user data. In other cases, I do a straight material-based sort.
You could pretty easily set a comparator that sorted on object centers.
Thanks pspeed for the input. I’ll have to give this a try, however…
I have been playing around more with the test case that I provided. If you move the camera directly towards the quads, stop, then just strafe left (move left) without changing the camera facing direction at all the flickering occurs. All vertices of the 2nd Quad (the rotating Quad) are behind the first and thus are furthest away from the camera at all times but yet the flickering occurs. How is this possible?
The distance between the quads is really small, while the distance when the 2nd quad rotates is much larger … If you move close enough on the Z axis and farther enough on the X axis the sorting will be wrong again
Also dont forget the limited z buffer depth, this can cause such flickering as well, when the frustum is set for rater large scenes(and has a very near nearestclip)
…