OpenGL - drawElements 2D imposible z-sorting (textured)

Question

I am creating a 2D program in OpenGL 3.2 Now to render what I do is have a VBO for each texture and add the elements of the objects that use that texture to this vbo. Now as you know the order you render objects will be the (fliped) order you see them on the screen.

Here is the problem, as you know its possible to sort objects by their Z value in the same VBO (by inserting them to the vbo according to their Z value). But when you want to sort them between VBOs thats impossible because they have to be in the correct VBO to have the correct texture, Meaning the VBOs that are drawn last will have positive Z value priority over VBOs that are drawn first.

This causes the Z value to transfer from the actual objects, to their textures and makes the Z value be grouped for all objects that use the same texture.

That was kinda confusing so to recap, because of the way VBOs work this is what is going to happen:

Turtule texture id 1

Box texture id 2

(Each textures has its own VBO)

There is one turtle and one box, the turtle (z = -1) is behind the box (z = 0) . if I render the box VBO then the Turtle VBO What will happen is we will see the turtle over the box even though it has a z value that is less then the box.

Here is some art I drew to help you visualize the problem:

^^^ That makes the Z value of the actual turtle meaning less compared to the " Z " value of the VBO. This can be worked around by having a Z value for each VBO but that limits the program because if the Z of the boxes is bigger than turtles no matter what every turtles is gonna be hidden behind every box. And its a stupid way of doing it.

So finally to the question:

---

What can I do to fix this, to have a meaning full Z value to each OBJECT.

---

Notes:

• I cannot draw the object individually because I use drawElements and because I add them to texture coresponding VBOs to reduce the VBO count and texture binding count.

Stuff I have tried* : I have tried using the actual opengl Z-buffer, but I cannot blend layers because of that so its not a solution.

Answer 1

Put all the objects inside the same VBO, and use a texture atlas to put all your sprites on the same texture.

A texture atlas should look like this:

All you have to do is the get UV of each sprite in the atlas (which you can do using a tool like spritesheetmaker).

Don't be afraid to make a 1024x1024 texture, or a 2048x2048 texture, or even 4096x4096 textures seem to have reasonable support on GPUs these days.

Answer 2

Z values by themselves do relatively little other than change the projection of the individual vertex which for a 2D orthographic sprite game basically means they do nothing at all. If you want to have the API take Z values into account when rendering overlapping items the way you want, you need to be sure to turn on Z buffering. As you stated, though, this does not play well with blending by default; you need something more. Translucent objects must be sorted or a non-trivial order-independent translucency technique (like depth peeling) must be used.

Typically in a 2D app, however, you just sort the objects back-to-front. This is called the painter's algorithm. Sorting manually is quite easy. You don't need to change the VBO setup I think you're using (I'm not 100% clear), just change the order of your draw calls.

Even high-end 3D games still have to do this, as translucency all but requires it and high-performance rendering actually benefits quite a bit from it for opaque objects (by sorting closest first with Z-buffering on, to avoid overdraw and keeping fillrates low).

You can do the same thing for 2D, of course: sort front-to-back for opaque or "cut-out" objects (those with alpha values of only either 1 or 0), and then draw back-to-front for translucent objects. Use Z-buffering in both passes but only enable Z-writing for the first opaque object pass. This is relatively easy, gives good performance (especially on fillrate-limited hardware like most mobile devices), and shouldn't require many changes to your code.

You should also highly consider @bobobobo's advice. Atlasing is a huge benefit to performance, and is very much possible on GL 1.1 systems. You don't need a single atlas, you can have more than one. The primary benefit is that it lets you reduce state (texture changes) and minimize draw calls, which can have a huge performance impact. You can automatically generate texture atlases from your images at runtime which fits whatever the current driver's maximum texture size is, if you're really worried about compatibility with ancient/deficient drivers.