Why we are not using pixel depth offset instead of masked opacity?

FishMan

Isn't that a solution for an overdraw problem?
I mean if you put a giant number in it - "transparent" pixels will be behind a skybox and theoretically do not render at all, while a shader will remain opaque. Am I correct? Or I misunderstand something?

Mark Dygert

Short answer: 
PDO is more expensive than Masked Opacity and can be just as expensive as transparency, so it's a poor choice to use as a replacement for Masked Opacity. Just use masked opacity.

Longer answer:
First lets make clear the terms we're talking about. 

Masked opacity usually refers to the binary calculation that engines use to decide if a pixel is either 100% opaque or 100% transparent, no middle ground, just on or off. This is probably the simplest opacity calculation to make. It's really fast and the best way to knock out pixels. It doesn't do costly transparency sorting but then it's never meant to do that. The contribution to overdraw is there, but it's greatly diminished because it doesn't have to calculate how much of a pixel you can see behind the other. 

Transparency usually refers to the gradual scale from 0-100. Pixels can be partially transparent which causes the engine to figure out what is behind it and sort that out first and then take a step forward and figure out the actual pixel that you see on the screen. That is where overdraw really comes into play, if it looks behind a pixel and finds another transparent pixel, it has to pause and keep looking behind pixels until it finds something solid. THEN it can start stepping forward. The less of that nonsense it has to deal with the better. Which is why people talk about controlling overdraw, it can be where most of your opacity budget will be spent and can easily chew up your ms and FPS.

Pixel depth offset, refers to moving a pixel in a given direction. This is also a costly calculation because you are transforming each pixel, on each frame. You have to figure out where the pixel was, where you want to move it and then calculate how to get it there, this can be really expensive if you have to do other things to that pixel, like apply normal or roughness. Keep in mind this will not replace transparency, it will only do fake opacity masking. This will not do transparency it will only do masking, so it's only a replacement for the cheapest form of opacity sorting.

When you apply PDO those pixels get stuffed into the rendering pipes and get used in all kinds of calculations, in a similar way that transparency goes through the full render pipe. Even if you're pushing them really far, they still get evaluated and used.

• Does this pixel get shadows from the surrounding lights? 
• What lights are affecting the pixel at its start and end points?
• How does that factor into the shading of the surrounding pixels?
• What is the normal map doing to the pixels?
• Is the material on a moving or deforming mesh, like a particle or a skeletal mesh? If so factor in those calculations...
• What is the pixels contribution to the fog or bounce lighting?
• How does this pixel affect scene depth? You don't want it to, but the engine will be asked to figure that out for each pixel on each frame.
  
• Now that we're using PDO for opacity masking, how do we talk to the transparency pipeline and make sure we aren't crossing or omitting data that it needs? 
• Do we need to rip into the transparency pipeline and insert more instructions so it sorts and shades things correctly?
  
• Does this large shift in PDO cause temporal Anti-Alasing issues? Do we get black streaks on the screen? Do we shut off TAA? What if that solves a lot of other issues?

With Opacity masking, the pixels get culled out of large sections of the rendering pipeline and usually don't get included in a lot of calculations. PDO, they're opaque and thought to be there, so they get the full treatment.

You might not see PDO show up on an overdraw visualization and think that it's a win but really, it's not. It's just a really convoluted way to bypass that shoves that calculation into another rendering pipe that isn't built to do that level of sorting. It is only chewing up more cycles, somewhere else that you can't see.