Ordering draw calls for alpha blending

Newbie & Debugging Questions
#1

Hey!

I recently ran into a problem where having multiple calls to opengl to draw translucent geometry produced some funky results. I googled it, and I believe the problem has something to do with having to order the draw calls from back to front.

I was curious; how should I go about doing this?

My game features an infinite world, split into chunks. Each chunk is 1 VBO. I can order the VBOs from back to front no problem. But will this fix the problem,? Or do I need to order the draw calls within the VBO too? Wouldn’t that be quite awkward to do, especially if you have a face that has 2 vertices behind another face, but 2 vertices in front of that same face?

I’m a little puzzled if I have to be honest. The only thing I know is that the weird alpha drawing only happens between chunks. This leads me to believe I only need to order the separate VBOs rather than the inner calls to openGL to draw the faces…

Anyway, thanks:P

#2

Try it :stuck_out_tongue:

Also some pictures might help :slight_smile:

#3

Just wondering if anyone had any experience with it, before I jump in and do something:P

#4

You can order everything based on distance to the camera.

#5

But the point is, do i need to order every draw call, or just the order in which the VBOs are drawn?

#6

I experienced this problem with my 3d world. Instead of sorting everything back to front, I just discarded the pixel with a custom shader.


varying vec2 texCoords
out vec4 color;
uniform sampler2D sampler

void main()
{
     vec4 textureColor = texture2D(sampler, texCoords.xy);

     if(textureColor.w <= 0.01) // If the pixel is basically transparent
          discard; // Throw this fragment away;

     color = textureColor; // Else assign this fragment to the pixel's color
}

Unfortunately, this method only works for completely transparent textures. If you want translucency, then you will have to sort back to front instead of using this method.

#7

But how could you sort it back to front if half the vertices of 1 poly are behind, and the other half are in front?

#8

Most games don’t have anything transparent except for particle effects, e.g. smoke, fire, sparks etc, which are easier to sort as they are flat quads facing the camera (so no impossible scenarios can occur). Games generally completely avoid having semi-transparent geometry due to the complexity of handling that. The closest thing available is alpha testing, which isn’t really transparency. It’s exactly what Longarmx wrote about, where you discard pixels that are “too transparent”, effectively achieving binary transparency (either fully opaque or fully transparent).

#9

order independent blending is really hard to do right.

sorting triangles will only approximate correct results; there are too many special cases when simple sorting fails … like overlapping triangles.

state of the art of dealing with transparency is using per-pixel-linked-lists afaik, using a so called “a-buffer”. a list of values per pixel, sorted per pixel and drawn blended back to front. too bad it requires rather recent hardware, i think gl 4.3+.

some random google results :


#10

It’d be interesting to think about a hybrid of the weighted OIT with fixed number of layers and no sorting per say.

#11

Hm, okay. I guess I should abandon this then - I was going to have all of the terrain above a certain height translucent, so that you could not only see a ‘cross section’ of the terrain but also the full shape of the terrain.

#12

@basil_:
Skip on the a-buffer: https://software.intel.com/sites/default/files/i3d14_mlab_preprint.pdf

further out: http://www.nvidia.com/docs/IO/88888/StochTransp-slides.pdf

Possible today on low-end: http://casual-effects.blogspot.fr/2014/03/weighted-blended-order-independent.html

#13

aah cool, thanks! :slight_smile: I’d love to skip a-buffers. they cannot be speedy or easy on memory usage.

stochastic blending is about abusing msaa buffers to do order independent “dither” type blending ?

#14

stochastic is pretty far out. yeah: the high view is many samples of some fencing/dither pattern per pixel (a la old software rendering trick).

#15

Other random thoughts are the volumetric stuff: fourier opacity mapping, extinction transmittance maps, half-angle slicing.

#16

reads really good :

#17

Efficient Rendering with Tile Local Storage: http://community.arm.com/docs/DOC-8916