The Glass That Wasn't There
You turn around in a greenhouse level and the windows are gone. Not broken, not glitching in any way you can name. Just absent, or worse, rendering the outside world in front of the plants instead of behind them. You stand there for a second wondering if you imagined them.
You didn't. That's a transparency sorting failure, and it happens because your GPU is, in a very specific sense, bad at reading.
The short answer: game engines render transparent surfaces last, sorted back-to-front by their distance from the camera, because the math that makes transparency work requires the background to already exist in memory before the see-through surface is painted over it. The longer answer is where things get uncomfortable.
Why Opaque Objects Get a Free Pass
Solid geometry is easy. When a GPU draws an opaque wall, it uses a depth buffer (also called a z-buffer), a second image at the same resolution as your screen that stores how far away each pixel's current occupant is. Draw a closer wall, it wins. Draw a farther one, the depth buffer rejects it. Order doesn't matter. The final image is always correct.
Transparent surfaces can't use that system cleanly. If you want a blue-tinted window to show 80% of what's behind it, the GPU needs to blend the window's color with the background color already sitting in the frame buffer. The blending operation is: final color = (window color × 0.2) + (background color × 0.8). Simple arithmetic. But the background has to be there first. Write the window pixel before the background exists and you're blending with nothing, or with a surface that's even farther away.
So engines split the world in two. Opaque geometry renders first, in any order, with the depth buffer as referee. Then transparent geometry renders second, sorted farthest to nearest, each layer painted over whatever's already been composited. The depth buffer is still consulted for opaque blockers, but transparent surfaces don't write to it. They read it.
The Sorting Problem Nobody Warned You About
Painter's algorithm (named after how a painter lays down a background before foreground details) sounds straightforward until you try to implement it on a scene with fifty translucent objects all moving independently.
Every frame, the engine re-sorts those objects by distance from the camera. Sixty frames per second means sixty re-sorts per second. For a small number of objects, a standard sort is fast enough. Scale it to a dense forest of translucent leaves and you're spending real CPU time on bookkeeping.
The worse problem, though, is geometric overlap.
Imagine two large transparent planes crossing each other like an X. Plane A is partly in front of Plane B and partly behind it. No single sort order is correct for the whole scene. Sort A behind B and the top half looks right, the bottom half is wrong. Sort B behind A and you get the opposite failure. The only real fix is to split the geometry at the intersection, turning two overlapping planes into four non-overlapping ones. Some engines do this automatically for specific cases. Most don't, which is why you occasionally see two transparent surfaces shimmering against each other, each frame rendering them in a different order depending on camera angle.
Here's a worked scenario: an aquarium asset with a glass tank containing glowing water. The water surface is one transparent mesh, the glass panes are four more. The player crouches to camera-level with the tank. The engine sorts the front glass pane in front of the water, the water in front of the back pane, and the chain works. The player rotates the camera fifteen degrees. Now the water's centroid is technically closer to the camera than the front glass pane's centroid, the sort flips, and the water appears to jump in front of the glass. That's a centroid sort artifact. It's a known, accepted limitation in most real-time engines, which tells you something about the economics of fixing it.
What Engines Actually Do in Practice
Unreal Engine uses translucency sorting by projected distance, measuring from the camera to the object's origin point. Unity's built-in renderer does roughly the same through a render queue system where materials get numeric priority values. A standard opaque material sits at queue 2000. A transparent one sits at 3000. Vegetation cutouts, opaque but alpha-tested, live at 2450.
Those queue numbers mean a developer can manually nudge render order without touching geometry. Assign a specific glass pane queue 3001 instead of 3000 and it always renders after everything else in the transparent pass. Artists use this constantly. It is, bluntly, a manual patch on top of a system that doesn't fully solve the problem.
Forward rendering and deferred rendering handle this differently too. Deferred rendering, which most modern engines use for opaque objects because it scales well with many lights, doesn't work with transparency at all. The geometry buffer can't store multiple layers of surface data per pixel. So engines running deferred for opaques switch to a forward pass specifically for transparents. Two different rendering pipelines per frame, back to back, every frame, forever.
Order-independent transparency (OIT) is the academic solution. Techniques like depth peeling or weighted blended OIT try to remove the sort requirement entirely by storing multiple transparent layers per pixel and resolving them at the end. Weighted blended OIT is now available in both Unreal and Unity, and it works well for smoke and particles where slight blending inaccuracies don't register. For hard-edged glass, it produces a characteristic hazy look that artists reliably reject.
The Depth Pre-Pass Trick
One technique that helps without solving everything is the depth pre-pass. Before drawing anything, the engine makes a fast, color-blind pass over all opaque geometry, writing only to the depth buffer. During the main opaque pass, any fragment that would fail the depth test gets rejected early, before the GPU runs expensive lighting calculations.
For transparent surfaces, the pre-pass means the depth buffer is fully populated with opaque geometry before a single transparent pixel is drawn. This eliminates one class of artifact: transparent surfaces accidentally rendering on top of opaque surfaces that should be occluding them. It doesn't fix sort order between transparent objects themselves, but it cleanly separates the opaque-vs-transparent relationship.
It's a bit like taping off trim before rolling the walls. The tape doesn't change the color. It keeps two separate operations from bleeding into each other.
What Actually Goes Wrong (and Why Artists Live With It)
Most players never notice most sorting artifacts. The industry knows this and has made its peace with it. A distant forest of alpha-blended leaves sorting incorrectly is visually indistinguishable from correctly sorted leaves to anyone not specifically looking. The artifacts that get noticed are the dramatic ones: a character's hair clipping through itself, a window vanishing entirely, water sitting visually outside its container.
A common misread is blaming the texture when the culprit is the sort. Players report "weird glitching" on transparent objects and assume a broken asset. Artists receive bug reports about textures that are technically fine. The real issue is a centroid sort putting two objects in the wrong order for three frames before the camera angle corrects it. If you've ever watched a game's water surface flicker between looking correct and looking like a mirror facing the wrong direction, you've seen this live.
Have you ever filed a bug report about a "broken" texture that nobody could reproduce? There's a reasonable chance the asset was fine.
Developers also make deliberate tradeoffs, and this is worth saying plainly: additive blending for particle systems isn't a bug fix, it's a redirect. Particle systems can involve thousands of transparent quads. Per-particle sorting is expensive. So engines use camera-facing billboards with additive blending instead of alpha blending. Additive blending (final color = background color + particle color) is order-independent because addition is commutative. The result looks different from true transparency, brighter, more bloom-prone, but it never sorts wrong. The visual lie is cheaper than the geometric truth.
The GPU is fast at parallel math and bad at sequential decisions. Transparency is, at its core, a sequential problem. Everything real-time graphics does with transparent surfaces is a negotiation between those two facts. And the negotiation is never fully won, only managed, frame by frame, at sixty times a second.