Switching Shaders - Painter's Algorithm

Newbie & Debugging Questions
#1

Hello there,

I’m using libGdx but feel free to answer generally.

Let’s say you have a 2D game where sprites are sorted by their y-coordinate, so sprites with a lower y-coordinate are “in the foreground” and get rendered over sprites with a higher y-coordinate. (assuming the y-coordinate is pointing upward)

Now let’s say i want to render trees in two steps, first i render the stump and then the leaves on top of it with both of these sprites having their separate shaders (let’s call it stumpShader and leaveShader). Now in a 3D environment this wouldn’t be an issue: First i bind the stumpShader and render all the stumps, and then i bind the leaveShader and render all the leaves. Because of these neat thing called z-buffer i don’t need to worry about my trees being rendered in a wrong “order”.

But in a 2D environment where i just “paint” trees over other trees i do have to worry about that, because if i render all the stumps first, and then the leaves on the stumps, some leaves will be rendered over stumps that they should actually be behind of. So that way i’m forced to render stump, leaves, stump, leaves, stump, leaves… and constantly switch between stumpShader and leaveShader.

As far as i know switching shaders is pretty costly and you should do it as sparingly as possible, so this is obviously not an option.

So my question is what do i do in this scenario?
Can i somehow utilize the z-buffer in this kind of 2D setup?
I guess i could write one shader that takes care of both things, but I’ve also heard that if statements should be avoided in glsl.

Thanks!

#2

Orthographic projections have a z-coordinate, if you give trees Z values based on their rendering order, you can use the z-buffer. (not 100% sure)

#3

  • Orthographic projection matrices still calculate a depth value, which is configured using the near and far values when setting up your orthographic matrix.

  • Z-buffers do not work well with transparency, as a semi-transparent sprite will update the depth buffer, preventing things from being drawn behind it. If you’re OK with binary alpha (either fully opaque or fully transparent), you can use alpha testing / discard; in your shader to prevent depth writes for the fully transparent parts (this is a very common technique used for foliage in 3D games).

  • If-statements are not slow per se. They’re only slow if 1. the shader cores in a group take different branches, as that forces all cores to execute all branches, and/or 2. the worst path of your shader uses a lot of registers, as the GPU needs to allocate registers for the worst case branch regardless of if that branch executes or not (this is very rarely a problem). If you have if-statements where all pixels of a triangle take the same path, the overhead is essentially zero. In addition, 2D games are often CPU limited as they often need to micromanage the sprites, so getting rid of CPU work at the cost of GPU work is often a net win as the GPU was sitting idle for most of the time anyway.

  • If you can draw all stumps first, then all leaves, then you only have two shader switches regardless of the number of trees you have, in which case the number of shader switches is constant. In that case, 2 switches instead of 1 is insignificant.

#4

thank you! very insightful