@
In order to get rid of the line, you need to ensure, that your displacement comes down to zero at a distance, less than distance of last cascade split, that has tess enabled.
@Michel.Dupuis @Deathrey I think I found an issue which explains the hard shadow falloff. Normally you’d want shadows close to camera be crisper, and the further it gets it can get more blurry. The issue here is that the near side of each shadow cascade in UE4 is blurry, and the far side of each cascade is crisper which is basically the opposite of ideal.
I have a test here showing that.
Red line shows first cascade area, green like shows second cascade. I have circled some details that are currently within the second cascade, on the near side. You can see the shadows are blurry.
Next, I have reduced CSM distance so second cascade comes closer to the camera. This time that circled part is still within the second cascade, but it’s near the far side of it before it fades into third cascade. You can see the shadows are now crisper.
Please let me know if I am being unclear or wrong about this. Thanks.
@
I’ve described the cause of sharp shadow line in a comment from mid January. It is due to the fact, that in cascade, that has tess disabled, but still has non zero displacement in it, shadows are received by comparing displaced light-space pixel depth versus undisplaced shadow depth. You should either reduce displacement fade distance to fit it in first cascade, or increase shadow distance and/or exponent so that first cascade encompasses displaced region or bump up index of last cascade that has tessellation enabled.
This image is with CSM distance 20,000: https://i.imgur.com/axzLRTT.jpg
First cascade covers so little area we can’t really fade tessellation that early, we need like minimum 10 meters of tessellation from the camera (maximum 15 meters).
How can I make it so other cascade has tessellation shadow enabled? or that involves modifying some code? because I don’t know code if that’s the case.
Still, do you see how the near side of second cascade cast blurrier shadows than it’s far side? shouldn’t that work the opposite way?
Restrict Tessellation To Shadow Cascade is the setting responsible for that.
It was present in preview build, but not in the final release. Sadly that makes this visually unusable until 4.20.
Really? Wasn’t aware of that. Leaves you Tessellation Component Screen Size control only. Should get same results, but restrict shadow to cascade was by far more convenient.
Yeah sorry guy, but this feature had to be cut of 4.19 because of the difference between static and dynamic rendering that could only be fixed with the other part of the optim that will be in 4.20. But in the meantime playing with the Falloff should help reduce the issue you see, it will remove the tessellation AND also blend the displacement to 0 but if you remove tessellation after Cascade 0 using this settings, i think it should provide a look similar to what you are seeking.
hi Michel,
“The shadow specific one will come for 4.20 as i couldn’t finish it in time for the 4.19 deadline.”
I was wondering if this is already in 4.20. I’m trying out the MasterBranch (pulled and compiled just yesterday) and on a first quick try (using an 8k terrain with a 0.25 actor scale) this doesn’t seem to have improved 
I’ll make more tests and profiling to check where the heavy cost comes from, but essentially in the current MasterBranch 4.20 tessellation on a big landscape is still pretty much performance-crippling 
Hi,
Which master branch are you talking about? as there is currently no 4.20 Branch existing.
Thanks.
And even from without the shadow optimization, as reported by others the performance are MUCH better and values can be tweaked so it’s not too costly compared to before. Keep in mind that depending on your landscape size (i.e 255x255x2) using a high tessellation factor will still cripple your PC, but ~10-15 times less than before if you don’t tweak the values to be more aggressive.
hi Michel, thanks for your answer
I downloaded the engine through GitHub and compiled it myself. the master branch I’m talking about is this: https://github.com/EpicGames/UnrealEngine/tree/master
when compiled and run, Help → About Unreal Editor displays version 4.20. as it’s obvious it’s not the final 4.20, it is why I asked if that one already had your shadow changes 
I know the performance in 4.19 is better in landscape in general (which has some positive impact on tessellation). however an 8k landscape with tessellation enabled (factor of 1.0 tessellation in the material, using the new landscape actor tessellation properties to only have tessellation on a single component or 4 components on the worst case if I move to the corner of a component) results in my FPS going from ~90 to ~50 running at 1080p on my GTX970.
for what it’s worth, at this point my landscape only has 2 layers and is pretty much a fresh start with no extra features - which means my performance can only get worse. but at this point I’m really only comparing enabling vs disabling tessellation alone.
in short, yes in 4.19 it’s better, but it’s still prohibitive.
which is why I wanted to look into 4.20
Yeah the feature is not in 4.20 yet, and would have some impact, but only in shadow, in your case is it still the shadow depth that is costly?
Also usually when using a landscape of 8k, you normally would use also world composition, as 8k is VERY big, most game/engine don’t have landscape of this size, they use trick to give the visual look of 8k without having the full landscape being 8k at all time, in this case, in unreal, you should use World Composition.
as I mentioned I don’t know exactly where the cost is coming from, since I just started playing around with the master branch. however now knowing that for now it still behaves as 4.19 I guess I can go back to 4.19 and profile it better.
digging up a couple of 2 weeks old screenshots (when I started testing landscape+tessellation with 4.19), I can see I had 38 FPS with shadows enabled, and 58 FPS with shadows disabled (in both cases with tessellation enabled, just 2 landscape layers, using the landscape actor tessellation cutoff properties to have tessellation only on one component, and a tessellation factor of only 1.0 in the material)
the thing here is that I downscaled the landscape to an actor size of 0.25 because 1 quad per square meter isn’t exactly cutting-edge nowadays.
at 0.25 scale I get 4x4 quads per square meter but the size becomes the equivalent of a 2k landscape. at this point using world composition (I assume you mean to stream in/out components) it would result in really limited view distances though.
at this point I’m just testing the limits of the renderer. I’m aware it’s better to use “background meshes” if the far away areas are not playable, or otherwise using world composition to stream in/out landscape components in place with proxy terrain meshes.
but even then, I’m really only focusing on the performance cost of having tessellation on and off. and at this point I still find it prohibitive
what would be great btw, would be if unreal would keep a version of the non-tessellated shader under the hood, and have it switched back and forth when the tessellation properties of the landscape make it reach a tessellation of 0.
without this, the base cost of tessellation is still too high, and it’s still very wasteful to have a tessellated material (for far components) without any actual tessellation going on (since as we well know, the base cost of tessellation is very high).
Also, you do realize that having a Tessellation Factor of 1.0 is like having no tessellation right? Also what are you using tessellation for?
Also could you show your material on how you use the tessellation?
Thanks
you mean in the material? for me Tessellation Factor of 1.0 = some tessellation, while Tessellation Factor of 0.0 = no tessellation
in any case as it’s been discussed and acknowledged several times (just scroll up to see it), Tessellation enabled with Factor of 0.0 == much higher cost than Tessellation disabled. that’s why I made the suggestion of having the non-tessellated shader under the hood.
I’m using Tessellation for my landscape only, nothing more. my test project for now is just a skybox, a landscape, and the default first person template stuff (the gun that shoots balls)
Tessellation enabled with Factor of 0.0 == much higher cost than Tessellation disabled:
This is totally normal as you go through the tessellation pipeline, which mean you still push the Hull/Domain shaders, even if you’re not using them, you’re still going through this pipeline on the GPU.
Can i see how you use the tessellation in your material?
Hi @Michel.Dupuis,
Just reaching out here to say there is a list of issues/features about landscape in general I created almost 1 year ago, which went on for 4 pages but staff didn’t leave a reply. Since you’ve been the only person who got involved with landscapes, and I’m not sure how your schedule works internally, I wanted to ask how possible it is for you or someone around you to have a look at the list and maybe work on ~1 of these features or issues per year?
Thanks.
@Chosker, I still didn’t find time to try your function you PMed me, been busy with a new apartment we’re moving to. Will give it a try asap. Thanks.
@ What list are you referring to?
yep I’m aware of the high base cost. again, that’s why I suggested the non-tessellated version of the shader + switching under the hood 
I wonder what you think about that suggestion btw. I think a slight spike on switching shaders per-component based on distance would justify the big performance gain
I’m currently at work but I’ll provide a screenshot of my setup later today. but really it’s just ((a heightmap texture with worldposition-based UVs [-] a scalar param as bias) [x] a scalar param as height multiply [x] vertexnormalWS) plugged into displacement, and then (a scalar param) plugged into tessellation.
–[x] is a multiply while [-] is a minus. this forum software turned (*) into italic text–
aside that I use FlatTessellation mode, and Adaptive Tessellation is enabled. doesn’t get any more basic than this really