Download

Landscape performance issue

Hi dear Epic,

I’m editing this post to give a summary.

**The problem as described best by Chosker.
**

The current landscape texturing workflow in UE4 isn’t suitable for open world projects. The performance cost per landscape layer goes massively high when compared to other engines. To a point where we’re limited to 4-5 layers if we wan to achieve production quality while maintaining acceptable performance. That’s while other engines out there i.e Cryengine 2/3/5 or Frostbite 2/3 benefit from up to 16 layers without massive performance drops since many years ago and have made their documentations available.
We’ve come down to a number of features that can improve the performance. (You know better, of course).w

1) Add ability to work with texture arrays into out of box engine version, including tool to create array from texture assets.
2) Add dynamic branching into material editor.
3) Overhaul weightmaps.( ex. allowing 16 bit weightmaps, storing layer ID rather than layer weight, and ideally allowing you to customize terrain painting brush to the point where you could manually specify the way to encode custom data)
4) Expose terrain heightfield / normal map to material editor( You should be able to sample those in terrain’s pixel shader. Weight maps too btw.)
5) Add a dedicated terrain color map.
6) Untie physical surface ID from terrain weightmaps and allow to bake surface ID from terrain material.
7) Virtual texturing.

Cheers to Deathrey for the contribution.

We’re currently “extremely optimizing” our content, but would like to have some improvements behind the scenes so we can develop our open world projects, add more layers and calculations without downgrading the visual fidelity to 2007 era.

**Quotes from the thread:
**

Please improve it. I’ll provide any sort of demonstration or anything you need.

Thanks.

Giving this a bump as this affects me too.

I have a pretty good idea why. Other game engines are using texture arrays, so the costs of sampling multiple textures are much less.

You can use texture arrays in UE4, just have to manually add this and compile the engine: https://github.com/EpicGames/UnrealEngine/pull/2340

I’m using them, and they are working great :slight_smile:

If texture arrays are the reason other engines can have as many layers but UE4 is limited to ~5 layer before +50% performance is dropped then why is Epic not using texture arrays already?

Texture arrays are functionally a better alternative to texture atlases in regards to terrain texturing, but in the essence, they are prone to same limitations.
Realistically, you cannot blend more that 3-4 sets of textures(by set I mean BaseColor, Normal and Masks).

Last time I’ve checked CE it was 16 layers per terrain, 1 layer per vertex, essentially allowing you to blend up to 3 layers per triangle. Still pretty limiting, but if you ask me, incomparably better than 3 layers per huge component. And you are storing layer id per vertex, not weight of each layer. All that at expense of not being able stretch the blend region for more than vertex spacing.
As for FB, judging from the paper available, it is not much different from UE4 when it comes to terrain layer blending. I think unjustified performance difference comes primary from lack of flow control.

I bet because current terrain philosophy does not really benefit from arrays.

I’d just love to have better blending between the layers. Either somehow decouple the blend mask resolution from landscape res or allow us to somehow modulate the transition between the layers. Height blend is a good start but it’s not that good at blending stuff.

I’ve used CE for so long, but honestly never needed to go beyond 10-12 layers, so even if it’s limited to 16 layers that’s still pretty impressive, given even at 10-12 layers I never had a performance drop. I know that in Battlefield 3 (Frostbite 2) they had usually 10-12 layers per map too (and that was on 2011 hardware) now 5 years passed we’re still struggling with even 4 layers on our terrain which is quite disappointing for non-paragon games. :frowning:

you can make custom transitions by using the layer weight nodes to output a 0-1 mask (instead of your actual layer textures), which you can then bias/modify and then plug into a lerp alpha (which will blend between your actual layer textures). it gets more expensive and since you can’t use the layer switch it gets more cumbersome, but its doable

The default way of texturing landscapes in UE4 is suffering from one huge drawback. Inconsistent framerates. Even if you manage to put your level artist in a cage, and make him plan a level in a such way, that any terrain component does not have more than 3 layers(which is much harder than it sounds), you would still get high framerate fluctuations due to components with only 1 layer rendering faster. Jumping framerate at times can be worse than stable low framerate. FB sorts this out with a virtual texturing.

I suppose you have overkilling textures sizes and complex shaders, i use 8 layers without problem.

Sure sure. Post pictures of your material setup, shader complexity, and landscape size. :slight_smile:
Reading your recent posts on other threads I assume you’re not going to help.

Regardless of my sour answers in feedback, off-topic, and general, (because after 15+ years developing video games in the trenches watching the new generations ask for magic buttons is funny), the vast bulk of my replys are to help.

Of course compared to your maps mine looks like a pony poop (1x1 kilometres). But my maps are designed to run on all possible computers, while you want to push the limits of Ureal engine.

but I just wanted to point out, that in my opinion/experience that the number of layers does not seem to be the main culprit of drop framerate.

bb257fb7e85d795be8b13d08252837d3852bbf4f.jpeg

