Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Terrain tesselation and dynamic shadows

While creating a terrain material I've ran into a performance issues with tessellation,namely with shadowcasting.

I am using quite large landscape and one dynamic light with far shadow cascade and having tessellation enabled on terrain material cripples performance. GPU profiler show roughly 5.0ms increased time for shadowed lights, ShadowDepthsFromOpaque. And that is only by just enabling tesselation in material parameters, having tessellation multiplier at 0. I can safely say that I did not experience this issue around UE 4.6 or so.

For the sake of consistency, I've reproduced the issue in a blank project.

  • 1) Create a blank project.

  • 2) Create Default level.

  • 3) Change directional light to movable.

  • 4) Create a new terrain, 505x505 or any larger size.

  • 5) Create a new material.

  • 6) Plug a simple Const Vec3 into base color.

  • 7) Assign this material to the landscape.

  • 8) Check performance.

  • 9) Enable flat tesselation in material settings.

  • 10 Observe unjustified performance drop.

Please note, that it happens only with landscape. If I replace terrain with a mesh of comparable density, I get no shadowcasting performance drop untill i start cranking tessellation multiplier way up.

I'm linking 4 somewhat similar posts I've found. Post1 Post2 Post3 Post4

Product Version: UE 4.10
more ▼

asked Mar 21 '16 at 02:38 PM in Bug Reports

avatar image

7.9k 130 31 293

avatar image AndrewHurley Mar 21 '16 at 03:53 PM

Hey Deathrey,

We are aware of the performance issues with tessellated landscapes and have a report in to improve this feature (UE-14253). I have increased the community interest and added a link to this post to the report. We appreciate you taking the time to investigate and provide additional posts where users are reporting a similar issue.

Let me know if you have further questions or need additional assistance.

Thank you,

Andrew Hurley

avatar image Deathrey Aug 17 '16 at 02:19 PM

Good day. Just noticed that UE-14253 has been marked as resolved in 4.13 Up to 4.13 preview 2 the issue is still present.

avatar image AndrewHurley Aug 17 '16 at 03:15 PM

I just ran some tests and cannot confirm what you are reporting. I followed your steps as well as made a more complex material and did not get any sort of drop in performance when enabling tessellation on landscapes. Below are the contents and results of my test in the 4.13 preview 2 release.

Without Tessellation

alt text

Notice the frames per second.

Landscape Material

alt text

Flat Tessellation enabled with displacement. Created parameters for material instance.

With Tessellation

alt text

This issue is fixed on my end. Let me know if you have further questions or need additional assistance.


Andrew Hurley

avatar image Deathrey Aug 17 '16 at 09:28 PM

Still able to consistently reproduce it in a clean project on 4.13 p2

  • 1) Create new project, blueprints, 3rd person template

  • 2) Create new level, default preset

  • 3) Turn off smooth fps in project settings

  • 4) Make a terrain material, exactly as displayed on your screenshot

  • 5) Set tessellation multiplier to zero

  • 6) Compile material, and create its instance

  • 7) Create a landscape, 505 resolution 63 quads per section, 1 section per component

  • 8) Assign above-mentioned material instance to the landscape

  • 9) Create landscape layer data for two layers, weight-blended

avatar image Deathrey Aug 17 '16 at 09:28 PM

Second part, due to character limit:

  • 10) Paint landscape fully with first layer

  • 11) Paint some spots with second layer

  • 12) Select Light Source, change it to movable, set Far Shadow Cascade to 1

  • 13) Play in standalone process.@1920x1080

  • 14) During play mode while looking from various angles, take several readings from GPU profiler and note Scene/BasePass time and Scene/ShadowDepths. At this point, for me they are averaging at roughly 0.80ms and 0.40ms respectively. That is on GTX 770

  • 15) Close play in standalone window

  • 16) Open landscape material.

  • 17) Enable flat tessellation, disable crack free and adaptive tessellation.

  • 18) Recompile and save the material.

  • 19) Play in standalone process

  • 20) During play mode while looking from various angles, take several readings from GPU profiler and note Scene/BasePass time and Scene/ShadowDepths. At this step my average readings are 1.10ms and 2.70ms correspondingly.

  • 21) Try roughly aligning the camera with Light Source's direction(Sun is directly behind the camera). For me ShadowDepth is peaking 4ms here. Without actual tessellation load

  • 22) If that is not convincing enough, expand the material to include distance-based tessellation, exactly as it is described here, and check how tremendous is the performance hit, even with low values for distance and multiplier. For reference, you can cross-compare performance with a mesh plane, that has roughly 250k vertices. There are no performance issues with a static mesh of comparable density.

avatar image AndrewHurley Aug 19 '16 at 02:56 PM

So I ran some more tests using your newly provided steps and am still not seeing the drop in performance. Silly question, but can you make sure you are on the preview 2 release? Could you also provide me with your 'dxdiag' so I can take a look at your system specifications.

I even increased the Tessellation to 4.0 and the displacement along VertexNormalWS to a multiplier of 25.0 and still did not see an unexpected drop in performance. Made sure 'Crack Free Displacement' and 'Adaptive Tessellation' were both turned off, took multiple screenshots using the ProfileGPU console command, and had no significant change in the ms.

I will say, your new steps are more complex than the original that got the issue to occur which means this could be part of the issue. If enabling flat tessellation on a landscape using a default set up while disabling 'Crack free displacement' and 'Adaptive Tessellation' does not reproduce the original performance drop issue, then it is determined as fixed.

Let me know if you have further questions or need additional assistance.


Andrew Hurley

avatar image Deathrey Aug 19 '16 at 03:33 PM

Good day again, Andrew. Thank you for your time investigating this. Your question is absolutely valid. Yep, I am on 4.13 preview 2, launcher version.Dx Diag file as requested

My screens(windowed standalone,1280@720):

No Tessellation No Tessellation Flat tessellation, crack free and adaptive disabled, zero tess multiplier Flat tessellation, crack free and adaptive disabled, zero tess multiplier Flat tessellation,crack free and adaptive disabled, 4 tess multiplier Flat tessellation,crack free and adaptive disabled, 4 tess multiplier

