Is it possible to procedurally paint landscape layers from code or blueprints (or even from within the material)? I do not mean creating a multi-layered material using MatLayerBlend functions, but rather to actually paint the landscape layers?
This would be useful if I want to have different hardness outputs (which affect erosion calculations, no?) based on a procedural test, for better erosion simulation.
It’s not possible to procedurally paint landscape from blueprints, but it is possible from C++, although advanced, and only from editor code (not during game, I’m afraid). There are various classes which can edit the landscape, including FLandscapeEditDataInterface.
Alternatively you can pre-generate your layers and then import them into the landscape by right-clicking on layers and choosing “import”.
And yes, “hardness” from the layer info affects erosion, I apologise for the lack of documentation on this.
I figured that would be the case. So what I am thinking is a plug in that would add a delegate to each tick of sculpting, perform some processing to determine results of, say, layer deposition based on the new geometry, then use those results to call the layer painting function. Would that be doable?
The class you mentioned has bupkis for documentation online; is there any online commentary documentation that’d clear up how to use that class? Any tutorials or can I get help from Epic…?
My apologies… I was looking at FLandscapeDataInterface not FLandscapeEditDataInterface…that’s a bit better. How would I attach my delegate function to be called after a sculpt pass? Is that possible?
There’s no easy way to do that, without modifying engine code.
Thanks!
So what about creating a plugin to add a new brush to the landscape tools which first calls, say, landscape hydro erosion and then calls the landscape paint to redraw the layers based on the new geometry? I want to avoid editing engine code as I am hoping to make a distributable plugin.
Unfortunately we don’t currently support custom brushes/tools from plugins. The interface is there (LandscapeToolInterface.h) but there are no register/unregister tool/brush functions.
Gotcha. Thanks much, . I’ll just leave this a suggested feature, then.
Thanks again!
Hi, what’s about this? I’m looking for something similar: i want to paint a landscape based on procedural an other algorithms in order to get a realistic representation of a real-world location, all of this as an auxiliar to the leveling process, not to runtine gameplay.
What do you think about that?
Yeah, I would love to see some script/code access to the landscape for the same reason. I think part of the issue asking such questions is there’s a lot of noise from those who are looking for a runtime solution. Those of us trying to do procedurals in editor time are, I think, getting lost in the fog.
Hey there I’m trying to achieve something similar, did you ever figure anything out with this?
If you dont need it at runtime, then your best bet is to pull slope maps to convert into splat maps from passing your heightmaps into a GIS program.
Basically, you create a function to paint slope values of each pixel within a certain range from black to white, and you have yourself the file(s) to apply as the paint layer for whatever layer.
Its the same idea of how Auto Materials work, except you aren’t doing math at runtime so its way more performant, while also providing better to similar results.
Since modifying the landscape will not change the paint at runtime, you could also just create a runtime auto material to use for testing purposes, out of which you extract the slope ranges needed to extract the files to be used later on…
Ps: the idea of making a runtime editor plugin for this is very interesting and all, but I for one wouldn’t want to build anything onto something that in its current state shouldn’t exist and should not have existed past 10 years ago.
IF they ever actually fix how the landscapes works, then maybe there will be someone picking this up.
Until then, even if they did create a plugin, people using it would be limited to amateurs and indy devs…
Sincerly, both categories are way better off working outside the engine and learning about how things really work, so they can move their projects to less disastrously flawed engines…