56f3ea6273664e7dcd7f6a54aa35883640b123fe.jpeg

a4b1bd0b7bd69918d475247ab180bbb1e1a5355e.jpeg

1b05fdd57a11424978bbc861db9f0a8ee83055e0.jpeg

Well that’s the simplest form of making a landscape material. And as you mentioned, the landscape size is too small. When I mention “number of layers” I don’t mean simply “number of layers”, yes we can make 10 layers even with only 2 texture samplers, but setting up every layer with more acceptable settings for an AAA game and having a large landscape means a vast amount of red shader complexity, and that’s where number of layers really counts and that’s where the problem with UE4 becomes way more apparent than you are experiencing. And it really is disappointing a 2007 terrain tech (cryengine) performs worlds better than UE4 on this matter.

OP is unquestionably right about the fact, that landscape performance issue exists. It has been brought up by most of the forum users, who worked with landscapes more or less seriously.Saying that you can use N layers without problem does not change it.

Luckily, it is relatively easy to cure, due to the nature of how accessible the source is. It is just that users would expect whole system to be way more optimized out of the box.
[HR][/HR]
I’d share my experience of adapting to a specific case with minimal efforts.
After discovering that within a given task,
(an island with a bunch of different biomes, unrealistic to go below 14-16 layers and design guys totally refused to mind layer number per component restriction)
default system was a dead end, my approach to designing landscape shader became to blend two 16 texture atlases using 3 weightmaps.

Texture ID for first and second atlas was encoded in weigthmaps 1 and 2.
Weightmap 3 was used to paint second texture atlas over the first one.

At this point I had a working system that allowed having 32 layers painted elsewhere.
The obvious limit was that you could only blend two textures in the same place.
Even at this point, with all the redundant math for extracting textures out of atlas and dealing with mips, even considering it was done 3 times for first atlas, it still ran appreciably faster than if I would dare to do something like that using default layers.

For further improvement, atlases were replaced with arrays and branching was introduced to skip unnecessary projections for tri-plannar mapping.

Concluding, I’d like to say that particular approach is just one of many feasible ways to deal with landscape performance issues and restrictions, and here goes its readily obvious advantages and disadvantages as viewed against default system:

**Pros: **

  • High number of layers
  • Lower pixel shader cost
  • Lower memory footrpint
  • Framerate consistency
  • No inflation for shader compile times

Cons:

  • Only able to blend 2 textures at any given place(It is possible to expand this, but on practice it did not feel limitting at all)
  • Relies on custom weightmaps generated in external software and/or changes to the editor painting tool
  • Relies on alternative way to get physical surface from landscape.
  • Efforts of implementation.

[HR][/HR]

Lastly, I’m going to re-link two feature requests, that I think are quite relevant to landscapes and virtually everyone should casts their votes on:
Generate landscape physical surface from material
dynamic flow control support for material editor

@Deathrey, Have you checked this out? https://github.com/EpicGames/UnrealEngine/pull/2340
[MENTION=24522]John Alcatraz[/MENTION], Can you please talk about what improvements are you getting using that code you linked?

I don’t know if im posting in the right place but im struggling to find a forum header that says engine got ktfo by a shader. i have been struggling with this engine for a good long while and i was looking forward to the new updates to fix the landscape layer issues. so far i have tried every way to set up my shaders with no success. i got to the point where i was mixing my own shaders from a combination of a few textures and some imagination to render approximate hybrids of my 8 or9 textures and finally got to a point where i could paint somthing different to the base texture and my engine crashed and ate my project whole it is now inaccessible and bricked. Im probably knocking out servers across the globe with this shader it is so abhorrent to epic law. I wrote a letter a long while ago about the unreal engine blocking progress and i didnt see one developer using the unreal engine in the indie corner at insomnia, what a shame i think i know why. so unfortunatly unless people who are much cleverer than i get stuck in to this engine at some key places ill be on unity trying to find my way around their system, creating shaders by code and not being pleased to see the results until epic turn it around. Good luck.I Support epics endevours and hope they have news soon to keep me interested in epic, but i cant make maps. engine 4.15 is dead it won’t boot.

@Maximum-Dev Aye, I’ve seen John linking that PR few posts above. Glad that work is being done to merge it and thanks to whoever submitted it.

@john alcatraz yo, how are you building your arrays with that pull request? Are you doing it in ue4, or are you using powerVR?

And yeah, could you post a quick pic of how its working in the mat editor please?

Personally, we are getting ok performance up to about 8 mats, but at 2048, and with not many bells and whistles. Add anything next gen like tessellation and the whole thing rolls over and dies.

It’s something very specific to my project (procedurally generated stuff), I would either have to use texture atlases or texture arrays, where texture arrays are just the way better alternative. With texture arrays I can use a single texture array in a material which can hold hundreds of individual textures and through a second UV channel specify which texture should be rendered.