Now a silly question from me. You are mentioning that you are not seeing performance drop when cranking up multiplier to 4. That sounds dead wrong to me. You should observe performance drop, and with 505 grid tessellated 4 times, this drop should be significant. And your two screenshots earlier from your post show a fps of 120. Please, rule out your FPS being capped by framerate limit or vsync.

I am quite positive that I am not the only one affected by this issue. It would be only to my entire joy finding out, that this issue is in my hardware/software, but whole team is being affected by that. Additionally, users from the forum thread do report the same. There is also another answer hub post on exactly this issue, the one with 50 votes on it.

dxdiag.txt (34.7 kB)
avatar image AndrewHurley Aug 19 '16 at 06:35 PM

Thanks for pointing out the framerate options as I did indeed overlook that setting. With that said, I ran some more tests and can see a performance hit, but nothing outside of what is expected. You can open the images in a new tab to view the original sizes in order to make the text legible.

Tessellation Disabled alt text

Tessellation On alt text

Tessellation with High Values alt text

So as you can see, I am getting a drop in performance in regards to my Scene rendering ShadowDepths, but it is nothing as significant as what you are reporting. The final image is expected as the tessellation multiplier of 4.0 is a pretty high number to tessellate a landscape. The shadow depths are going to increase the more I displace the landscape as well since it is pushing the vertices along VertexNormalWS and creating new shadows.

Let me know if you have further questions or need additional assistance.


Andrew Hurley

avatar image Deathrey Aug 19 '16 at 08:45 PM

Tessellation multiplier 4.0 with Displacement of 20.0 (3d shot) is totally expected. .

~~12% frame render time increase between No Tessellation and Flat Tessellation with zero multiplier(I understand it might lie within normal framerate fluctuations, thought i am never getting frame to frame difference that high, unless something actually changes on the screen) on your hardware(I assume that to be somewhat equivalent to GeForce 900 series) can easily transfer to ~30% on 700 series. around 30% is the minimum difference I was getting between enabled and disabled tessellation. I would really expect virtually no performance difference here.

I see shadows on your shots, thus the camera is not oriented to have light source behind the camera. The reason, why I am specifically pointing out light orientation relative to camera in step 21, is that number of landscape components rendered, when facing away from directional light source is maximal, and minimal, when looking facing the light. The issue manifests itself much more clearly, when facing away(components behind the camera are still being rendered into the shadow map). In this case my total frame render time increase is peaking up to 90% increase between no tessellation and flat tessellation with zero multiplier.

avatar image Deathrey Aug 20 '16 at 11:31 AM

Additionally, as soon as I increase landscape size beyond 505, things go much much worse. Shots for 4k landscape:

No tessellation: No tesselation

Flat tessellation, zero multiplier Flat tessellation, zero multiplier

avatar image Maximum-Dev Aug 20 '16 at 04:58 PM
avatar image AndrewHurley Aug 22 '16 at 03:46 PM

Okay so I looped in some additional devs after completing another round of tests where I was unable to reproduce the same drop in performance you are reporting. In regards to tessellation simply being enabled and using 0.0 as their values, I was given a more technical explanation as to why it is unrealistic to expect no performance impact.

There will be some non-zero cost to have tessellation enabled regardless of the tesselation factor, because with tessellation enabled the topology format is D3D11_PRIMITIVE_TOPOLOGY_12_CONTROL_POINT_PATCHLIST rather than D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST and the adjacency data is supplied to the domain shader, which consumes more memory bandwidth. The domain shader also needs to run for each set of control points, even if it returns 0 or something that evaluates to 0.

With that being said, I ran your tests again and still did not get the same drop in performance. Would you be able to provide me with the test project you are using so I can simply open the project and confirm what you are reporting?

Thank you,

Andrew Hurley

avatar image Deathrey Aug 22 '16 at 09:16 PM

Well, when I mentioned "virtually no performance difference", I sort of accounted for that. There is an overhead, but by all means it can't be held responsible for doubled frame render time on a heightfield as simple as 255K verts.

Link to a project, hope it can clear something up.

My thanks.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

2 answers: sort voted first

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.

more ▼

answered May 26 '17 at 02:01 PM

avatar image

Michel.Dupuis STAFF
120 2 4 4

avatar image Deathrey May 26 '17 at 05:11 PM

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.

avatar image Deathrey May 26 '17 at 05:13 PM

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.

avatar image Deathrey May 26 '17 at 05:17 PM

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.

avatar image Maximum-Dev May 26 '17 at 09:57 PM

@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:

alt text

Flat tessellation with 10 meters radius (from camera to mannequin):

alt text

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.

avatar image Michel.Dupuis STAFF May 29 '17 at 12:56 PM

Hi Maximum-Dev

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.


Hopefully i can help you resolve your problem.

avatar image Maximum-Dev May 30 '17 at 03:38 PM

Hi Michel,

Here's my landscape settings:

alt text

No Tessellation - Wireframe

alt text

No Tessellation - Lit mode

alt text

Flat Tessellation - Wireframe

alt text

Flat Tessellation - Lit mode

alt text

Visualizing Landscape LOD = Pretty much lod 0 everywhere since the landscape is small

alt text

Increased Landscape LOD Distance Factor from 1 to 10

alt text

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.

alt text

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:

alt text alt text alt text alt text

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.

avatar image Maximum-Dev May 30 '17 at 03:39 PM

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.

avatar image Michel.Dupuis STAFF Jun 05 '17 at 11:34 AM

Hi Maximum-Dev,

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.

avatar image Michel.Dupuis STAFF Jul 11 '17 at 12:56 PM

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

avatar image Sickmoocow Sep 01 '17 at 05:38 AM

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

avatar image Deathrey Sep 14 '17 at 09:55 PM

Great to hear. Is it on github yet?

avatar image Maximum-Dev Oct 02 '17 at 12:50 AM

Any updates? :)

avatar image Michel.Dupuis STAFF Oct 06 '17 at 11:21 AM

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 :P

avatar image Deathrey Oct 06 '17 at 02:03 PM

That is great. Especially loving LOD distribution part and eagerly looking forward to it and I think whole community will really appreciate the efforts.

avatar image Maximum-Dev Oct 06 '17 at 02:45 PM


