Hello.
I would like to be able to access the depth buffer at the very least, with post-processing shaders, as well as the normals buffer.
The use case that I have for this is to be able to create a proper cel-shading post-process shader (similar to what games like Borderlands have), using the depth buffer (and possibly normals to detect corners) in order to create borders instead of just extremely unreliable pixel sampling.
Depth Buffer + Normals access for Post-process shaders
Moderator: GZDoom Developers
-
Marisa the Magician
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Re: Depth Buffer + Normals access for Post-process shaders
This has been shot down before, but now even one of the developers wants this, I see.
Maybe we can make this possible by hooking these shaders in during the ssao pass(es)?
Maybe we can make this possible by hooking these shaders in during the ssao pass(es)?
-
Kinsie
- Posts: 7399
- Joined: Fri Oct 22, 2004 9:22 am
- Graphics Processor: nVidia with Vulkan support
- Location: MAP33
- Contact:
Re: Depth Buffer + Normals access for Post-process shaders
IIRC this was turned down because portals perform horrible black magic that renders the basic concept of "depth" a lie.
-
phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Depth Buffer + Normals access for Post-process shaders
It was turned down because portals have to be "sealed", or things will draw where they shouldn't. But turns out, if you think about it for a moment, it's actually not that hard to figure out a way to get a clean depth buffer for shaders.
Basically, the simplest way to deal with this is have the depth buffer for PP shaders just be an extra texture. You render the geometry to it in the world rendering pass in addition to the normal colour buffer, and just draw the depth value to it.
However, you don't draw the "sealing" to it, so this depth texture remains "unsealed", while the actual depth buffer gets sealed, so that it doesn't render things where it shouldn't.
The drawbacks of this method are (very slightly) higher VRAM usage and possibly very slightly more work for the GPU (but not really that much), but it's certainly not that bad of a price to pay to have a proper depth buffer for shaders.
This would also actually allow SSAO to be done normally, too, so it'll be able to happen for all portals with recursive ones instead of having to be limited to a certain number.
Basically, the simplest way to deal with this is have the depth buffer for PP shaders just be an extra texture. You render the geometry to it in the world rendering pass in addition to the normal colour buffer, and just draw the depth value to it.
However, you don't draw the "sealing" to it, so this depth texture remains "unsealed", while the actual depth buffer gets sealed, so that it doesn't render things where it shouldn't.
The drawbacks of this method are (very slightly) higher VRAM usage and possibly very slightly more work for the GPU (but not really that much), but it's certainly not that bad of a price to pay to have a proper depth buffer for shaders.
This would also actually allow SSAO to be done normally, too, so it'll be able to happen for all portals with recursive ones instead of having to be limited to a certain number.
Re: Depth Buffer + Normals access for Post-process shaders
The SSAO pass has to run before translucent stuff (anything where alpha is not 0 or 1) or it will not look right. That is actually the primary reason it has to run where it does, because portal rendering means it renders everything inside a portal before sealing it up.
I don't think it is a good idea to allow custom shaders access to the internal gbuffers as they may change. A much better solution would be to allow custom gbuffers, possibly where you would specify some of the channels being the normals or depth and the engine would then do a copy.
I don't think it is a good idea to allow custom shaders access to the internal gbuffers as they may change. A much better solution would be to allow custom gbuffers, possibly where you would specify some of the channels being the normals or depth and the engine would then do a copy.