Hi
Why are using enabling tessellation in the material but putting a tessellation multiplier of 0 (which should act as disabling it based on your assumption)
Pardon me, I haven’t really understood your question 
I’m neither intending to use material with tessellation enabled while having mult at zero, nor assuming that setting tess multiplier at zero has absolutely same effect as disabling tess.
I am only signing under the following:
- In UE4, tessellation, landscape
tessellation in particular, has
considerably higher overall
performance cost than expected. - Baseline tessellation cost on
landscape is inflated. - Whole scene shadows are prohibitory
expensive with landscape
tessellation.
Hi, after investigation i think the biggest issue, is that you’re trying to tessellate a zone that is way too big, i.e the map provided is a 2kmx2km map, and about 1.5kmx1.5km is tessellated and shadowed…(ie in LOD0) which is quite costly even on high end graphic card.
I tried playing with LODs to see if performance could be improved and by changing the LODDistanceFactor from the landscape from 1 to 3-4 which you don’t see much difference visually drastically reduce the cost of the shadow from ~8ms to 2ms.
We need to keep tessellation for the shadow pass to prevent issue with self shadowing.
Even in a case where you would have a really big landscape and you can see from up high a mountain down a valley, down the valley would be so far that the tessellation wont even be visible. Using foliage could also be a trick to help reduce the LODDistanceFactor even more as you wont see the floor with foliage on it anyway.
Hope this help!
Also why having Tessellation at 0 still cost more than having it at off, is really because of the Tessellation pipeline being used, as even if Tessellation is at 0, you can still provide a displacement map if you have a detailed enough terrain like the one provided in the example.
Michel, I really appreciate your response, but if you are trying to assist me in particular, rather than addressing practical performance issues, those efforts would be of greater use somewhere else.
For the purpose of the project, which I was engaged in while filing this report, terrain rendering was overhauled fitting particular needs. This report remains here due to majority of users, who tried using landscape tess under dynamic lighting, instantly recognizing practical tess cost issues.
I’m stressing the word practical.
In regards to baseline cost, I do not have anything constructive to say for the time being, apart from what was already stated. I did not find any readily apparent cause in the code.
For custom solution, lightening up VStoHS and hull shader helped considerably, but that is not inline of how current landscape rendering works. So overall, baseline cost might be justified as applicable to default landscape. Still pretty high though.
End of part 1 due to char limit.
In regards to shadows:
So how you are supposed to slap together a large world with dynamic shadows while keeping tess in mind?
Correct me if this is wrong somewhere:
You would use world composition, with somewhat realistic tile sizes, lets say 505x505 tiles, 64 components each, scaled at two vertex per meter.
In the worst case scenario, You would only be rendering 4 of such tiles(camera is located near the corner of a tile)
Tiles beyond that, are rendered as single static meshes, ensuring that no landscapes are drawn beyond ~~500 meters in worst case.
You have one directional shadow casting light, with a number of shadow cascades, that is set to cover landscape visibility distance,while using far shadow only for far terrain mesh LODs.
You would set up your tessellation, based on distance, again here, something realistic, like 10 meters. ( Beyond 10 meters tess multiplier is 1).
Now, the culprit here is that you absolutely do not want any other landscape LOD levels to be present in tessellated region, other than the highest one.Obviously, if the landscape starts to transition to lower LOD still in tessellation region, you will get noticeable and ugly movement of the surface.
Logically, you would try to set landscape LOD factor to a such value, that LOD transition happens as soon as possible, but outside tess region(10 meters in our case).
End of part 2 due to char limit.
All would have been fine, if not that fact that to fulfill above-mentioned requirement, landscape lod factor needs to stay above certain value, which is commonly so high(Yeah it is around 3-4 that you mentioned), that landscape slightly further away starts to look like a flashback into 90s. I really have no clue how you can try to offer that as a solution.
At the same time, if you set LOD factor to a lower value, it will result in landscape with tessellation enabled, but having tess multiplier at one, bleeding into shadow cascades, that are not covering tessellated region and normally would have no need to have it enabled, delivering milliseconds worth of shadow depth render time inflation.
In connection with above I propose these potential solutions:
- Introduce some sort of landscape lod
falloff curve, other than linear or
square root, that would ensure fast
drop in near regions and lower drop
in far regions. - Allow to optionally force disabled
tessellation for landscape far shadow
depth rendering. - Allow to optionally force disabled
tessellation for landscape for each
individual shadow cascade separately.
If at this point it is still considered non-issue, feel free to close the question and I won’t post about it any more.
See post below.
@Michel.Dupuis I’m not a coder so I don’t know, but if there’s no apparent error in the code then it might just bad implementation or something like that. On a simple 505x505 landscape having tessellation with 15 multipliers going as far as only 10 meters it costs around 5ms which is extremely high and it’s coming right from ShadowDepths.
No tessellation:
http://uupload.ir/files/lc7a_1.jpg
Flat tessellation with 10 meters radius (from camera to mannequin):
http://uupload.ir/files/1k8h_2.jpg
Really there shouldn’t be such massive cost for just a few thousand tris being shadowed. This report has been flagged as resolved maybe a dozen times since 8-9 months ago but still the +5ms cost isn’t justified. I’d appreciate it if someone take some serious look at this issue. I know tessellation code might be flawless, but there can be other ways to help it.
Hi
What are your settings for the test you’re currently showing?
Can you disable the tessellation and send a screenshot of the Wireframe view?
Also can you go into the ViewMode->Landscape->LOD and take a screenshot of the result, it will show you the LOD setup for the landscape, so take the screenshot from the player POV so we can see well the setup.
Thanks!
Hopefully i can help you resolve your problem.
Hi Michel,
Here’s my landscape settings:
http://uupload.ir/files/jo5l_5.jpg
No Tessellation - Wireframe
http://uupload.ir/files/zr2v_1.jpg
No Tessellation - Lit mode
http://uupload.ir/files/sa4n_2.jpg
Flat Tessellation - Wireframe
http://uupload.ir/files/0w3a_3.jpg
Flat Tessellation - Lit mode
http://uupload.ir/files/saay_4.jpg
Visualizing Landscape LOD = Pretty much lod 0 everywhere since the landscape is small
http://uupload.ir/files/kjul_7.jpg
Increased Landscape LOD Distance Factor from 1 to 10
http://uupload.ir/files/hn77_8.jpg
While keeping LOD Distance Factor at 10 and going back to the original position ShadowDepths cost 0.58 ms cheaper. But still very expensive compared to No Tessellation.
http://uupload.ir/files/khuj_6.jpg
Also I feel it’s important to mention, while increasing Landscape LOD Distance Factor didn’t reasonably reduce the tessellation cost, it destroys the landscapes silhouette too early. Below is a comparison:
http://uupload.ir/files/ds97_11.jpg
http://uupload.ir/files/fm2_9.jpg
http://uupload.ir/files/emzs_12.jpg
http://uupload.ir/files/hscc_10.jpg
Essentially the problem in other words is if you have a flat plane mesh imported in engine with 200,000 Tris and on the other hand you tessellate a small area of the landscape surface and add 100,000 Tris to it, shadowing the landscape ends up costing significantly more than shadowing the mesh.
Continue in second comment due to char limit.
I’m not sure what can or has to be done but for example if you look at Frostbite’s Battlefront, landscape comes with 2 vertex per meter, making it 8 times more dense than what we have here (8 Tris per square meter vs. 2 Tris per square meter), and then tessellation is extended to 15 meters. Besides that all nearby rocks and trees are tessellated as well (up to 7 meters), still the entire game runs above 90 FPS on my GTX 970. I’m really confused as to why we’re not able to reach even 60 FPS here with only small landscape without any gameplay, A.I, VFX etc. going on. It’s true they heavily optimize the content, but we really don’t have any way to optimize Flat Tessellation here other than making it distance based which is what we’ve already done. If you can help reduce the Flat Tessellation ShadowDepths cost and solve this riddle that’d be tremendously helpful for everyone.
Hi ,
I’m currently looking if there is something that can be done to improve the cost a bit, i can’t guarantee anything, but i’ll try.
Simply a small message to let you guys know that i found some way of improving landscape rendering cost(not finished implementing yet), hopefully it will be available for 4.18
That’s great news, thanks for looking into it!
Any details you can share with us at the moment? Curious if this is mostly an optimization effort, or an overhaul
Great to hear. Is it on github yet?
Any updates? 
Hi, unfortunately i wasn’t able to finish it for 4.18, so it will be in 4.19.
As for details i can share, all i can say is that the bigger the landscape (i.e 255x255x2) the better the improvement, and i’m talking in the range of A LOT better
It wont be simply a shadow fix, it’s a big refactor of the whole rendering code for landscape, changing how some stuff is calculated to give better LOD distribution while having better performance. Which mean that mountains at far range will have better LOD than flat terrain at the same distance.
Anyway, i’m close to be finished, and to give an example of improvement, i’m using LandscapeMountains sample as a test project and i resample it to different landscape size based on my test. If i’m using tessellation with a factor of 3 in a 255x255x2 map with a big view of most of the landscape (light in the back to have the worst case for shadow), before it was around 9-10 fps on a GTX 1060, right now i’m closer to 30-40 and i’m also seeing improvement on PS4, not as much, but there is improvement
Also there will bit a lot more info in stat landscape and property on the landscape actor to tweaks to achieve what is desired so perf improvement could be even more or less depending on the settings you will uses, but the default one will be tweaked for better visual and better performance.
Hope you guys will like it
That is great. Especially loving LOD distribution part and eagerly looking forward to it and I think whole community will really appreciate the efforts.
Hello, no i’m saying the improvement is proportional to the landscape size, so the bigger it is, the bigger the gain. For your info, the biggest landscape you can create would be 255x255x2 which would create a 16kmx16km landscape using the Setup