Thanks for all the improvements. I have a question. Are you basically saying that tessellation will now run fastest on the largest landscape size? (largest size being 8129x8129

avatar image Michel.Dupuis STAFF Oct 06 '17 at 02:50 PM

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

avatar image Maximum-Dev Oct 06 '17 at 03:44 PM

Not sure if I'm missing something. With these settings the maximum size I get is 8x8km. Total resolution is 8161x8161 to be specific, which means 8161x8161 meters.

alt text

avatar image Michel.Dupuis STAFF Oct 11 '17 at 11:16 AM

Hmm maybe you're right, i was assuming 16x16 because i'm currently converting LandscapeMountains for my testing and at 255x255x2 i'm at 16kmx16km.

avatar image Sickmoocow Oct 07 '17 at 01:46 AM

Sounds awesome! Will there be any way to increase terrain resolution independent of component size/number of components? For example, let's say I want 4 vertex per meter resolution in LOD 0 for my terrain. Right now the only way to do that is to increase the number of components, which just leads to a ton of overhead

avatar image Michel.Dupuis STAFF Oct 11 '17 at 11:17 AM

No, the underlying mechanic of how landscape are built wasn't touched at all, only the rendering aspect of it.

avatar image Maximum-Dev Jan 18 '18 at 03:24 AM

Hi @Michel.Dupuis

Got some issues with tessellation and shadowing, I have posted some images for you on the 4.19 preview thread here: https://forums.unrealengine.com/unreal-engine/announcements-and-releases/1413780-unreal-engine-4-19-preview?p=1414902#post1414902

Thank you very much for working on this, we really appreciate it.

avatar image Michel.Dupuis STAFF Jan 18 '18 at 11:28 AM

Hi @Maximum-Dev

Can you try not using the VertexNormalWs, i think i saw a jira on my side talking about issue and this.

Also, i know you haven't seen the release note yet, so you probably don't exactly know what changes and how it work.

I'll try to repro locally and see how it goes, but in theory it should work as before, as shadow were not affected in this phase, only rendering optim, LOD distribution changes,more options to control tessellation, etc. The shadow specific one will come for 4.20 as i couldn't finish it in time for the 4.19 deadline.

In any case i would guess if you push the tess multiplier and compare with 4.18 you should see major gains.

avatar image Maximum-Dev Jan 18 '18 at 01:18 PM

@Michel.Dupuis tried without VertexNormal node but still as soon as landscape is deselected these black spots appear.

alt text

If I skip these couple nodes and don't push dark values downwards then it looks fine.

alt text

But pushing dark values downwards and white values upwards is necessary otherwise entire surface just goes upwards and too much clips with player and other assets.

avatar image Michel.Dupuis STAFF Jan 18 '18 at 01:36 PM

@Maximum-Dev Hmm im wondering if what you're seeing is simply not the difference in shadow in tessellation handling between dynamic rendering code path and the static code path.

i.e in Editor if the landscape is selected you will see it rendered in dynamic code path, otherwise by default it's static.

Can you try to use console command without having the landscape selected in the editor, and see if it change something(i.e if you see the same issue then when selecting the landscape)?

Landscape.Static 0 <- Disable static rendering Landscape.Static 1 <- Enable static rendering

If you don't know to enter console command while in the Editor simply open the Output Window, then at the bottom of this window you can type console command there.

Let me know if it change something! :)

avatar image Maximum-Dev Jan 18 '18 at 03:11 PM

@Michel.Dupuis I gave those commands a try, they toggle the issue regardless of which one I enter. For example if I set it to 1 it looks fine then, but if I re-enter it with same 1 value issue is back.

But I got something for you, I'm going to post my results step by step and I've wrote descriptions on the right side of images.

alt text alt text alt text alt text

So basically if we want it to look fine we must keep the settings only like that. We can live with it for now until the issue is solved and we can try different settings.

Just out of curiosity, are you aware of CSM blocky shadowing on smooth surfaces, affecting landscape surfaces?

You can see it in my last image here (this issue is not related to tessellation issues, it's been there since the start):

alt text alt text

Thank you for your time. :)

avatar image Michel.Dupuis STAFF Jan 18 '18 at 03:16 PM


Thanks for the test and clarification, i'll look into it. As for the Shadow blocky effect, it's due to something else that was changed, it should affect everything, not only landscape, and i don't know if it will be fixed for 4.19. (Hopefully :) )

avatar image Maximum-Dev Jan 18 '18 at 03:42 PM

@Michel.Dupuis Loving how the new LOD system works. Shapes hold up much better it's great! :) And yes that blockyness is visible on everything. I was just trying to find out if this issue is known to you because the thread about this went on for 13 pages but nobody from Epic replied yet neither on thread nor on answer hub reports so we really don't know if anyone at Epic is aware of this and has it somewhere on a long term to-do list.

avatar image Maximum-Dev Jan 18 '18 at 04:01 PM

And one last thing. Sometimes when I create a new landscape for testing I see LOD 0 has unequal triangle sizes.

alt text

That's without having tessellation enabled.

avatar image Michel.Dupuis STAFF Jan 18 '18 at 04:09 PM

And it wasn't doing this before? This is simply the morphing applied to LOD that was being done before too. I'll validate if it's something new, in any case it's not having any more impact than before on perf, or anything. The only thing i could think of, is that maybe you weren't seeing it in wireframe mode before.

avatar image Maximum-Dev Jan 18 '18 at 04:34 PM

The issue seems to appear only on specific parts where LOD 0 transition to LOD 1 happens. I'm going to zoom in on these two spots:

alt text

Red spot from close up looks fine:

alt text

Blue spot from close up looks uneven:

alt text

In 4.18 and before, blue spot starts to look just like red spot when approached.

In 4.19 this uneven-ness (new word?) in triangle size makes some tris become way denser than others when tessellation is enabled.

avatar image Deathrey Jan 18 '18 at 11:23 PM

@Michel.Dupuis Finally got my hands on 4.19 preview. Firstly, let me thank You for implementing separate LOD falloff curve for LOD0 and other LODs and especially for allowing to cap tessellation rendering to a certain shadow cascade. Essentially that seems to fix all undue shadow rendering costs for landscape tess.

