Automatic Z-Depth Algorithm

Feedback on past, current, and future development.
Post Reply
SatoriLotus
Posts: 24
Joined: 22 Jun 2017, 16:03

Automatic Z-Depth Algorithm

Post by SatoriLotus » 29 Aug 2017, 06:54

How much performance cost would there be for the engine to automatically calculate z-depth for alpha transparency and filter accordingly?

This would make things like translucent glassware and gems possible.

Chris
Posts: 1286
Joined: 04 Sep 2011, 08:33

Re: Automatic Z-Depth Algorithm

Post by Chris » 29 Aug 2017, 14:14

What do you mean by "automatically calculate z-depth for alpha transparency and filter accordingly"? Depending on the mesh's depth test setting, the Z depth value is calculated so it can be skipped if needed, and depending on the mesh's depth write setting, said value is written to the Z buffer.

SatoriLotus
Posts: 24
Joined: 22 Jun 2017, 16:03

Re: Automatic Z-Depth Algorithm

Post by SatoriLotus » 29 Aug 2017, 15:17

Chris wrote:
29 Aug 2017, 14:14
What do you mean by "automatically calculate z-depth for alpha transparency and filter accordingly"? Depending on the mesh's depth test setting, the Z depth value is calculated so it can be skipped if needed, and depending on the mesh's depth write setting, said value is written to the Z buffer.
This link could probably explain what I mean better:
https://blender.stackexchange.com/quest ... y-viewport

and here's an in-game example of the limitation at work:
Spoiler: Show

User avatar
AnyOldName3
Posts: 546
Joined: 26 Nov 2015, 03:25

Re: Automatic Z-Depth Algorithm

Post by AnyOldName3 » 29 Aug 2017, 16:00

When you're using the regular Z-buffer algorithm to draw stuff, it assumes that you can ignore things behind other things, which doesn't work for translucent materials. You can extend it so that you render everything without transparency normally, and then sort all the transparent objects by their depth using another algorithm. This can be complicated as parts of one object can be in front of something while others are behind, in which case the object needs splitting. Anything behind the z-buffer depth of a pixel from earlier can be discarded, and the rest is rendered from back to front on top of the other stuff. If you only have a couple of translucent objects, this isn't terribly performance intensive, but if everything might be, then you're totally screwed as the z-buffer algorithm is what GPUs are geared towards, and it's a lot simpler and faster than the alternatives.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests