I've never implemented depth peeling myself, but since I read about it for the first time I've never really considered it a good solution for transparency - because of its efficiency issues and limitation of max. N transparent layers.

It's not acceptable for games even on highest end GPUs today. It's probably fine for some demos or other non-real time applications where perfect inter-translucency intersections are critical.

I'd definitely go with traditional forward renderer for translucency nowadays. Also because in a "typical" (thinking about games) scenario you don't have too many translucent surfaces.

Quote:Original post by kek_miyu
I don't believe depth peeling is a viable technique for a real game and it's not more useful in a deferred renderer than in a forward renderer.

Well, depth peeling combined with deferred renderer for translucency has same advantage as it has with opaque geometry. You could theoretically light translucent geometry in deferred manner the same way as you light opaque geometry because each transparency layer contains single surface layer (although that would be overkill, hence you'd need separate depth buffer for each transparency layer as well).

But, yeah, depth peeling was mainly invented to handle problem of sorting translucent geometry back to front which can't be solved even if you sort per triangle.

You should definitely have a look at this.

I should think it would be sufficient to do your normal, opaque-only deferred shading render first, as normal, and then with the Z-buffer still filled, do your translucent-surface rendering sorted back to front by objects; if you don't use double-sided surfaces and use only convex shapes, you should have few to no problems.

One issue tangled in is particle systems; particles can get everywhere, and it can completely ruin your scene if, say, the emitter for a particle stream gets sorted in front of a window, but some of its particles are behind it, causing them to be not rendered (Z-occlusion), or rendered as though the window wasn't there (insufficient data to reconstruct the window's effect on what's behind it).

Depth peeling resolves this by targetting that second issue; by rendering and saving enough data to reconstruct the window's effect, and then doing a composition pass of all the layers afterwards. But that doesn't mean it's an elegant solution, because you will still get artifacts if your scene gets viewed from an angle that lines up more transparent surfaces than you have layers.

My approach is simple, even if it does restrict the art of a scene a little bit; I don't organize my particles and dynamic transparent geometry by emitter, but by their 'sector' in a world made out of BSP-like planar slices, which are made from the relatively-static transparent geometry, like windows. My visible set of transparent surfaces is found by walking that tree and intersecting each sector with the viewing frustrum. I sort the visible sectors containing particles back to front, and render sector, partitions, sector, partitions, until I get back to the camera's sector.

This technique works fine for buildings, even somewhat curved ones, but I killed my poor CPU once when I, without thinking about the implication, made a dome-shaped glass greenhouse, and then raised a few dozen dust-cloud particles blowing around it. Just 120 or so surfaces to make the greenhouse, a subdivided icosahedron, but because of their orientation I was getting one dust-cloud every once in a while, while walking nearly 6,000 sectors.

On the plus side, it worked correctly. Not a single dust-cloud pixel was visible on the inside the greenhouse; you could see them blowing past outside, but the particles, though large, tried to intersect with the greenhouse walls and were clip-planed back to their rightful side. Because I could rely on particles staying in their sector on the far side of each partition (the greenhouse walls), I could do a distortion through the windows using the view rendered thus far, as well.

I give no promises to the performance of my technique; I am not a good optimizer, was not using deferred shading for the opaque geometry (though I don't see how it would change anything), and did everything by-the-book, using normal, unmodified algorithms instead of specializing everything to the problem domain. I think on my Radeon HD2600 & AMD Turion X2 2.0 GHz I just managed to break 9 frames per on a simple city scene, with transparent slice planes in the walls of buildings and a single unmoving car's windows (~20 slice planes).