As much as one might want it to be so, the cause of the problem is slightly different.
This is caused by shadows. Shadows don’t actually work at all for orthographic cameras, so the problem will not appear.
Work hours and budget has nothing to do with such very, very old issues. It’s been years. Sometimes all people need is a simple reply letting them know that they at least know the issue exists. That’s all. But the silence only results in more duplicate threads and posts by different people.
if we keep the thread up maybe they’ll end up acknowledging it
btw I’m sure I saw this very issue in FortniteBR, I just don’t have the evidence 
If I recall correctly, for the cinematic, they had to replace the heads for higher resolution models, because as there were shots very closely to them, it was necessary increase the details and smooth the surface a lot, maybe was just to avoid this issue. Anyway, you can’t do that for gameplay with landscapes… and replacing the areas compromised for high resolution props is a pain…
Im not confident on a reaction to this thread… I wish a lot for some acknowledge 
Yuo can see it clearly in Xmas season battle bus.
yep got some evidence now
btw is it me or does Fortnite completely ignore Landscape for the terrain to rely on static meshes? 
Simply false. You can rotate the light in an ortho mode in a mesh-viewer without issue. Shadows look clean. Switch to perspective and the shadows become blocky. Like I said, the fix is to simply factor the perspective matrix into the shadowing. I’d do it myself but the rendering pipeline is closed source.
Ortho camera is broken in-world it appears. It’s unrelated, but the issue probably involves the lack of the perspective matrix.
There is no shadow in orthographic mode. You’re mistaking the direct light fading out on backfaces for shadows.
Also, all code is available on github. Unreal has no closed source parts.
What do you mean rendering pipeline is closed source? Everything is on Github: for example shadow rendering is here https://github.com/EpicGames/UnrealE…wRendering.cpp
If you want to check the shaders they’re under Engine/Shaders.
@Ohriginal: An easy way to verify for yourself what Zeblote is saying:
Create a new scene with a directional light and a sphere, and toggle “Cast Shadows” on the light on and off.
to elaborate a little on the mesh viewer itself…
I have the feeling Epic is trying to ignore this and keep it under the rug for as long as they can, until some major company calls them out for it publicly. Then there will be a fix right in the next engine version.
Yeah Epic don’t use their landscape system, and tbh the landscape performance and quaility is another topic to talk about…
Fortnite used meshes per zones the world of fornite are random generated so place meshes per zones of 20x20m ± to build a puzzle level for say it in some way.
Seems like this still no fixed.
Happy New Year
Personally even if Epic doesn’t want to address this problem at this time, I would like to know what is causing it and if there is a solution for it, since i’ve seen it come up in other realtime software, can someone explain why is it such a universal problem? is it a hardware limitation thing or software or…?
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]
Thanks @ . It greatly enlightned the issue for me now. I shall meditate on this for a while.
Would it be a simple change to copy this over to normal shadows?
Hey thanks man for taking the time to explain this, any guesses on the pros and cons as to why Epic may not have chosen the latter two options that would result with relatively better shadowing?
I think before used to have this look better, aswell someone posted screenshots from realtime shadows of Crysis 2 that is a 7 years old now game that looks better than this…
If someone want to make raytracing in realtime there sure is a hardware performance problem, but there is always other ways so…