Add microshadows support

[LiveTrower]

closes #12671

This PR adds support for microshadows, first described by Naughty Dog in Uncharted 4, as a PBR alternative to Light Affect AO.

For more details, see... #12671.

[jams3223]

You dropped you're crown king.

[uno1982]

Thank you very much for your contribution! Looks amazing in action

[Saul2022]

It seems like this broken the mobile pbr material since when you enable ambient occlusion the texture turns white

. Also i got thousands of error messages like this upon opening the project with ao enabled

When switching to forward+ the errors and bugs stay

Here is a mrp with a pbr material from ambient cg textures https://drive.google.com/file/d/1aC9mlhSppWs-xJSCncHQKdQyjyy5fWWu/view?usp=drivesdk

[joao-pedro-braz]

@Saul2022 Would you mind attaching the error in full?

[LiveTrower]

It seems like this broken the mobile pbr material since when you enable ambient occlusion the texture turns white

. Also i got thousands of error messages like this upon opening the project with ao enabled

When switching to forward+ the errors and bugs stay

Here is a mrp with a pbr material from ambient cg textures https://drive.google.com/file/d/1aC9mlhSppWs-xJSCncHQKdQyjyy5fWWu/view?usp=drivesdk

Your problem seems to be related to fp16, so I would like to ask you to try again since I made some adjustments, as I don't have a device that properly supports fp16.

[Saul2022]

@Saul2022 Would you mind attaching the error in full?

The Issue is that while i can copy it, upon pasting it here, the browser crashes.

[Saul2022]

Your problem seems to be related to fp16, so I would like to ask you to try again since I made some adjustments, as I don't have a device that properly supports fp16.

Tried the latest artifact and i still got the errors , freeze and white texture as before.

[Saul2022]

Tested and now it works as expected and looks amazing, great job !

Off

On

[Calinou]

Tested locally, it works as expected. The interactions with additional lighting features (emission, back lighting, SSS, transmittance) seem correct.

Testing project: test_microshadows.zip

Preview

AO light effect and SSAO/SSIL are all disabled.

Renderer	Disabled	Enabled (0.85, default)
Forward+/Mobile
Compatibility

[Calinou]

This is always defined when ambient occlusion is enabled, so there's no way to use ambient occlusion without also having micro shadows enabled in the core shader. This leaves performance on the table if you set Micro Shadows to 0.0.

I suggest adding a boolean Micro Shadows > Enabled property in BaseMaterial3D (true by default), then a Micro Shadows > Strength property (0.85 by default). This way, you can set the first property to false and have no performance cost compared to 4.5.

(We can't use the existing Micro Shadows property alone, as inspector updates when dragging a slider currently don't work well.)

That said, maybe this option is too niche to be toggled on a per-material basis, and should be disabled in the project settings instead (similar to specular occlusion: rendering/reflections/specular_occlusion/enabled).

[LiveTrower]

Let me see if I understood you correctly:

• You want a new property, micro_shadows_enabled, to be added to ambient occlusion in StandardMaterial3D.
• This property should be set to true by default.
• You want to add a new setting in the project settings to globally disable microshadows.
• This global setting should be set to false by default.

Is this what you are suggesting?

[Calinou]

Yes, that sounds good to me. However, I would make the project setting affirmative (i.e. micro_shadows/enabled that is true by default).

In the future, we should look into adding similar "kill switch" properties for demanding BaseMaterial3D features, so that you can toggle them globally: godotengine/godot-proposals#2455

This is however nontrivial to implement in a way that doesn't require a restart to be effective (so you can use it in graphics settings menus). That said, we can leave this for later for a first implementation.

[Meowcat285]

Has there been any progress on this PR? This is something I'd really like to have

[LiveTrower]

Has there been any progress on this PR? This is something I'd really like to have

@Calinou made some suggestions that I didn't quite understand, so I asked him for clarification, but he hasn't replied yet. If you're wondering when this PR will be merged, it will likely be in 4.7 because 4.6 is already in feature freeze. However, that’s not my call; it’s up to the rendering team.

[LiveTrower]

I’m sorry for closing the PR; the rebase wiped out my changes. I managed to recover some of them, but I had to reimplement the rest.

I have replaced the Uncharted 4 method with the analytical method specifically for Forward+. Mobile and Compatibility modes will continue to use the Uncharted 4 approach.

I haven't been able to run performance tests because, honestly, I’m not sure of the proper way to do so. I would appreciate it if someone could run some tests on Forward+ to see if the analytical approach is viable for both high-end and low-end hardware. Additionally, I’m unsure if Godot executes this in parallel or if the visibility calculations are not performed on a per-light basis.

[jcostello]

You can use git reflog to recover the changes before the rebase

[LiveTrower]

I've noticed that the ao_light_affect property isn't working in compatibility mode. Is this intentional or is it a bug?

[Calinou]

I've noticed that the ao_light_affect property isn't working in compatibility mode. Is this intentional or is it a bug?

cc @jon1solution

It may be a limitation of S4AO's single-pass approach, I'm not sure. In this case, we should document it.

[jon1solution]

Excellent question. I did see ao_light_affect in scene.glsl, but it was simply set to 0.0. The S4AO shader actually runs in the post.glsl, so no mention of ao_light_affect there. I have no idea if it would be difficult to sent that info to the post processing pass in the GLES3 renderer. Does this lack break microshadowing?

[LiveTrower]

Excellent question. I did see ao_light_affect in scene.glsl, but it was simply set to 0.0. The S4AO shader actually runs in the post.glsl, so no mention of ao_light_affect there. I have no idea if it would be difficult to sent that info to the post processing pass in the GLES3 renderer. Does this lack break microshadowing?

It doesn't directly affect how microshadowing works, but it’s confusing that ao_light_affect doesn't work, given that microshadowing is the intended alternative with better quality for a bit more performance cost.

[BlueCube3310]

Visual Comparison between Forward+ and Mobile:

Forward+	Mobile

[BlueCube3310]

Test results:
Project: microshadow-test.zip

System: Fedora Linux 40 (KDE Plasma) on Wayland
GPU: integrated Intel(R) UHD Graphics 620 (WHL GT2)
CPU: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 threads)
RAM: 16 GB

RenderingDevice driver: Vulkan
VSync: Disabled

Environment disabled, directional light shadows disabled.

Renderer	Microshadows On	Microshadows Off
Mobile	4.8 MSPF	4.7 MSPF
Forward+	9.67 MSPF	9.46 MSPF

In general, I found the performance impact to be negligible (even on Forward+).