As @Maximum-Dev reported, you get different results with landscape selected and unselected in the editor. Setting Landscape.Static 0 removes discrepancy between selected and unselected landscape, but also makes landscape tess settings have no effect.. With Landscape.Static 1, everything works fine, when the landscape is not selected.

@Maximum-Dev regarding the shadow artifacts, you have shown on the screenshots, they should only appear in regions, which are located in shadow splits, which already have tess disabled through Restrict Tessellation option, but where displacement in your material is non-zero.

Here is example of what is happening: alt text

Near the bottom of the screen, there is a line where first cascade transitions into the second one. Only first cascade is rendering tessellation. What happens in second cascade, is that it renders shadow depth as if landscape had no tessellation, but tests this depth against a surface, which has tessellation, resulting in a circular region noticeably pushed out of the shadow(I'm using only positive displacement. Should I bias that into positive and negative, there would be mix of overshadowed and unshadowed pixels.). This is totally expected and correct.

Dealing with it involves ensuring that material displacement reliably fades to 0, before it reaches shadow cascade where tess is disabled. In case of the scene on the screenshot, Restrict Tessellation To Shadow Cascade should be set to 1, to include first and second cascade.

avatar image Deathrey Jan 18 '18 at 11:27 PM

Part 2 due to char limit.

With that in mind, testing performance against the same scene in 4.18, drops nearly 3ms on shadow depth rendering. It is also worth mentioning, that with separate LOD curves, one might not even need to restrict tessellation for shadow depth rendering and rely on LOD settings alone, but it is still good to have one .

avatar image Michel.Dupuis STAFF Jan 19 '18 at 12:49 PM

@Deathrey Glad that you like the new exposed stuff, like you said there is a diff between satic rendering and dynamic rendering, i'm currently looking to fix this issue hopefully for 4.19 Release. As for the drop in shadow depth cost, keep in mind, that a phase 2 is closed to be finished that will completely eliminate the remaining case which is dynamic light aligned with the camera direction. With the new stuff it will remove more than 50% of the cost, while also lowering average shadow cost as it will use lower lod depending on the cascade if there is no visual quality drop. In big landscape this will be eliminating a LOT of primitives sent to the GPU while giving the same visual, but with a new setting to control if you want it to be more aggressive or not.

avatar image Maximum-Dev Mar 15 '18 at 10:25 PM

Hi @Michel.Dupuis, We got 4.19 and it's so good thanks to you! I only have one question regarding this, in the first preview build I think there was a way to make tessellation cast shadow a bit further, but in the final release there's no way to do that and we get a hard transition between shadowed tessellation geometry and non shadowed area which is pretty close to camera. Here I'm using 4 cascades with 20000 distance. Is there any way to help this a bit? because it's really not looking good enough as you see here: alt text

avatar image Michel.Dupuis STAFF Mar 16 '18 at 01:08 PM

Hi @Maximum-Dev,

Glad that it's now much better for you :)

This line you're seeing was still there in other version, it's where the cascade 0 stop (if i remember correctly). And should do that with any mesh you're using but it might be more visible in the case of tessellation.

As for the other shadow params, they were simply pushed back to 4.20 with the rest of the phase 2 optim, so all shadow stuff will be together.

avatar image Maximum-Dev Mar 16 '18 at 06:11 PM

@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.

alt text

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.

alt text

alt text

Please let me know if I am being unclear or wrong about this. Thanks.

avatar image Deathrey Mar 16 '18 at 10:59 PM

@Maximum-Dev 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.

avatar image Maximum-Dev Mar 16 '18 at 11:34 PM

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?

avatar image Deathrey Mar 17 '18 at 12:00 AM

Restrict Tessellation To Shadow Cascade is the setting responsible for that.

avatar image Maximum-Dev Mar 17 '18 at 12:28 AM

It was present in preview build, but not in the final release. Sadly that makes this visually unusable until 4.20.

avatar image Deathrey Mar 17 '18 at 01:36 AM

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.

avatar image Michel.Dupuis STAFF Mar 19 '18 at 01:10 PM

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.

avatar image Deathrey Mar 16 '18 at 04:05 PM

@Maximum-Dev 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.

avatar image Chosker Apr 23 '18 at 06:52 AM

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 :(

avatar image Michel.Dupuis STAFF Apr 23 '18 at 11:12 AM


Which master branch are you talking about? as there is currently no 4.20 Branch existing.


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.

avatar image Chosker Apr 23 '18 at 11:53 AM

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 :)

avatar image Michel.Dupuis STAFF Apr 23 '18 at 12:05 PM

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.

avatar image Chosker Apr 23 '18 at 12:19 PM

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 :(

avatar image Chosker Apr 23 '18 at 12:29 PM

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).

avatar image Michel.Dupuis STAFF Apr 23 '18 at 01:07 PM

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?


avatar image Chosker Apr 23 '18 at 01:27 PM

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)

avatar image Michel.Dupuis STAFF Apr 23 '18 at 01:31 PM

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?

avatar image Maximum-Dev Apr 23 '18 at 01:49 PM

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.

avatar image Michel.Dupuis STAFF Apr 23 '18 at 01:52 PM

@Maximum-Dev What list are you referring to?

avatar image Chosker Apr 23 '18 at 02:00 PM

would be lovely to tackle all the landscape issues and feature requests, but while we're on this thread I'd love to focus on the tessellation issues otherwise we'll never get anywhere ;)

still would be awesome for Epic staff to read up that forum thread though

avatar image Chosker Apr 23 '18 at 01:57 PM

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

avatar image Deathrey Apr 23 '18 at 05:06 PM

Landscape had been switching to a shader variant without tess for LOD1 and onwrads since 4.14 i think.

avatar image Chosker Apr 23 '18 at 05:49 PM

never heard of this feature. but that would mean that forcing the landscape to LOD1 (and beyond) would completely avoid the base cost of Tessellation, and I frankly doubt this has ever been the case (otherwise the base cost of tessellation on huge landscapes would never have been so big)

anyway this behavior changed in 4.19. Landscape has tessellation at all LOD levels now/again, and the new landscape actor's tessellation properties control the curve and range of landscape tessellation reduction on the fly as a means to re-add the distance-based tessellation that got lost with switching landscape LOD from distabce-based to screenspace-based

