Dynamic shadows artifacts

IOchair · September 17, 2018, 2:26am

If this bug is not fixed now, it will never need to be fixed. Because it is a generation of ray tracing soon, and I don’t need to consider performance as a CGer:confused:

Poet_11 · September 17, 2018, 3:57pm

Epic is now a mega wealthy company thanks to Fortnite : ) they should be able to hire a whole dedicated department to fix this stuff easily…

LOL that seems like it…

anonymous_user_fbe2d247 · September 18, 2018, 11:15am

I made PR for my improvements for Closer percentage soft shadows.

Chosker · September 18, 2018, 12:21pm

that looks ace, but your screenshots don’t seem too show how it impacts the “hard edged shadows” discussed in this thread. does it improve that in any way?
now lets just wait 6 months for the PR to be looked at

anonymous_user_fbe2d247 · September 18, 2018, 2:43pm

It helps but it’s not enough by it self.

spacegojira · September 19, 2018, 1:26pm

Yeah well, it seems unless it either directly affects Fortnite or one of Epics big industry customers, they won’t lift a finger to fix it…

That link gives me a 404 error, the page is missing (and I’m logged in). Did you delete it?

anonymous_user_fbe2d247 · September 19, 2018, 2:52pm

It’s still there. Maybe you haven’t logged in to GitHub?

MothDoctor · September 19, 2018, 5:44pm

You don’t have to “big industry customer” to get support through UDN or/and negotate custom deal with Epic.
That being said, it would be quite strange if noboy from studios with premium support didn’t raise this issue. So… it could be just Epic focusing more on new platforms and features than polishing existing codebase

spacegojira · September 22, 2018, 7:32am

Either that or they have the resources to build a fix themselves (which they won’t share) OR since it’s a very specific issue, it wasn’t a big enough problem for a major studio yet.
I am also certain a big studio would rather build ingame workarounds (like covering all the problematic shading zones with foliage or building new 3d models), as they have the manpower for that, than to prolongate their schedule for an unknown amount of time by hoping Epic would be issuing a fix in the next update / version. Especially since Epic has pretty much ignored this problem so far.

anonymous_user_fbe2d247 · October 5, 2018, 9:05pm

After improving my pcf shadow PR quite a bit I can now say that this solves “hard edged shadows” completely. I added gather optimization also for blocker search which improves quality in hard cases quite a lot. I also updated how dithering is done so its temporally more stable. I also made it so that you can compare old and new method easily with console command.

DamirH · October 6, 2018, 2:31pm

Hey, thanks a lot for the contributions. I was wondering - this 5152 PR contains all the fixes that were talked about in this thread, yes?

anonymous_user_fbe2d247 · October 6, 2018, 10:34pm

Everything related to pcf shadows.

KenyZ · October 7, 2018, 7:22am

