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.
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)
(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).
@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 ?
@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
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.
FarCry5 has a 10x10km terrain at 0.5m density (source: GDC2018_TerrainRenderingFarCry5.pdf - Google Drive). it’s unclear if they switch to “vista terrain” chunks but from that paper it doesn’t sound like it.
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”
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
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?
@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.
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
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.
@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.
@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.
@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)
(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.
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?
@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.
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.
