If a Landscape Grass Variety has a low density, it will not align correctly to Landscape. Groups of rocks, sticks and other horizontal meshes will look like they are floating or sticking out of the landscape.
This can mostly be observed near the edges of a sculpted cliff or in similar areas where the angle is changing strongly.
The only workaround is to increase the density of the Grass Variety or not have any sculpted cliffs in the landscape.
Check the attached/linked project to easily see the issue:
The “normal” is 1m squared by default.
So, if your grass mesh is smaller than that, you can basically guarantee that it will fall outside of the tile and not be precisely aligned.
The thing is it really doesn’t matter.
Proper grass will be longer and dip under the landscape / grow above it as needed via vertex displacement.
Proper vegetation will also grow towards the light vector, which is now possible since the sun/athmosphere updates provide a light vector in materials.
It does matter though, it’s causing weird visual artifact with no great alternative solution, but mainly just waiting for the new GPU scattering tools for PCG at this point, doubt they will touch LGTs now.
With a properly made asset there are no problems, visual or otherwise.
Also the align to grid option is necessary for the grass elements not to fall on the edges of the landscape. The properly made assets would obviate for that as well, but distributing 2 sets of proper assets one on grid and a smaller one off grid would most likely always look best.
Interesting choice of words calling them “bad assets” for not aligning with this tool- something other engines have easily been able to do forever now (the other foliage tools seem to do it correctly too) - you’d assume this tool would be able to correctly align too. But thanks for the info- good to know how it works, I guess it limits what kind of assets you can use with this method.
This doesn’t just happen on this engine.
Likely, a badly made asset is going to be badly placed by any automated system.
Some of the reasons why the asset is bad (if i did not mention them above already) coud be:
Wrong object pivot.
Lack of custom/proper collision.
Badly planned mesh structure.
Too small/too large a mesh.
Badly planned mesh material (grass).
Other engine centric reasons not related to the meshes could be:
Bad landscape geometry.
Bad landscape collision.
Moving the landscape from where the engine places it (can cause grass maps to go nuts).
I’ve used this with good success in the past (oh, just saw your question on there about getting it working in UE5 - it looks like WorldPartition breaks it, it works with a single landscape)
I’ve been thinking - it looks like that plugin is no longer supported, and one of my tools, rdBPtools already enumerates all foliage, and also has a tool for dropping to ground, so it’s a simple task of checking the normal and subtracting a little off the z position - something I can add very easily.
I’m going to add that feature for the next version. If it’s that you’re looking for a solution to give your customers - maybe this will work?
Also, something similar for splines, I noticed your comment that you recommend your customers turn off collision (definitely speeds it up).
I have another tool I’m in the process of polishing ready to release - rdSplinetools that splits up splines into smaller sections that are very fast to edit. The tool is c++ - but to allow for the full spline experience, it has to send commands to the blueprint spline being used to populate the spline (telling each section it’s start position, matching up start-end point movements, and snapping to sockets).
If you were interested in supporting those commands in your own spline blueprints, it would speed up your and your customers editing - and you could advertise it supported the high-speed editing as a feature…
DM for a release candidate to have look at if you’re interested - and here’s the WIP site:
You can see very similar assets in Epic’s own demos or in Quixel’s work.