I don’t know why, but for me on 4.15 this commit ( https://github.com//UnrealEn…b971aeaa31898e) changed the situation before my updating to 4.20.3. Now it crashes the engine, and ( ) is not working, as like as 5099 and others.(((

anonymous_user_fbe2d247 · October 19, 2018, 8:44am

There was bug that projection depth bias was applied twice with float3 variant of CalculateOcclusion.

anonymous_user_fbe2d247 · October 19, 2018, 9:05am

https://github.com/EpicGames/UnrealEngine/pull/5184
Optimization to save 36 ALU from subsurface shadow by using exp2(1.442695*x) instead of exp(x)

anonymous_user_fbe2d247 · October 19, 2018, 9:43am

https://github.com/EpicGames/UnrealEngine/pull/5185
Optimization to save 36 ALU from shadow comparison by rearranging math to MAD friendly format.

II_ADN_II · November 6, 2018, 8:38pm

Shouldnt this bug could be fixed just by scaling the bias accordingly the cascade resolution? I think the problem is that all cascades uses the same bias, despite using different pixel “sizes” in world.

anonymous_user_fbe2d247 · November 7, 2018, 8:42am

Bias is scaled based on resolution. This problem actually shows better with high resolution than low.

II_ADN_II · November 7, 2018, 4:21pm

This is more or less universal problem for shadow mapping algorithms.
A bit more details under the spoiler.

[SPOILER]Shadow mapping typically works by rendering the scene depth from point of view of the shadowcasting light.

https://i.imgur.com/otsoosf.jpg

Coordinates of scene pixels/fragments are then transformed into coordinate space of the light and their Z coordinate is compared to the depth, stored in shadowmap.

https://i.imgur.com/fklO3PY.jpg

If pixel’s Z coordinate in light space is larger than depth, stored in shadowmap, it is in shadow. Otherwise, it is not.

https://i.imgur.com/RDSCLyD.jpg

**Everything would be cool, if all screen pixels would always map to a corresponding shadow map texels. In reality they don’t and quite a few neighboring pixels would be mapped to a single shadow map texel. That means that when comparing Z coordinate of a pixel in lightspace, with a depth stored in shadowmap, there will be certain error, and some pixels would be falsely shadowed, while others would be erroneously unshadowed. This effect is commonly known as shadow acne. **

https://i.imgur.com/MDFpjiK.jpg

The most straightforward way of dealing with it, is to add a certain fixed value to the shadowmap depth, reliably pushing problematic pixels out of the shadow. While such method efficiently deals with the issue, it also reduces the shadowed area on the objects. If overdone, it cause object’s shadow to be smaller than the object, resulting in objects levitating above the surface look.
This approach is implemented in UE4 and you can tweak it with a value called Shadow Bias on each light.

https://i.imgur.com/GO2duip.jpg

However, when you add shadow filtering for smoother shadow edges, the problem worsens considerably. Now for a single pixel you would need to test it against several neighboring shadowmap texels, and when doing so, you are still using light-space Z coordinate value of the the original pixel, which greatly inflates the error.

https://i.imgur.com/aAo7eRD.jpg

To compensate, you would need to increase the bias considerably.

https://i.imgur.com/x4uJA5I.jpg

There are few ways of dealing with it.

Firstly, reducing shadow filter size would reduce the amount of biasing required. It can be done by setting quality presets.

Secondly, slope scaled depth bias can be implemented.

https://i.imgur.com/xPa0sFu.jpg

The idea is to add little amount of bias on the surfaces, that are perpendicular to the light and large amount of bias on the surfaces, which are parallel to the light.

https://i.imgur.com/8meQuXM.jpg

Slope-scaled depth bias is not implemented in UE4

The last common tool in dealing with the issue is receiver plane depth bias. In the essence, it works somewhat like slope scaled depth bias, but the amount of bias applied varies per each shadow filter sample taken instead of per shadow texel, resulting in even greater precision.

Receiver plane depth bias is implemented for PCSS shadows, but not for ordinary percentage closer shadow filtering, which is default.

Implementation of Slope scaled depth bias can be done by using a special shader for shadow depth rendering, or by setting slope bias in rasterizer state, the latter one being more tricky, but preferable. Both would require engine code adjustments and tug along certain complications.

Receiver plane depth bias can be implemented in shader files alone, without need to build the engine from source.

The essence of this thread is request to have slope-scaled depth bias and/or receiver plane depth bias as a part of stock UE4.[/SPOILER]

So this is it how its called, time to make a request then right? Im pretty sure its already a feature of unity since day one, why is not in unreal?

PD: slope-scaled depth bias its the same as the normal offset bias?

Deathrey · November 7, 2018, 4:52pm

They are not the same. The earlier one pushes the surface away from the light and does not greatly affect shadow shape while the latter pushes the surface inwards along the vertex normal and reduces shadow area, but requires lower values to deal with self-shadowing issues.

It is not in the engine most likely to due to the fact that there simply was no demand for it, until shadow filter kernel grew to immense sizes, but that is only my speculation.