Godot: PSSM artifacts with directional lights

[matrem]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
godot master branch

Issue description:

It seems to me pssm and/or pcf need a little more work to be really usable.

For a simple scene with a cube and sphere, the default settings are not great (gap due to bias) but even after many tweaking I would say it's not ok :

• split incoherence
• jaggy resolution (the settings for resolution in project settings do nothing)

Steps to reproduce:
Here my little scene with results (which are very different in every viewports) :

Here a comparison with unity (with no tweaking) :

Link to minimal example project:

[soloparatolos]

I just tried the beta build an looks like the problems with the shadows are still there. I opened a couple of issues about this but got closed. I think that this is gonna be a real problem when more users get aboard with the beta and they see that there is no way to tune the shadows to look ok even in the simplest scene. This is the last issue I created #11390.

[Calinou]

Note that directional shadow size changes are effective only after an editor restart (or running the project).

However, I can confirm that directional shadow maps will look poor when the viewport is very wide (but not when it's very tall), see the screenshots below:

Wide viewport (bad directional shadows):

Square viewport (good directional shadows):

Tall viewport (good directional shadows):

OmniLights are not affected by this issue.

Note that you can fix split incoherence by enabling Blend Splits on the DirectionalLight. This should probably be enabled by default, as it looks much better.

[kubecz3k]

Do blending splits makes it looks better?

[Calinou]

Do blending splits makes it looks better?

Blend splitting is enabled in my project; disabling it has no impact on this particular issue.

[reduz]

I insist that the PSSM algorithm is implememted as best as I understand it. It may be a matter of default settings. If anyone wants to research more on this topic, let me know and I will linknto relevant pieces of code

[matrem]

Blending help a bit but when there so much difference between two splits it seems not be able to smooth the result properly.
Long time ago I played with pssm and pcf, I don't know if I can improve anything, but I'm interested to look at how you did that. You implemented some specific paper ?

Some cool pointers, for anyone looking for information :
https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch10.html
https://docs.unity3d.com/Manual/DirLightShadows.html
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416307(v=vs.85).aspx
http://developer.download.nvidia.com/SDK/10.5/direct3d/Source/VarianceShadowMapping/Doc/VarianceShadowMapping.pdf
http://developer.download.nvidia.com/shaderlibrary/docs/shadow_PCSS.pdf
https://developer.amd.com/wordpress/media/2012/10/Isidoro-ShadowMapping.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.1923&rep=rep1&type=pdf
http://www.nvidia.com/object/doc_shadows.html

[volzhs]

@matrem if you are interested, #7204 this also would help. :smile:

[cosmicchipsocket]

The main issue I see with the directional shadows is that the objects don't appear to have contact with the ground. Lowering the bias much further from the default produces artifacts.

Here are the results I get using the same bias and normal bias settings from the Unity screenshot:

Setting any amount of contact causes pretty nasty artifacting. Here are some examples with a contact value of just 0.1:

Increasing the texture resolution of the directional shadows from 4096 to 8192 does let me set the bias lower before artifacting occurs (and thus make the shadows less floaty), but doing this effectively halves my framerate.

Why has #7204 been closed? Can it be resurrected?

Edit: I am getting much better results if I increase the size of the geometry by 10x:

The defaults for shadow and rendering distance don't seem to be designed with this scene size in mind, however:

[vnen]

Why has #7204 been closed? Can it be resurrected?

Because it was made for Godot 2.1. Godot 3 has a completely new renderer backend, so that PR can't be applied anymore.

[cosmicchipsocket]

Poking at this some more, it seems like the max shadow distance is what determines the resolution and precision of the shadows (combined with the shadow texture size selected in the project settings). This would explain why enlarging the geometry made the shadows more precise.

I wonder how the distance defaults compare to Unity?

[jayanam]

The shadows are still bad for directional lights in 3.1.1. Perhaps have a look at the code of UE4 to see how they did it.

[Calinou]

@jayanam We can't look at UE4 code due to the proprietary license it's under.

[jayanam]

I didnt mean to copy it, just understand how they implemented directional
lights and shadows, because the implementation of PSSM in Godot seams to be
incorrect.

On Sun, Jun 2, 2019 at 11:40 PM Hugo Locurcio [e-mail]
wrote:

@jayanam https://github.com/jayanam We can't look at UE4 code, due to
its license.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/13575?email_source=notifications&email_token=AEJUGIB4VJS63NU32HQRS43PYQZJHA5CNFSM4EGMDWKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX6CBQ#issuecomment-498065670,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJUGIACUC4ZHMRZK4425YTPYQZJHANCNFSM4EGMDWKA
.

[Calinou]

@jayanam Even merely reading its code constitutes a legal risk, as one of Epic's lawyers could claim the implementation is too close to the original. This is why reverse engineering is best done in a "clean room" approach :slightly_smiling_face:

[Zireael07]

What about Unity? https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-source-code/

[akien-mga]

What about Unity? https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-source-code/

That blog posts is pretty clear.

Not open source.

[Zireael07]

You can't modify the code, but you can read it "... to understand or improve performance of games... made with Unity engine". And if you understand how Unity did it, there's nothing stopping you from improving Godot's implementation? Neither Unity nor UE4 have those issues with shadows...

[jayanam]

Yep, that's what I wanted to say.

On Mon, Jun 3, 2019 at 3:13 PM Zireael07 [e-mail] wrote:

You can't modify the code, but you can read it "... to understand or
improve performance of games... made with Unity engine". And if you
understand how Unity did it, there's nothing stopping you from improving
Godot's implementation? Neither Unity nor UE4 have those issues with
shadows...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/13575?email_source=notifications&email_token=AEJUGIFDRZGKKUIXLGWKFY3PYUKF7A5CNFSM4EGMDWKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWZLFFQ#issuecomment-498250390,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJUGIAZQIZVD6V7VJNCL33PYUKF7ANCNFSM4EGMDWKA
.

[mysticfall]

I believe this is one of those gray areas of software licensing and copyright. Some people consider it to be ok to read proprietary source code and take some ideas from it as long as you don't actually copy the code, but there are also precedents like GNU Classpath, for instance, which forbade anyone who had seen the proprietary source code (thus 'becoming tainted') which it aimed to clone from participating to the project, to stay clear of any potential legal problems.