Batching semi-transparent geometry.

Usually, proper sort order at a per-sprite level is not necessary. Often, you're trying to use sprites to simulate volumetric material anyhow --- so the depth of the sprite doesn't accurately reflect the depth of the material anyhow, and even per-sprite sorting won't look that convincing. Sorting at a batch level is usually enough, as long as the batches are chosen sensibly.

When proper sorting is necessary, generally people use a texture atlas, as you note.

Ah, thanks for the confirmation about atlasing and so on, for sprites, etc.
In a GUI application, the scenario I depicted would lead to breaking up the batches to render each layer correctly, though, right?


Also, can anyone recommend some books that specifically deal with techniques like that?
Something like a hybrid of GPU Gems and the ShaderX books, maybe?

I remember reading about techniques that help for reducing drawing calls and all that, but I read them a long time ago...and they were all scattered, so a compilation would be really, really awesome.
I don't want prefab code, per se, but still more or less specialized general tips (even if that's some sot of oxymoron).

For example...I think I recall reading that one could just use all 8 texture-'slots' at once to save some switches, but I can't remember if the approach used 8 coordinates per vertex, or had some sort of lookup and only used one set of texture coordinates and a sort of index about which texture to use.

A general approach, but still specialized enough to prefer it over multiple draw calls.

Edit:
Would be awesome if it also contained things like:
"It's less CPU bound to fill a VB with vertices in a specific order in one call later, than using 10 draw calls to render those 10k tris without any sorting" for example.
(I pulled these figures out of my behind, but I read something like that before, but again, somewhere I can't remember)

something like a ...tricks of the trade book for backwards people like me, as in, slightly outdated (cause I don't think big AAA guy give out their secrets) but still better than web-tutorial/autodidact level performance.
Any recommendations?

Assuming you achieve transparency by blending. It must be distinguished between linear blends and non-linear blends. The decal blending, additive blending, subtractive blending, and reverse subtractive blending
d := s
d := s + d
d := s - d
d := d - s
are all examples of linear blends. It can be seen when applying 2 blends in the one and other order, and both ways give the same result. E.g.:
d2 := s2 + d1, d1 := s1 + d => d2 = s2 + s1 + d
d2 := s1 + d1, d1 := s2 + d => d2 = s2 + s1 + d
Hence linear blends are not order dependent.

On the other hand, a non-linear blend like alpha-source blending
d := a * s + ( 1 - a ) * d
cannot be reordered, because
d2 := a2 * s2 + ( 1 - a2 ) * d1, d1 := a1 * s1 + ( 1 - a1 ) * d => d2 = a2 * s2 + ( 1 - a2 ) * ( a1 * s1 + ( 1 - a1 ) * d ) = ... - a1 * a2 * s1
and
d2 := a1 * s1 + ( 1 - a1 ) * d1, d1 := a2 * s2 + ( 1 - a2 ) * d => d2 = a1 * s1 + ( 1 - a1 ) * ( a2 * s2 + ( 1 - a2 ) * d ) = ... - a1 * a2 * s2
are different. Hence non-linear blends are order dependent.

Notice please that also linear blends cannot be mixed freely with opaque objects, because of you still need to control what pixels to render, i.e. usually by the depth test.

What are your needs? You may use blending in the sense of masking, i.e. alpha is either 0 or 1. In that case you effectively have decal blending where alpha is 1 and no blending where alpha is 0, but you need to setup it in a single mode where both can be achieved in parallel. But you've luck, because with some trickery you may reach the goal: Discard pixels where alpha is 0, and the depth buffer will only be updated where you actually want pixels to occur. (You can use alpha test or shaders to discard pixels.) Sometimes switching off depth buffer writing in total is a solution, too.

You may have small fall-offs of alpha between "large" 1 and 0 areas. In this case you may say that only small rendering artifacts appear, and hence ignore order problems. IMHO GUI's are not necessarily a good candidate for this method.

Screen door transparency (a kind of stipple blending) is order independent, too. Depth peeling (a multi-pass method) would probably work as well (I've never used it yet, so I may be wrong).


If a texture atlas isn't big enough, then using multiple TUs is possible, but brings its own problems. AFAIK it is meaningful only with shader scripts, and even then you need to pick the correct sampler (indexed access to samplers is not possible, at least in GLSL; presumably its the same in HLSL and Cg). It would be better then to use 3D textures where the 3rd texture co-ordinate is (mis-)used to pick the correct layer; using 2D texture arrays would make this simpler but isn't strictly necessary.