note the emphasis on 'on the fly', which is what makes me suspect there isn't a tess-less switch at any moment

avatar image Michel.Dupuis STAFF Apr 23 '18 at 06:04 PM

It used to be LOD0 Tessellation, and LOD1+ Material with No Tessellation. Now user control up to which component screen size should we apply tessellation after that the behavior is as before, we use a material with tessellation off.

Even in the component that got the tessellation enabled material, there is a falloff that can be controls in settings to further improve the perf of tessellation.

avatar image Chosker Apr 23 '18 at 06:16 PM

well then. by setting the Landscape's TessellationComponentScreenSize to 1.0 and TessellationComponentScreenSizeFalloff to 1.0 (effectively reducing tessellation as much as it's possible, since they are both capped at 1.0) I get tessellation in really just 1 landscape component. how to explain the big cost?

alt textalt textalt text alt text

avatar image Michel.Dupuis STAFF Apr 23 '18 at 06:20 PM

Can you show your wireframe? Tessellated component will be rendered white, and you should be able to see if the falloff is working or not by moving around in the editor, the far rendered triangle from the component should not feel more opaque then the one close to the camera. (Obviously hide the rest of your actor otherwise it will be hard to see)

And as i already said, a factor of 1 should have no visual impact, it wont subdivide your triangle.

avatar image Chosker Apr 23 '18 at 06:29 PM

sure thing, here it goes alt text

everything appears to be the exact same tone of grey though, I don't see any of this white vs more opaque polygons. it's just a more dense wireframe on the exact same shade of grey.

and to re-iterate, this wireframe is with a Tessellation Mutliplier of 1.0 in my material instance. only with a value of 0.0 do I get tessellation to appear completely removed. so a factor of 1 really does subdivide my triangles.

these are my landscape actor settings in case you're curious alt text

as you can see I push the LOD distribution a lot and the far away mountains are really low poly.

changing the TessellationComponentScreenSize and TessellationComponentScreenSizeFalloff values do have an impact on the falloff as you say, so that seems to be working correctly. but of course lower values than my current 1.0 means even more tessellation

tess-result5.jpg (1.3 MB)
tess-setup2.jpg (64.2 kB)
avatar image Michel.Dupuis STAFF Apr 23 '18 at 06:32 PM

And if you do a stat gpu, with those settings, what it look like?

avatar image Chosker Apr 23 '18 at 06:37 PM

with stat gpu it looks like this, (also in comparison with/without tessellation - shadows are enabled in both cases)

I kept my skybox and my little test box hidden btw

alt textalt text

avatar image Michel.Dupuis STAFF Apr 23 '18 at 06:39 PM

What are your shadow cascade settings?

Also where is the light compared to your camera?

avatar image Chosker Apr 23 '18 at 06:45 PM

here's my shadow cascade settings:

alt text

and the light compared to my camera (hope this one makes sense)

alt text

for what it's worth, a completely top-down light results in the same performance

tess-setup3.jpg (91.9 kB)
tess-setup4.jpg (302.5 kB)
avatar image Michel.Dupuis STAFF Apr 23 '18 at 06:49 PM

Those last things, would be helped with my last optim i made, that might be put in 4.20.

Unfortunately for 4.19.X this is as good as you can get.

Increasing to a tessellation factor of 2, does your performance changes a lot?

avatar image Chosker Apr 23 '18 at 06:55 PM

Tessellation Factor performance:

  • factor 0.0: 58 fps / 17.2 ms

  • factor 1.0: 54 fps / 18.4 ms

  • factor 2.0: 50 fps / 19.8 ms

  • factor 3.0: 47 fps / 21 ms

  • factor 4.0: 44 fps / 22.2 ms

sad to hear that having no tessellation at all vs tessellation on one single component will drop my FPS from ~101 to ~58

however I can wait for 4.20 and more, it's just important that the slowdown is acknowledged by you guys (and improved upon)

avatar image Deathrey Apr 24 '18 at 02:40 AM

@Chosker I only tested landscape tessellation in 4.19 preview, and to be fair, I did not experience performance issues, that I would be considered undue, provided the landscape is set up right.

@Michel.Dupuis Michel, wanted to bring up one more tess-related issue. It is depth pre-pass.

Well, on practice, I doubt I'd ever use depth pre-pass on landscape at all. Landscape is just too heavy and most importantly, it is kind of object with naturally low overdraw.

And lastly, with tess enabled, you are paying twice the cost of landscape tessellation for base pass. How about allowing to optionally disable depth pre-pass for landscape?

Or alternatively, optionally disabling tessellation in landscape's depth pre-pass ? I'm pretty sure, gentlemen, who are into landscapes, can live with being restricted to use only positive displacement, if it doubles tess performance for base pass.

avatar image Chosker Apr 24 '18 at 06:18 AM

can you please elaborate on having "the landscape is set up right." ? all I did was take AffordableLandscapes from the marketplace, opened one of the maps (an 8k landscape, 255x255 quads/section, 1x1 sections/component), deleted everything except the landscape itself and the skybox, and set the landscape actor scale to 0.25 to test having 4x4 quads per meter. then I modified the LOD settings to be more aggressive than default.

if there's some secret to making tessellation not half my FPS when applied to my landscape, by all means share it! :)

I wonder how big was the landscape in your test in the 4.19 preview?

avatar image Chosker Apr 24 '18 at 06:30 AM

@Michel.Dupuis here's a new test I did:

  • I made a copy of my landscape material and disabled tessellation on it

  • then I selected all components except the 4 closest to the camera, and applied the non-tessellated version to them as Override Material

alt text

in theory this the same thing the engine is doing under the hood right?

now, this is the result: alt text alt text

the performance difference is very significant at almost a full 2ms. could there be something off in how this is handled?

the wireframes look exactly the same btw

tess-result8.jpg (1.1 MB)
tess-result9.jpg (1.1 MB)
tess-setup5.jpg (218.0 kB)
avatar image Deathrey Apr 24 '18 at 09:55 AM

