I have an auto-material for landscape, that spawn landscape-grass-type.
It works fine on its own.
→ however if i create a level instance with another landscape (with same material(a clone in fact … to test)) … and load it on top of the main landscape … foliage generation is totally messed up for the instanced landscape … it just won’t update at all the modifications made to its material, like totally inputing 0 to the grass node would still make it generate foliage … like both landscape uses the same grass map.
→ i want to avoid manually painting foliage.
→ is there a way to have a grass map per landscape? within the same level?
thanks.
Personally I don’t care much for grass maps. You would be better off just using the (still experimental after 10 years) procedural spawner to spawn in the grass nodes as foliage instances.
And if the landscapes are one on top of the other you really should consider converting to meshes.
However, in a pinch they work fine.
Back in 4.25/27 you also get no grass map issues.
I have a flipped landscape in use as a cave top with painted foliage that works (not grass though).
Honestly, the problem is probably your “auto material”.
ins’t tiled landscape for streaming by distance? Does it make each tile having its own grassmap?
my instanced landscapes are added at runtime, it is not preset.
my goal is to have as few maintenance as possible before i start generating diversity. My loaded instances are basically miniature variation of the main landscape (worldmap vs zoomed zone) … so i would like to use the exact same auto generation for both. That way i wouldn’t have to manually paint foliage, each time i want to create a new variation with different textures+foliage.
my auto material works fine. plus there is really only one node for spawning “grass” … without much place for error.
for now i can get away with manual painting, but in the long run, it will limit diversity a lot.
I have some overlapped landscapes with grass and they do work fine using persistent… doesnt mean that itll work on the latest engine though. Test first.
Your automaterial is the stupid idea here, theres not a doubt abiut that.
Take whatever image you are generating for the heighgmap. Do the slope map on that image.
Output the result as the layer you feed to the grass node. Pre-baked so the load is CPU side not GPU.
Doing that there is likely no way that the grassmaps would clash regadless of wherever you put landscapes.
Also worth noting:
You aren’t supposed to move landscapes. Doing so invalidates/damages the grass map.
There used to be a console command to fix that - they removed it afaik…
Move before applying grass. Don’t move it again.
To fix, perhaps remove the material and re-apply it (won’t work for you though, yours being programmatic. Likely you spawn then movd and it paints. Try applying no material initially and only after the move maybe)
I need the absolute world position node, because the landscape needs to be rocky at higher altitude, plainy at lower altitude … depending on where it spawns.
But it seems you think both landscapes are colliding: they are not. When i said “on top” i meant above it.
Additionally, what do you mean by pre-baked?
i do not move the landscape: i spawn the instanced level(containing the landscape) where it needs to be.
You don’t. The value of the color in the heightmap (which is 16bit, so 1 to 65535) drives the height.
If you have multiple on top of one another (doesnt need to collide) you just need to also do that math:
Object position + heightnap color = local altitude = different layer to paint.
And if you use it as that - to paint a different layer - its probably also less costly performance wise.
Created before the spawn takes place in this case.
Doesnt matter.
Grassmaps are computed in editor only now that i think about it. So its never going to work using grass nodes if you spawn differeng things procedurally at runtime…
Test a packaged build.
why using “Object position + heightmap” when “absolute world position” does the same thing? … or are you saying that an instanced level doesn’t use the persistent level world position? but its own local one?
is it where the interference occurs?
Do you mean “Build/Build grass maps only”?
why do i see grass spawning slowly at runtime then? even if i build grassmaps in editor mode first?
is there some sort of editbox to check somewhere?
Didnt get notified of your reply so this is mostly for other people looking things over.
The object position I was speaking of is the Landscape.
Absolute world position doesn’t tell you anything useful since its just the value you read of the specific pixel (or vert) being rendered.
Just guessing here - if you implemented any material stuff to help rendering, fhats why.
You have various improvments possible. From adjuating the distance to set fade in/fade out amounts to the more performant “moving grass under the landacape using vertex shader based on camera distance”.
Going back to basics.
The issue is that you want the engine shaders to magically waste resources to compute things per pixel but the fact you have a landscape on top of another is obviously hindering whatever WPO based math the shader is told to run with.
Removing that alltogeter, producing a slope map, then filtering the result of that slope map by WPO will get you to reduce GPU/CPU costs while enabling you to render grass where it needs rendering.
Running the slope map + math within the grass shader and disabling grass alltogether (opacity 0) based on the overall WPO height also becomes possible, enabling you to further customize the look and feel, or avoid grass showing up on snow areas without necessarily having to paint specific snow layers.