It really seems like the only way something ever gets done here is if epic needs it for one of their own games, or an enterprise customer requests it.
Then they implement the most useless things, like clear coat with dual normal map.
Meanwhile we can’t have non-blocky shadows.
Have you got your hands on 4.17 prev?
Yes, I posted an image on the last page, it looks exactly the same as in 4.16 if you don’t enable expensive soft shadows.
Oh didn’t see that. Well, not sure what joinmake meant there by saying it’s looking good in 4.17.
On flat surfaces there has been improvement at least, previously I got acne on surfaces that were close to perpendicular to the directional light, now it’s pretty much fixed. Or maybe I’m just imaging stuff :\
Gotta double check.
Not seeing any improvements at all. Still lots of weird artifacts on walls even with a bias of 0.5
Yeah, no improvement. I must have been dreaming or something 
Here is another approach to dampen the artifacts. Flat bias based on screen-space derivatives
Default shadow filtering, 3x3 PCF, 0.5 constant bias:
[SPOILER]
https://image.prntscr.com/image/5HiTl5h4Q42fUctO4tXZZg.png
[/SPOILER]
2x2 PCF with additional depth-based bias and 0.5 constant bias.
[SPOILER]
https://image.prntscr.com/image/o4W7CKTzS6uhwPKYWtFzOw.png
[/SPOILER]
**
Pros: Keeps shadow silhouettes more or less intact, easily implementable.**
Cons: Breaks at larger kernels, generates small artifacts on edges/object intersections occasionally, adds cost to shadow filtering.
Potentially, can be used as alternative to slope-scaled depth bias, but still does not replace receiver plane depth bias and should be only used in conjunction with the latter one.
Speaking of which, I’ve ran into issues applying proper receiver plane bias to default shadows though.I’ve described it in this thread. If anyone has an idea about the reason, I’d be glad for any help.
How long do we have to deal with this.
Until someone like @ figures out a solution, because epic doesn’t care 
Someone should hire him full time to just fix what community needs fixed.
Instead of Deathray pretending like he’s reinventing the wheel, by “paraphrasing” known code and acting like it’s his own creation, the majority of the base code is already in the link that I linked earlier. There is a whole section about screen space PCF ddx/ddy filtering. It also states that it’s a pretty complex operation, meaning it has a non-trivial performance cost. Keep in mind that you can quickly google to find more versions and variations of these types of filtering
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416307(v=vs.85).aspx
The problem lies in properly fitting it into the UE rendering path and doing it in a way that minimizes impact on frame time. There is a lot asynchronicity in the rendering engine and I’m pretty sure that plays a lot into the mix as to why they haven’t implemented it already. In that article, it even states “Because this technique is computationally complex, it should be used only when a GPU has compute cycles to spare.” The problem is that the UE rendering engine is already pretty optimized in filling up empty cycles.
You’d have a few options to pick from:
1)Let it lock up GPU to calculate completely and immediately
2)Mess around with priorities and “spare cycles,” so that this filtering would have a higher priority and finish sooner
3)Let it constantly update over several frames like DFAO
#3 would be the best trade off between performance vs quality. It would be made to have an iterative approach where it’s filter quality starts out course and progresses into finer and finer accuracy. So it might start out looking a tiny bit like the faceting problem and over a couple frames, it would smooth out to look closer to what the soft shadow filtering looks like.
Well, terrain issue is a bit complicated. It is 3 issues combined, not a single one.
More or less default appearance:
Firstly, it is cascaded shadows with large filter size. This is the issue discussed in this thread. Dealing with it is hard and always comes at drawbacks. 4.17 PCSS does a good job at minimizing it. I will post the code of adding additional bias for simple PCF shadows shortly, but one way or another, biasing involves certain loss of details.
Once you dampen this issue’s contribution, you end up with something like this, hopefully with slightly better shadow filtering:
Secondly, it is screen-space ambient occlusion. You will notice its contribution only in indirectly lit areas. Dealing with it involves tweaking ambient occlusion bias, until you get acceptable balance of faceting and details.
After dealing with it, terrain should look like this:
Lastly, there is inconsistency between shading and shadowing. Shortly, it is described as unshadowed triangle, facing away from the light, being brighter than shadowed part. I believe this issue is landscape-specific.
Potentially, scaling terrain’s normals to make them more aggressive helps to minimize it. It is somewhat fake, but helps to hide problematic shadowing areas with shading.
With slightly scaled normals terrain appears this way:
Hope that helps with terrain issues.
Sandly PCSS can’t be used everywhere as it adds an additional performance cost. And tweaking SSAO to make the blocky shadows less apparent on the ground, makes the SSAO look bad/go off on other regular meshes.
This is the Vehicle Game project from Learn Tab. I’ve done zero changes to it. Directional Light comes with 3 cascades.
This is simply unacceptable even as a demo.
This does look pretty bad yeah.
The same scene with RPDB at defaults. It has sufficient artifacts of its own, but generally seems a tad better.
The change is partially based on 4.17 PCSS code and is a shader edit only. You do not need to build engine from source to try it.
It is incomplete, but generally should work without major issues.
Spot lights are not working correctly, but you might never notice that. Point lights are unaffected. Lower quality presets need to be replaced with no-bias version though.
It is probably good to enable shader development mode and make backups of two USF files in question before overwriting originals.
I am most likely unable to offer any kind of support on this one. Use at your own risk. Make backups!
[HR][/HR]
There are scenes, that seem to benefit from this kind of bias greatly, but also there are ones, that look worse. As everything here, it is situational 
Yeah, that it is a tradeoff. Pretty sure something can be done to improve it though.
Now that the team I’m on has started creating our map, we’ve run into this issue as well. Honestly, how is it okay for this issue to still persist? Basically, dynamically lit terrains are just gonna look awful unless you enable PCSS in 4.17 or increase shadow bias (which causes issues). Like, I’m really having trouble wrapping my head around slope bias not being a thing here. I have not made one post on these forums that was overly negative towards Epic since I’ve been a member here, but this is ridiculous. Epic boasts about extreme visual fidelity but then you have stuff like what Maximum-Dev and are posting and it’s just not consistent with such claims. Of course there are workarounds that have been posted, but they aren’t really viable solutions. I know I’m coming across as sounding entitled, and that’s not what I’m aiming to do, but this is a serious issue that needs to be addressed.
Happening in Paragon as well
That looks really bad. I mean, not “OH GOD BURN IT” but it’s clearly below the quality level of everything else and reduces immersion. It’s eye catching in plenty of cases, though. Not sure why this hasn’t been fixed. It would be a huge improvement.
This deserves a bump…
I was not aware of this issue as most of my models dont have it, however after adding my tree’s in I get this issue. I am on 4.17.1 and it is still very much a real concern here.
