Auto landscape materials - are they all the same?

Your valid point is voxel, but a decent voxel plugin will already include (or should) an approriate set of materials - or even specific USFs to use and maybe custom material nodes on top.

On the other, maybe you skipped an important byte or 2.

They (automaterials) are pointless because you can trivially produce the paint (slope) maps in any GIS program, apply them as the paint layer, and avoid incurring any per pixel calculation costs.

You can do this near instaly with the very same heightmap that makes up your terrain.

For larger worlds, if you dedicate a day or so in testing how the engine works, and perhaps pull out some hair (like anything in engine?), you can actually set up batches of tiles to import including the material, and the slope maps for the paint layers (splat maps, etc).

You can get a 256km^2 map running in less than an hour or two, even on a shoddy 1080ti thatā€™s as old as the crap with kite mentioned above.
(And more importantly, you could already do so even at the time of the demo inception - making the demo an example that shows you precisely what not to do in productionā€¦)

Whats worse is that the so called auto materials are always performing the calculations, but unrealā€™s landscape is not editable at runtime.
So, unlike Voxel, all that extra cost is just wasted overhead (in an engine that already has a rather compromised rendering pipeline cost!).

Ps: aside from brushify which supports direct paint anyway, I havent really seen any products out there that have any good grass/foliage - and even brushify isnt exactly a Game Ready set of assets. Still, not somthing Iā€™d go actively seeking, as much like you I can make my own (with manicured lightmaps)ā€¦

I believe you have a slightly different interpretation of ā€œauto materialā€ than I do.
I worry less about ā€œwhat is the elevation/slope dependent functionā€ and more about ā€œwhat does the material do to avoid large-scale repetition, and look good and versatile.ā€

After all, a single material slathered over the entire terrain is never going to look good enough. You need to paint in dry spots, mud, trails/roads, cliffy areas, dunes, and so fort.

FWIW, I find the Brushify series of terrain materials hits a good balance between these concerns. Yes, it does the calculation of slope in the shader, which as you correctly say, could technically be pre-calculated, but thatā€™s a cost Iā€™m willing to pay as long as I have a very small team. Once thereā€™s enough resources to spend on runtime performance, itā€™s totally possible to render out the decisions the shader are making, to another texture, and then use that as an additional blend layer.

Of course, then you instead run into the problem of ā€œmore blend layers.ā€ If you target low-end shader models (mobile, Switch, ā€¦) where you only get to use three layers per terrain component, then wasting additional layers on slope variation is probably the wrong choice. But of course it all depends on the look youā€™re going for, and the total amount of people-time available to you.

unrealā€™s landscape is not editable at runtime

With editable landscape layers, they are.

I donā€™t think there is ever any need to incur the cost of slope calculations. It takes about 10 minutes to produce the same map with near 0 understanding of the process.
Small group this, small group that - it honstly just sounds like an excuse for ā€œI cant be bothered to learn a new programā€ - which I somewhat understand, but its an excuse and nothing more.

Unless something changed drastically, the landacape layers work in editor only, not at game time.
And if it is possible at all to toggle different layers on and off at game runtime, the end results are all still pre-cooked - so the slope calculations can also just be pre-cooked.

Regarding the switch, it should be able to handle SM5, so it probably can use shared wrap if you need it to - but given the engineā€™s very low performance, Iā€™m not sure if thata a good ideaā€¦

what is the cost of a slope calculation? surely thatā€™s just the vertex shaders normal in most? Wouldnā€™t it be the sampling of the mixed texture sets that would be the expensive part?

No the slope is calculated per pixel, not per vertex, which is what makes it incredibly expensive for what it provides.
Moreover, the calc is happening everywhere at all times, even if the pixel is already rendered out - which is even more expensive.

On top of that, then, you also have the cost of the different layers - but you probably have the cost of the layers anyway when you paint them with identical slope maps.

