The Trouble with Transparency

Even with ludicrous bandwidth to render or shade pixels, there's only so much that a hardware design that's 5 years out of the gates can do. With transparency and overdraw being the biggest culprits for the case of the missing fillrate, developers have few choices short of just not drawing transparencies. Sure, they can design the scenes for minimal overdraw or use LOD on effects, but again there's only so much one can do before it becomes artistically limited (yay... box room). Next is reducing the resolution of the transparency buffer, but this is par for the course for console games.

One of the solutions on the Xbox 360 is a neat trick, first publicly described by the Lost Planet developers at Capcom: Alias a lower resolution render target/transparency buffer as a 4xMSAA target. With Xenos' ROPs capable of 4 multisamples per clock, the operation is effectively free whilst reducing the pixel shading and fillrate cost by 4x. The downside can be some blocky artefacts in the graphics image;depth testing against a lower resolution depth buffer can also lead to edge artefacts. So, Chris Tchou goes on to describe a "smooth upsampling from the low res to the high res buffer".

For Reach, transparencies flagged for low-res use the 4xMSAA trick with a half-res buffer whilst still being able to use the full res depth buffer & Hier-Z buffer because their low res rendering is done in the same pass as full res transparencies whilst maintaining sort order; sorting can be an expensive pain when dealing with dynamic transparency effects. When desired, the low res buffer is resolved and blended with the frame buffer in a full screen pass with bilinear upsampling. However, switching back and forth between high & low res is expensive for which there were three optimizations used.

I NEED A BUCKET!

Chris explains this in detail, so I won't butcher it any more:

To optimize the transitions, we introduced a system that would revert back to normal high resolution rendering when it expected no net cost savings, based on the screen size of the particle system and expected overdraw.

On top of this, we reduced the fill costs of the composite step by stenciling out the areas actually touched in the alternate small buffer.

Finally, and most effectively, we limited the number of transitions by bucketing all the low res transparents into a fixed number of groups during the transparency sorting.  These groups were sorted together so they would be rendered sequentially. If you have N buckets, you will have at most N-1 transitions to deal with.  In practice, we found that N = 3 worked pretty well.

With the bucket system, there is some popping implied when the transparencies change buckets since the sorting changes. To reduce bucket changing, they create the groups by finding the largest 2 distances between transparencies (only 3 buckets).

When we insert these groups in the normal transparency sorting, we use the location of the farthest member of each group.

This means low res transparents are always pushed back in the render order, never pulled forward – which is good since the artists usually put low res transparents behind high res transparents.

With this system, we got the overdraw advantages of low-res rendering, but with visible minimal artifacts. As a result … we could make much heavier use of transparents to give atmosphere to our levels

So, enough about buckets. I have bad memories with buckets. You can actually see just how far they've taken the rendering technique with transparencies in one of the later levels of Halo Reach where you're flying around a city that's burning and there's all the rain particles too (and yes, they do hit the surface of your VTOL).

Ending Note

At any rate, it's always nice to see techniques that make it into a game, which afterall seems to be the ultimate line between academic "interactive framerates" (It's a faaaaake) and.... REAL... real-time rendering. All credit and thanks should go to Chris Tchou, Bungie and friends for having those slides public.