You need to have linked github account to access that.
Hello,
First of all, sorry that it was so quite here all that time and you didn’t get any kind of response about dynamic shadow artifacts.
Thanks Kalle-H for your awesome contributions. I just integrated both of them (pcf 2x2 offset fix and pcf 2x2/3x3 optimization) for 4.20. Regarding other dynamic shadow issues in this thread - can’t promise anything at the moment, but certainly we will look into it.
That is really great to hear 
No need to promise anything, just hearing something from you/Epic is great.
Found easy fix for this.
FScreenSpaceData ScreenSpaceData = GetScreenSpaceData(ScreenUV);
float NoL = saturate(dot(ScreenSpaceData.GBuffer.WorldNormal, DeferredLightUniforms.NormalizedLightDirection));
Settings.TransitionScale = SoftTransitionScale.z * lerp(0.1, 1.0, NoL);
O.o really? OMG!!
GetScreenSpaceData has non trivial cost associated with it. Suggest that you replace it with a function, that would grab only normals from gbuffer(or at least double check, if unused parts of it are compiled out of ASM. I believe they are not.), as well as exposing constants on that lerp for control, but overall, that would be a feasible temporary workaround. There are other potential uses for surface normal during shadow filtering btw.
Shader compiler are really good for removing unused parts of code. GetScreenSpaceData is used pretty much everywhere without worrying which parts are not used. I can check the ASM to be sure. I don’t use source code version so I can’t add control for parameters.
There is ASM diff.
Untitled diff - Diff Checker
Actual code that is added is pretty short.
15: sample_l(texture2d)(float,float,float,float) r2.xyz, r0.xyxx, t0.xyzw, s0, l(0)
16: mad r2.xyz, r2.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), l(-1.000000, -1.000000, -1.000000, 0.000000)
17: dp3 r1.w, r2.xyzx, r2.xyzx
18: rsq r1.w, r1.w
19: mul r2.xyz, r1.wwww, r2.xyzx
20: dp3_sat r1.w, r2.xyzx, cb2[2].xyzx
21: mad r1.w, r1.w, l(0.900000), l(0.100000)
22: mul r1.w, r1.w, cb0[0].z
Yeah, That what I was worried for. And it was for nothing, it is only one extra fetch.
It is a good find in any case.
The approach however still suffers from the fact, that biasing is done based on shadow receiver, not shadow caster.
Biasing during shadow depth rendering based on shadow caster normal vs light vector does not distort the shadows that much, so it is still a warmly welcome feature, along with being able to set bias/ soft transition scale per each cascade.
Either this is a cruel hoax or the community managers need to grant you the “Developer” banner; I’ll reserve my judgement until one or the other is confirmed.
that actually looks great.
but before getting too excited, could you show something with more irregular geometry than a sphere? I wonder how non-convex self-shadowing will behave with this fix
He’s not from Epic though, is he, otherwise he would have the “Developer” tag. And if he was really from Epic, than this would be a really poor response after all this time.
Oh, come on… Please, try be a bit more optimistic in life 
Almost everybody is like “oh, it would be awesome to have any response”. And you’re like a zombie: somebody gives you a hand and you bite it.
I guess this new mysterious developer is Krzysztof Narkowicz who just joined Epic. A guy with years of experience, also as lead engine programmer. Let him settle in.
@Krzysztof.N
Siema, dobrze cię widzieć w tym siedlisku żmij zwanym forum
And continuing in English… It would be great to immediately mark all accepted PRs on GitHub. I know it’s not your fault, many PRs are still “open and waiting” even long time after being pulled into engine. Do you think it’s doable?
Hey @krzysztof can you please ask anyone to give you a Epic Staff badge… otherwise we most likely report you for impersonating Epic’s employee. This thread is just too sensitive for the community 
No one is insulting the man, but we really have no way of knowing if this 1-post account is an impersonator or not. Nothing is stopping me from creating a Ryan_Brucks account and claiming the old one got lost in a forum migration or something, this is why the Developer badges exist. The community managers need to finally get back on the ball here asap.
Not to mention that there are lots of Krzysztof registered…
I was commenting the part with “And if he was really from Epic, than this would be a really poor response after all this time.”
And I simply assumed it can’t be a fake account. That post doesn’t include any serious “trolling material”, this would be incredibly lame troll.
Well, lesson learned. Should quote only relevant part of post…
Can confirm, new Epic dev
Okay now that it is confirmed, thank you for finally getting back to us. I hope you understand my (and others too I am sure) frustration having this problem all the time, I had to abandon a promising project because of it (which I already had put a lot work into).
Could you please let us know what your plans are to adress this problem and how you try to fix it - I mean other than implementing what Kalle-H did?
Also, could you, or anyone from Epic, let us know why there hasn’t been a response for so long? And if possible, how you plan to avoid such non-communication in future?
Thank you again and welcome to the community!
Let be honest. This thread hasn’t been most welcoming for Dev’s to jump in. Lot’s of whining and overreactions. Not that much actually helpful information or suggestions. I also do want to know what are the Epic plans with shadows but I am feared that this negative attitude just silence them.
Currently I am trying to improve PCSS. They are bit too noisy and tend to overblur close casters. There are also some light bleeding.