I might be wrong but what you describe looks like the standard-issue shadow acne, where the artifacts are caused by screen pixel - shadowmap texel mismatch as you explained.
what we see here, the artifacts that produce faceted-looking shadows being discussed here, really look like a different problem - the problem appears based on the model’s topology completely independent from the shadowmap texels
I still think we’re missing something here because every other engine out there (including UE3) does not have these faceted-looking shadows we’re seeing here and I don’t imagine all those other engines out there (old and new) have Receiver plane depth bias implemented (UE3 doesnt for sure).
Regular shadow acne is something we’ve come to live with and accept, it’s a known limitation and it’s pretty much in every engine. but this issue here is much more perceivable and it screams bad quality all over the place
if this is indeed the same problem as the regular shadow acne it still feels wrong that it’s visible in such a large area of a sphere surface, as in every other engine (including UE3) shadow acne is only really visible at the lights’ grazing angles
It is still same issue. It is just that the larger the shadow filter is, the more grades of shade it will have, to a point where it is hard to see individual acne lines and a face might look uniformly shadowed to a certain degree.
If you take a closer look, the acne on that pic follows the faces of the model exactly the same way, like UE4 problem, that we are discussing. If you bump down UE4 quality settings to a level of UDK defaults, you would see something like this.
Nope, indeed. Most had been getting away with a combination of bias and slope-scaled bias.
The state of the problem in UE4 by default is pretty severe, I’d agree.
On a big scale, only few thing have changed since UDK, namely PCF filter size, and shadow resolution. It became larger in UE4 compared to UDK.
Yep.
It is hard to guess. Pretty sure they had valid reasons. Simplicity, consistency of results and platform/hardware compatibility comes to mind. Usage of classic slope-scaled depth bias varies slightly between between platforms and imposes restriction on a format of render targets, that can be used for shadow rendering.Implementing it in a hello-world app is incomparably easier, than in established engine. Adaptive bias might not run on every mobile phone out there, plus it has a measurable performance hit and on top of that, it can occasionally produce visual issues far more severe than the issue we are talking about. As opposed to these, flat bias is as simple as a brick and will reliably run on any toaster. Last but not least, up to a certain point, flat bias, backed by soft depth comparison, was just sufficient. In any case, these are just wild guesses as I see it. Whatever was the initial reason, I have a firm faith that UE4 needs slope-scaled bias. It would also be preferable to be able to adjust depth bias and slope-scaled depth bias for each cascade split individually.
Here is a short overview of what one can expect from various biasing techniques in UE4 under the spoiler:
I did post RPDB code a few pages behind in the thread. Here are the same files for 4.18.
Cannot share proper slope-scaled depth bias code unfortunately, as there were others involved.
Alternatively you could give a try to this material function for 4.18.1. It mimics slope scaled depth bias, with an exception that unlike the proper one, it operates per-vertex and does not come for free.
I encourage everyone to post works, broken due to this issue that you wouldn’t be able to showcase otherwise.
Perhaps this will keep the thread afloat and raise the awareness.
I also encourage everyone to mention this topic everywhere publicly possible, like in other forums, the gamedev reddit or when Epic is publishing a new blog post about how awesome their engine is. This needs a lot more attention.
I know it’s not the solution you probably want to hear, but until this gets fixed your best bet may be disabling shadows on landscapes entirely, then use contact shadows for any tessellation detail I know you probably want to have
Normally you can just cover it up like normal, but on the moon I don’t think that would really even be an option, so the sledgehammer approach may be the best one.
It’s Cary, in case anyone is really going to… ))) Anyways, we had to pause our project with landscape, even though it was nothing fancy, not even an open-world game - we are responsible people )) It’s almost impossible to make it look good. And all those other issues with large amounts of vegetation in UE4… And it’s a bummer because when the project started the future for UE4 looked very bright with so much promised by Epic. On the other hand we now have improved lightmaps and indoor lighting (well, sorta) and other improvements for the engine, and it’s great. But in any case I wouldn’t be optimistic about dynamic shadow artifacts and “large open-world” features. It’s Epic’s policy, I guess, to not speculate on issues they are not going to fix right away or in a near future. But at least a “Nope, guys, don’t have time for it right now” would be great so we could plan ahead and don’t have to put a project on hold for I-don’t-know-how-much-longer. Peace.
it’s not really better, it just shifts the problem somewhere else entirely
when using that the shadows jitter like hell with an impossible-to-miss hard noise pixel pattern. I assume it relies on TemporalAA (which gives unacceptable ghosting in my case), but even with TemporalAA I see the noise pattern on far-away objects (the entirety of my case: a top-down citybuilder)
also a drop of ~12% of performance (my case) can’t be considered a fix