@Chosker Set up right involves: 1) Avoid using 8k landscape, when practicable. You can't LOD it efficiently, thus your LOD0 will still take huge space, even if you are running 1024 components. You can't layer it efficiently either. Rely on world composition and smaller landscapes. 2) LOD agressively. 3) Set up shadow cascade splits in a such way, that your first cascade fully encloses components with tessellation enabled. In 4.20 this would change to Set up shadow cascade splits in a such way, that your first cascade fully encloses displaced region. 4.19 Preview version had a core change, that did not make it. It is the essensce of this answerhub talk and without it tess shadow costs are still fubar. Whatever you do, you can't afford rendering landscape components, where tessellation is enabled, into more than one shadow cascade. 4) Disable early z pass in project settings.

@Michel.Dupuis Speaking of an 8k landscape in 4.19.0, is there any partcilar reason why you can't use component tessellation screen size higher than 1 ? And adding to that, why you can't push LOD0->LOD1 transition earlier?

Here is an actual LOD0 picture. You can't push it closer to the cam. Nor you can force tess cutoff kick in earlier, which you definitely should be able to do. alt text And here is expected components, where tess should be enabled: alt text

actuallod0.jpg (44.1 kB)
expectedlod0.jpg (45.1 kB)
avatar image Chosker Apr 24 '18 at 10:31 AM

ok so,

1. I only use an 8k landscape to downscale it (to 0.25 scale) and get more density (1 quad per meter is far from cutting edge).

but this already means my components are not taking a huge space. what about having more+smaller components though?

I could try world composition but then I'm just going to improve upon the far-range stuff, which isn't really that expensive with my current setup. with an 8k landscape downscaled to 0.25 scale I have a 2x2km landscape, which means I have an average of ~1.5 km view distance. world composition would pretty much destroy this already limited view distance. unless I use proxy meshes... but at this point (where my far landscape components are basically 4x4 quads, and my material is super simple) the landscape should in theory by superior performance-wise to using meshes.

unless something changed drastically in the past couple of years, world composition is just a tool to hide/unhide chunks of landscape, but in fact provides zero benefit if you want to keep to the same view distance (in fact when I tried it 3 years ago the performance was worse... https://answers.unrealengine.com/questions/233228/why-is-a-regular-landscape-2x-faster-than-a-tiled.html)

Layering: I don't see how layering is relevant at this point. I'm merely comparing tessellation vs non tessellation. I'll fight the layer battle later (I'll limit it to 4 layers per component and I'll make dynamic branching on custom nodes)

2. I already LOD aggressively. see my wireframe screenshot above.

though again this is a 'general' thing and not a tessellation-specific thing.

3. I could do that, but then it means close-range shadows will be really low-res. at this point my tessellated region is quite big (because the components are big, even if they are at 0.25 scale)

I'll try it anyway, if at least to mitigate the impact for now.

4. disabling early Z pass had zero impact


avatar image Deathrey Apr 24 '18 at 11:33 AM

1) Up to this day, I am not aware of any shipped or soon to be shipped decently performing titles, that would be using heightfield this high res. I would recommended opting in for using 1k resolution, coupled with world composition. This would mean having not more than 4 landscapes rendered at a sigle time and allowing you roughly up to stunning 250 meters of heightfield view distance in any direction at grid spacing of 4 vertices per meter. Everything beyond that, would be rendered as vista terrain(level LODs). Subjected to number of components in a single landscape and the landscape LOD level, you are using to bake vista terrain, but overall, rendering level LOD is unquestionablly faster, than a heightfield.

In regards to tessellation, however, this is in direct correlation to how efficiently you can match terrain component size to tessellated region. The lower the component size in world space is, the tighter the fit is. Same applies to shadows. The smaller your component is, the tigther you can fit it to shadow cascade. It all boils down to maximising ration between area, that uses shader permutation with tessellation, and area, where displacement is applied. The change, I original suggested to Michel and mentioned in previous comment, decouples active tessellation in shadow rendering from component size, but the principle still applies. Gotta wait for 4.20 for this one it seems.

Efficient layer splatting is just a pleasant side effect of this approach, but it indirectly improves tess performance too. Sampling and blending those heightmaps does not come for free in domain shader. Not directly relevant to the discussion though, indeed.

3) Yes, you can and should do that. It is essential. No way around it. Directly relevant to what I laid down in item 1.

Again, the change, that did not make it into 4.19, but was present in 4.19p, adresses that in particular. (charlimit)

avatar image Deathrey Apr 24 '18 at 11:33 AM

(charlimit) 4) Z-Prepass, when it is enabled, means that you are paying tessellation costs additional time. It does have a noticable effect. If it does not for you, double check, if pre-pass is not being forced on by something else(ex. dBuffer decals).

avatar image Chosker Apr 24 '18 at 12:28 PM