The cost reduction is not having the shader continuously processing things it doesnā€™t really need to processā€¦

1 Like

No matter how itā€™s calculated - isnā€™t that branch of code executed while the GPU waits for the samples to return? Or is that just a CPU thing?

Edit:

Iā€™ve just done some tests in 5.4 and Iā€™m seeing the same kind of performance Iā€™m seeing in 5.3 projects, maybe Iā€™m missing something but hereā€™s what Iā€™m seeing on a 4070 (which scales mem speed and cache speed) - it takes that much code to see a noticeable increase in rendertime (just random expensive instructions) - but if I plug the Red of the mask in, itā€™s immediately an increase, larger than that code branch.

The cost / instruction count there is probably obfuscated by the built in function.

Make your own - its better anyway.

Mathematical instructions are always less than new landscape layers (because in short, the landacape is a piece of sā€¦ 20 year old tech thatā€™s never been updated properly).

If you do similar stuff on a mesh, you already have a lot lower of a cost from adding a full on material attributes blend.

Thats the other thing.

A single texture tells you nothing since you have to have a somewaht decent looking end result.

That involves at the very least an Albedo and a Normal map.
Assuming you cheat and derive roughness off the green channel (so grass and foliage is shiny, other stuff is not),
plus plug in whatver else you need off the albedo, and possibly add in or compute heightmaps off the normal map.

The best way to go about it is probably to create a material function that generates your layer.

Then you blend in those final functions.

Now, assuming you blend in with paint, you incur nothing else on top of it.
The material is painted, the layer blend is interpolated and you get your results (Plus or minus height blend).

Assuming you power a lerp (for each different texture/uv group) based on the slope calculation - then the lerp will always be calculating if it should or should not paint said pixel in said way.

All calcs here are always GFX bound - so newer cards means faster speeds.

But because something has a cost you cant quite quantify due to better tech, doesnā€™t mean said cost is neglegible, needed, best practice, or the proper thing to have.

Additionally, you are dealing with a situation where even shaving 1ms off the total GFX load means the difference between a viable game and an unplayable one for the lower end tear of gfx.
So anyone working professionally on anytjing will always optimize everything they can optimize (particularly when there is absolutely no visual downside involved).

1 Like

Absolutely, this was just a simple test. Iā€™ve been testing over the last number of years with various slope routines, 3rd party landscape materials, landscape configurations and things like WP.

Yes youā€™ve already convinced me to go down this road :slight_smile: A couple of questions about it though:

  1. Do you use your own routines for creating LODs with matching outside edges?
  2. Do you store your paint layer type data in vertex data or in splatmaps?

This is the part that Iā€™m interested in the most right now - yes itā€™s free as far as GPU cycles go but there is a cost in footprint (although not massive for smaller landscapes - think something 12km x 12km - it adds up - if you import the layers as splatmaps, it incurs the greatest cost with the most data (although as you point out you could create a blueprint utility to create the layer in a more efficent way)) - if I can guarantee that my slope/anti-tile routines fit within my slowest supported gfx cards read speed I get calculated slopes etc for free, and without any footprint. Itā€™s too enticing to ignore.

Iā€™ll be using a modified lerp that just samples one or tuther when the lerp is 0 or 1 which is most of the time so should give a nice performance boost.

Agreed.

On a custom mesh the calculating slope may in fact be faster.

The landscape is its own concoction - the paint layer must exist for it to work, and even if you donā€™t paint to it, the materials and memory are allocated.

So comparing to a mesh, adding in the extra texture could cost more overall - youd have to bench for worse case scenarios.

Yes if needed. Generally it isnā€™t. Blocks of landscape are merged into one another so you cant see exact edges.

Depends - even RT some times if you need control of it at runtime.
Splat is best normally. Since the meshes are mostly simplified and analytical there arent usually enough vert to paint layers.

1 Like

Thanks! Thatā€™s Gold!

1 Like