Search radius is intended to be used as in shadow space, but shader gets source radius as is, from the light, correct me if i’m wrong.
Also, what happens when source radius is 0 ? Projecteded source radius is also 0, and all the softenss comes just from PCF.
Me thinks that Light Source Radius needs to be adjusted to be in shadow space before being used.
When radius is 0 the projected value is clamped to one texel.
Source radius is projected from world space to shadow clip space:
radius * (1 / tan(fov/2)) / ShadowSpaceDepth
0.5 there seems to be correct visually. Lightmass difference can be attributed to exposure, biasing, sharpening and filter radius clamping.
Lightmass:
PCSS:
PCSS low exposure:
PCSS high exposure:
As to why is it there, needs in depth look. I don’t have source accessible at the moment, will check in a few days.
I will make more lightmass testing. If the multiplier is indeed correct I will remove my PR.
Returning to my previous post, is spotlight projection adjusted for source radius? I believe it is not and it is root of all problems.
CotanOuterCone variable is the adjustment.
What I was asking, aren’t you supposed to shift whole shadow projection behind, so that source is at spotlight’s near clip plane? That is… at distance zero, your source raidus will be radius, not zero.
I haven’t implemented PCSS for spot and omni lights myself, so bear with me.
In case, that above is a brainfart, what is happening with PCSSParameters.y ?
Red Color: Expected
Green Color: Expected Penumbra
Blue Color: Received at defaults
default:
0.5 replaced with 1.0,
and max kernel size inflated:
I don’t know about that shifting. There is only division by projected distance. Near plane distance isn’t factored at all. Not sure about should it.
PCSSParameters.y = MaxKernelSize / float(ShadowInfo->ResolutionX). So this should be correctly adjusted.
: Have you this PR integrated when you do testing? https://github.com/EpicGames/UnrealEngine/pull/4507
Yep, I have.
Bumping this to increase the chance for Epic to enter this thread.
I can confirm that this problem still exists in version 4.19, nothing has changed yet.
4.20 seems to be different. 4.20.0 has a different type dynamic shadows artifact:confused:
Can you take a screenshot of this? I still have the same artifact in 4.20 that I had in all the previous versions. Nothing has been fixed it seems. 
Hi, I have a dynamic low poly landscape with a directional light, and any time I turn on shadows, I get horrible shadow acne at certain angles. The bias is already at 0.3, and increasing it doesn’t do much (until it’s like 1, and then the shadows look detached). In Unity, I’m used to some shadow acne when the light source is almost perpendicular to the face of the shadowed triangle, but this seems pretty extreme. Most of the triangles affected have fairly different face directions. Is there anything that can be done? I saw there were some pull requests months ago, but I’m not sure if they help with this problem. (I’m using 4.20)
I’ve attached an example (TAA turned off to show it more accurately).
So…not even an official statement about this?
Yeah this is really bad, even with full shadow biasing there’s still errors, in addition to the shadows accuracy going down the drain.
Hm seems like Epic is still trying to ignore it’s indie gamedev users and their problems…
It totally messes up my procedually generated voxel landscape, it’s just super immersion breaking. 