1) FarCry5 has a 10x10km terrain at 0.5m density (source: https://drive.google.com/file/d/1H6ouhi96pLg8WDlwXSGHFupPyZDv2MF6/view). it's unclear if they switch to "vista terrain" chunks but from that paper it doesn't sound like it.

SW Battlefront 1 had 8x8km terrain with 1x1km playable area (source: https://www.gdcvault.com/play/1023272/Photogrammetry-and-Star-Wars-Battlefront), and then background meshes further from that. terrain tessellation goes up to ~15 meters. terrain density is not mentioned.

Ghost Recon Wildlands had a 32x32km terrain (sources: https://www.gdcvault.com/play/1024029/-Ghost-Recon-Wildlands-Terrain / https://80.lv/articles/procedural-technology-in-ghost-recon-wildlands/) with 0.5m terrain density, and also tessellation on top.

obviously these are highly specific openworld outdoor games. then again UE4 is advertised with catchphrases such as "Photoreal Rendering in Real Time" and "large, open world environments with [...] terrains that are orders of magnitude larger than what has been previously possible" :P

sure I can cut off my landscape and replace it with proxy meshes with world composition. it's probably even a necessity to achieve good performance (in UE4) once the rest of the level assets are in place. but the entire point I'm trying to make is that it's the close-range tessellation (those 4 components around the camera) that are causing the huge slowdown

I'll play around with component size and shadow distance to try to achieve a better ratio vs how it plays with tessellation. but I don't think I'll have a proper result until 4.20

also I know blending the heightmaps has a cost... and that's exactly why at this point I'm only testing with 2 layers. I'm aware things will get more costly as I add 'features' which is why I aim to reduce this [already big] baseline

4) the rest of my settings are the engine default. Ill doublecheck if DBufferDecals are enabled. do you know other things that could be forcing the prepass?

avatar image Deathrey Apr 26 '18 at 10:56 AM

@Chosker I am well familiar with the papers, you've linked, and they do not contradict with what I mentioned. 10km squared playable map not equals to 8k heightfield in UE4. Whatever way of heightfield rendering you choose, you need ways of lodding and streaming it in. I won't deny that working with world composition is a bit on a painful side in UE4 and I would gladly see terrain rendering overhauled, but as of now, there are no alternatives and as applicable to UE4, for large world, you can and should use world composition. And the way you set it up, will directly influence the efficiency of rendering it, including setting up tess for maximum performance. It does not mean that using 8k 1024 components landscape is a taboo. It is just that it would not be as efficient, as splitting it into 16 2k sectors 256 components each. Both ways, you'd have 1024 draws for the heightfield, but latter one would require extra 12 draws for level LODs, but you would have much more agressive LOD, significantly better layer splatting, more efficient shadow and tessellation rendering, as well as cheaper shading on distant terrain. Have in mind, that most games, making use of tess with dynamic shadows, optend in for not having tess rendered in shadow depth at all and accepting the shadowing mismatch it causes. If you ask me, I see no reason why you can't force disabled tess for shadow depth pass per material instance in UE4. It does not only apply to landscape tess.

Also, in 4.19, whatever way you set your LOD, the cap of screen size of 1 does not allow you to transition from LOD0 to LOD1 early enough. (charlimit)

avatar image Deathrey Apr 26 '18 at 10:56 AM

(Charlimit) There are a ton of other features, that would be useful for landscape rendering, for example: texture arrays, custom material node operational in tess input, splatting to a virtual texture, heightfield-based far shadow cascade. The latter one would be actually quite useful for shadow performance at high distance. But it is unrealistic to expect them implemented in stock engine in overseable future.

Meanwhile, we can just hope for ability to restrict tess to a certain cascade brought back in for 4.20.

avatar image Chosker Apr 26 '18 at 12:54 PM

from the papers I can't directly infer if they stream components in place with proxy meshes or if they keep them all visible and simply LOD them. but I can agree that expecting 10km-long vistas on pure heightfield-terrain would be naive :)

once again I've just been wanting to mitigate the cost of Tessellation though. since I started these tests everything was in a really good state with tessellation off.

anyway I made some more tests with my existing 8k landscape. I changed the sections per component from 1x1 to 2x2, disabled all pre-pass stuff and played a bit with the shadow settings to try to match the cascades with the tessellation. I managed to get a solid 80-90fps regardless of where I move or look at (with the landscape occupying the entire screen). surprisingly the key factor was the sections per component, and the 2 other things had quite a little impact.

at this point I didn't compare the tessellated vs non-tessellated landscape but I'm sure the difference won't be as big as in my previous shots.

for me this is already a very good baseline considering I have a density of 4x4 quads per square meter -at some point I'll test with 2x2 density and a 4k landscape instead, so same world size but half the density-, and that I could reduce the view distance using fog so I can stream components in/out, and that 4.20 will improve the shadow part even more :)

of course some extra control over things would be welcome, so all the things you mentioned would allow freedom for everyone to decide which corners to cut. and of course "better features" might still come (virtual texturing is on the roadmap. UE4 4.30 maybe?)

also I wasn't aware that the custom node isn't available for Tess output btw, so thanks for the info. it will prove problematic when I attempt to use dynamic branching :(

btw when you say "significantly better layer splatting" do you mean that proxy meshes would use a pre-baked texture rather than actual painted layers? or do you mean something else?

avatar image Deathrey Apr 26 '18 at 07:48 PM

@Chosker custom node input for tess multiplier would allow you to use a little trick to have lower tess multiplier in shadow depth passes, further increasing tess performance. By better layer splatting I mean lower component size in world space, which commonly results in less layers being present on a single component.

avatar image Michel.Dupuis STAFF Apr 24 '18 at 11:13 AM

@Deathrey Because it wouldn't make sense a factor of 1 mean, if the component size is >= 1.0 on screen then apply this tess settings.

I'll look to be sure there is not a edge case there, but in theory this is why it's maxed to 1.0, the same as the screen size for static mesh wouldn't make sense being >1.0

avatar image Deathrey Apr 24 '18 at 11:42 AM

@Michel.Dupuis But it does make perfect sense, that, you should be able to restrict tess to the components, I've marked on the shots above, doesn't it ?

avatar image Michel.Dupuis STAFF Apr 24 '18 at 11:53 AM

@deathrey I just confirmed,

What we do is this:

ComponentScreenSize >= UserSpecifiedTessellationComponentScreenSize.

Which mean in your case: ComponentScreenSize >= 1.0 -> Tessellated.

It could be changed to support > 1.0 to restrict tess maybe even more let say you put 1.5 it would not tessellated much stuff, as most of the time when standing on a component, the size is ~1.0-1.5.

I will have to try it, to be sure it's not breaking anything else.

Unfortunately this kind of changes will have to be done for 4.20 not 4.19.X.

avatar image Deathrey Apr 24 '18 at 02:58 PM

@Michel.Dupuis Yep, I completely agree that in common cases screen size of 1 is enough, but as one can see, with larger components you might need more leeway. Probably the same could be applied to the LOD itself too.

What about depth pre-pass though ?

On a side note, cheers for communicating, even if not obliged to. It is indeed very valuable.

avatar image Michel.Dupuis STAFF Apr 24 '18 at 03:13 PM

@Deathrey I'll have to investigate for the pre pass as you suggested.

avatar image Chosker Apr 24 '18 at 03:13 PM

I'd second more agressive options for both LOD and Tessellation.

I also kinda miss a bit of control over how LOD works on the Landscape, as I find that areas in the mid-range could be reduced more (but without completely killing the far range quality)

anyway Michel I also want to thank you for your continued comments and support :)

avatar image Michel.Dupuis STAFF Apr 24 '18 at 03:29 PM

The goal was to keep it simple so i divided it between LOD0 (which is the most expensive to render) and other LOD (which do not cost much to render anyway), but if we wanted more control i guess using a curve to define the LOD transition, tessellation would give you the flexibility you want but not necessarily improved FPS.

avatar image Deathrey Apr 24 '18 at 04:51 PM

@Michel.Dupuis I hope you can tolerate all the spam in this thread today. Wanted to bring your attention to one more fact. Unfortunatelly I am unaware what you have laid out for 4.20, but as for 4.19, there is a following observation:

With landscape component tesselattion screen size set to 1.0, I'd expect every component, that has screen size of 1.0 or above, to be rendered with tess enabled, both for base and shadow pass. What about components, that are completely outside of view frustum, but are within the cascade frustum ? And how is LOD selected for landscape components, that are outside of view frustum ?

With low directional ligth angle, 7 cascades and huge shadow distance and low exponent, facing the directional light, I get absolutely expected performance. 2.0ms for base pass and 0.5 for shadow depth pass. When facing away from the light, shadow rendering spikes to 12 ms. It is obvious, that more components enter cascade frustum, but to me it undoubtedly sounds like every or almost every component, in the cascade frustum, but outside of view frustum, has either tessellation enabled, or inappropriate LOD level, or combination of both. It must be so, because there is shadow depth rendering spike, 8ms worth, even with tess disabled on material.

avatar image Michel.Dupuis STAFF Apr 24 '18 at 05:45 PM

@deathrey the second optim was to give options to help improve this particular case you describe, when the light is directly in the direction of the camera, it will have to process all components (or close to) to generate proper shadow projection, so if the component had tessellation, shadow will be tessellated/processed even if disabled.

As for how LOD are selected for component outside of view frustum, it's simple, if they cast shadow that will be seen in the view frustum, we compute their visibility as if they were visible.

avatar image Chosker Apr 23 '18 at 06:06 PM

so here's how I use Tessellation in my materialalt text

tess-setup.jpg (333.7 kB)
avatar image Maximum-Dev May 13 '18 at 06:01 PM


I tried deleting my distance based tesslllation calculations and use the built in feature but tessellation component screen size/fade in landscape settings doesn't seem to be working on 4.19.2.

avatar image Michel.Dupuis STAFF May 15 '18 at 06:30 PM

Hi, it should be, the last time i tried in it was working fine.

Can you tell me what you're doing/expecting?

Thanks :)

avatar image Deathrey Jun 06 '18 at 04:48 PM

@Michel.Dupuis So the changes, you were talking about, did not make it even into 4.20p1 ? Still can't set landscape LOD / tess falloff properly.

avatar image Michel.Dupuis STAFF Jun 06 '18 at 05:06 PM

@Deathrey: no unfortunately it should be available in 4.21-4.22.

avatar image Maximum-Dev Oct 26 '18 at 08:25 PM

Hello @Michel.Dupuis, Any updates for 4.21 ?

avatar image Michel.Dupuis STAFF Oct 26 '18 at 08:33 PM

No, unfortunately i'm working on something else for now, if i can finish my stuff, maybe it will be for 4.22, but can't guarantee it.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

Thanks for the test project. I was able to confirm what you are reporting and have gone ahead and entered a bug report for the issue. You can track the issue following the link below on our new Public Issues Tracker.


Once the issue has been addressed by our engineers, the fix will be added to the release notes for fixed issues within an upcoming full engine or hotfix release.

Let me know if you have further questions or need additional assistance.


Andrew Hurley

more ▼

answered Aug 23 '16 at 03:16 PM

avatar image Deathrey Aug 23 '16 at 05:04 PM

Glad that you were able to reproduce it finally. Just have to say that I don't state that the issue is view angle dependent between the directional light source vector and the player's view angle, like it is stated in the ticket. That is number of landscape components required to be rendered depends on that. It is not part of an issue and was referenced here to better highlight performance difference.

avatar image Maximum-Dev Apr 28 '17 at 12:50 PM

So it's been 8 months. Did this bug report fall off the table?

avatar image AndrewHurley Apr 28 '17 at 01:58 PM

No, it is still on the horizon to be fixed. As you can see it is marked as backlogged which means it does not have a high priority at the moment.

avatar image Maximum-Dev May 10 '17 at 04:44 PM

Alright thanks. Can you please update the Affect Versions to show 4.15.1 too? And on a side note, Andrew, can you help us out a little? I know it's not a priority for Epic's internal projects but we've all been waiting for a very long time for this fix and it's crucial for a large number of projects, what should we do so the engineers take a look at this?

@Deathrey, It does seem view angle has some influence here too.

Looking towards directional light:

alt text

Looking behind:

alt text

avatar image Deathrey May 10 '17 at 10:44 PM

Yeah, increased cost when looking against the light is expected, since more landscape components are in shadow frustum.

Earlier in this thread Andrew mentioned 12 control point vertex data being responsible for increased baseline cost. This is not the case at all, because for flat tessellation without crack free displacement 3 point patch data is used, but ugly baseline cost issue still persists. The issue should be somewhere around vertex factory->hull shader(something gets interpolated more times than needed? At first glance HStoDS struct looks a bit strange too.)

In addition to that, for better tessellation performance there should be an option to allow you to selectively render shadow depth with tess disabled for each cascade separately. In typical usage scenarios you are extremely unlikely to still have tessellation beyond 1st/2nd cascade. In theory 4.13 change not to render tess past LOD0 should have dealt with it, but on practice LOD0 is commonly present in all cascades, making that change arguably useless for dynamic shadows.

avatar image Michel.Dupuis STAFF May 19 '17 at 01:11 PM


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)

avatar image Deathrey May 19 '17 at 05:37 PM

Pardon me, I haven't really understood your question :P

avatar image Deathrey May 23 '17 at 06:05 PM

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.

Linking again relevant threads here: One Two

avatar image Deathrey May 26 '17 at 07:34 PM

See post below.

avatar image Maximum-Dev Jul 19 '18 at 05:53 PM

Hello @Michel.Dupuis,

Congratulations on releasing 4.20. I just wanted to ask if you've been able to push the remaining improvements to the final version of 4.20 yet?


avatar image Michel.Dupuis STAFF Jul 19 '18 at 05:58 PM

No unfortunately, as i said previously, it will be in 4.21/4.22.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question