Hello, I have a bunch of 2d textures stacked up on the screen in RGBA format and the backside of them disappears… the front displays fine. The textures are put on some quads which are flat… like just displaying an image.
Would anyone know how to ammend the problem? I’ve done two sided light models
glDisable(GL_CULL_FACE);
That didn’t help… I guess I should add that there’s lots of transparency. Like, the “back side” of the object (a stack of textured quads) has a bunch of textures that are mostly transparent… but moving the camera to the back makes the front disappear.
Sounds like classic draw order problem. For transparency blending, you have to render that stack of textured quads back-to-front from the eye’s perspective.
Also, I assume you have GL_BLEND enabled, your blend function set appropriately, and your quad alpha values set appropriately.
Precisely… I had thought openGL would “handle that” automatically, but reversing the order in which the “stack of flat textures” is created fixes the back view yet not the front.
Is there a simple way to have opengl do this automatically?
Do you mean, is there a:
glEnable( GL_DEPTH_SORT_MY_POLYGONS );
Unfortunately, no.
And if you think about it for a few minutes, you’ll probably figure out why. If you have intersecting alpha polygons, there isn’t a polygon sort order that results in back-to-front rendering for every translucent fragment (pixel) in every translucent polygon. You have to bust geometry to get that, and OpenGL doesn’t want to get into that. Further, even without intersecting alpha geometry, it’s possible to orient your translucent quads relative to each other so that they’re mutually overlapping in depth, again such that there is no polygon sort order that results in back-to-front rendering for every translucent fragment. So again, you have to bust up some geometry to get the sort you want. Not only that, but you could sprinkle translucent geometry among opaque geometry over the course of the whole frame, so even if a sort was possible, OpenGL would have to record every single thing you told it to do the entire frame to be able to extract the translucent stuff, and sort it, so it renders in the right order and after all the opaque geometry. That’d kinda kill performance.
It’s much cheaper to sort geometry on an object basis at an application level (if that’s all your app needs) than to ask OpenGL to sort it per polygon or pixel.
So long story short, back-to-front depth sorting of alpha geometry is left in the application’s camp. It has more of the context needed to do this (if it even cares) than OpenGL.
And in general, when it comes to how rendering commands are drawn and grouped (batched), that’s an application thing. OpenGL just does what you tell it, the way you tell it, in the order that you tell it.
Now there are higher level transparency rendering techniques (not built into OpenGL) that you can implement on top of OpenGL to implement per-pixel transparency sorting (e.g. Depth Peeling and variants), but those tend to be on the more expensive side. For your problem, that’s using a sledgehammer to kill a knat.
Thanks! It’s useful to know the explanation behind the need to do it at the application level.