Accessing per-pixel normals in Godot 4.0

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

Accessing per-pixel normals in Godot 4.0

nilolo

Hi, I was wondering if there is a way to access the screen-space normals in Godot 4.0.
I assume there could be a way because I found the DEBUG_DRAW_NORMAL_BUFFER option in the Viewport class, which shows the view I'm looking for when activating it.

I thought of this 'hack' where you could use a second Viewport, set this debug draw option and save the viewport texture to use it as a shader parameter. But I don't know about the performance and I assume this is not the intended way. Also in the docs it says that these debug normals don't respect the effect of custom vertex displacements from shaders.

Is there an easier way to get the normals, let's say for post-processing?

cybereality

Godot is not a deferred renderer, so I don't believe you can access the full normal buffer. However, you can access NORMAL in the fragment shader, but only for that pixel.

nilolo

I've heard about this before, being a property of a forward renderer. But I thought there might be some changes to the renderer.
I wonder how this debug view is implemented, if it's just a this fragment shader you mention on every mesh.

TwistedTwigleg

I think it does a fragment shader on every mesh to get the debug normal view, but I could be totally wrong about that. There was a proposal to expose other viewport modes like the debug modes for use at runtime, but I do not have a link to it and I do not think it was implemented.

cybereality

Also, AFAIK those debug views are only available in debug mode. So when you ship a game in release mode they will not be there. Performance would probably also be bad trying to hack it, so that may not be a good plan.

lee-willis

You didn't say from where you want to access them. GdScript, or Vertex Shader, or Fragment Shader?

nilolo

lee-willis Thanks for your input! I didn't manage to check if the debug view is available in release mode yet.

Ideally I would like to access the normals in a Post-Processing fragment shader.
So either in a spatial shader with a quad in front of the camera or a canvas shader for the viewport.

lee-willis

Does this do what you want?

https://godotshaders.com/shader/uv-unwrap-and-normals-unwrapping-world-aligned/

Megalomaniak

While you can't get a normal pass from a forward renderer as far as I am aware, godot's is a depth pre-pass forward renderer, so you should be able to get a depth pass, and while the extra cost is not desirable, you could do some processing to produce a normal pass conversion from the depth pass.

Note that transparent objects don't get drawn to depth pre-pass, however that issue can be worked around by using a dithering shader instead of transparency. Further you can look into "Discontinuity Sensitive Filtering" to smooth out the dithering.

Honestly though I'm not sure it's worth the effort, might just be ~~easier~~, well more performant anyways, to implement a deferred renderer plugin for godot on the source level.

edit:
https://docs.godotengine.org/en/stable/tutorials/shaders/advanced_postprocessing.html#full-screen-quad

cybereality

Oh, yeah, I forgot about that. You do have access to DEPTH_TEXTURE. It is relatively simple math to extract a normal from depth (and also world space position). See here, I think this is the best method.

https://wickedengine.net/2019/09/22/improved-normal-reconstruction-from-depth/

nilolo

Thank you both for your answers!
Implementing a Deferred render pipeline option for Godot would definitely be very interesting, but it's over my head for now. I've seen Bastiaan Olij mentioning in his PRs that he's working towards making this kind of customization possible.

Depth pass to normals leads to many results online, it seems to be a common problem for implementing SSAO as well.

Megalomaniak

nilolo it seems to be a common problem for implementing SSAO as well.

Sure, though 4.0 should already feature significantly improved AO compared to previous versions so not sure if it's even really worth the effort if it's about implementing better AO. Maybe, I'm just not sure.

nilolo

Small addendum, the debug normal view does work in release-mode 🙂