In previous versions of UE4, the Landscape Grass Type did not have a limit to how high we could set the density. In version 4.22, it caps at 1000. Is this a bug? feature? Is there a way to override the setting?
Bump. This is a problem I’m running into too. Are they trying to get me to use a larger mesh to get more coverage?
Probably a performance thing. I ran into the same problem but will just add more grass to the base mesh instead.
arbitrary limits drive me crazy, how do we override?
you can usually, and almost always, manually type in amounts above the slider maximum without any issue.
This is UI clamped to 1000 so you can’t manually type in a higher number but it looks like you can adjust the limit in the LandscapeGrassType.h header file.The UPROPERTY to adjust is GrassDensity.
Edit: Just tested it out by altering that header file and it works fine to up the density limit.
I’m also running into this issue. Currently the only solution will be for me to modify my assets to include more geo. That has side effects though. It would have to use a larger surface area, meaning that smaller hills/details will have floating grass etc.
Not 100% sure on this. But I’m faily sure the grasstypes system is instanced to reduce drawcalls, so why would more density matter other than to reduce polycount. As long as designers keep an eye on the polycount and don’t do silly stuff (too many material id’s etc) then why not unlock it (Like all other sliders in UE4!). Would be great to have this option back!
… I’m curious as to what it is that you are making to be able to afford over 1000 draw calls per 10 square meters.
What happens if you add trees to the landscape with so many calls literally wasted on grass?
Moreover, if your grass mesh is a patch of 1mx1m you only need a density of 10 to cover the area. You can bump it up to 20 and get a really lush looking zone.
If your mesh is a single bundle of grass it would probably still cover at least a 25cmx25cm area…
That should mean a density of 40 would cover the same area and a density of 80 would look decently lush…
Either way, performance degrades rapidly at 4k, using a 1mx1m mesh at 2,350 to 294 tris set up to cull in less than 5 meters you get decent performance up to 100 density, and a drop of over 30fps with 1000 compared to none (use grass.flushcache).
Refer to this for more tips?
Not sure that helps any, as your marketplace content is generally on point…
I might be wrong about this, but the grass uses the instancing system to merge meshes and reduce drawcalls, from my experience you can use super high densities without affecting performance, as long as you keep sub materials down and shader complexity low it will run just fine. I did comparison tests with High density and Low polycount vs Vice Versa. Both have equal performance/drawcalls due to merging. There probably is some advantage to having a higher density static mesh, but it’s not that significant from what I can see, I’m definitely not making huge wins in performance.
And this is the main issue: Putting more grass blades into a static mesh and spreading it over a slightly larger area (otherwise it looks too patchy) reduces visual variety and leads to floating geometry. For photorealistic scenes this is a big disadvantage. You can see this in my test scene attached, the more density I add to the static mesh, the worse the floating geometry on sculpted landscape.
I believe users should be allowed to push the engine to the limits. We should be free to use huge values and high densities.
You never know what good can come from unlocking a parameter like this.
Why restrict the users with arbitrary limitations.
At the moment I now have to make the choice between patchy grass (a mesh with a smaller surface area has less floaters) or floating grass (caused by larger surface area). The grass system was perfectly adequate before this limitation was introduced.
In a finished scene for camera usage you would just fill the patch up manually with the foliage tool.
in fact you really should do thatdin games as well when needed.
Either way, the question now is, why can you not just add another mesh of the same mesh at max quantity to the grass implementation?
It supports however many mesh you put in, even if you loose on performance because it generates an additional draw call stack.
I agree the limit should probably be lifted. But it is likely there because of memory considerations, or because performance with grass is already very poor (without early z pass) from the start.
It has always literally Crippled the engine performance with the mesh that all of the base tutorials utilize.
What I would like much better is for the automated grass map to be a little smarter, so that the areas off the ground don’t make it in and need manual adjustment.
so far, I have been able to isolate areas in the heightmap based on slope to derive the png to use to paint the smaller variation of the mesh, and the material just subtracts this mask from the larger grass mesh layer.
Also, I just remembered, there is a new system of sort that was showcased by Brucks in one of the streams about water/landscape where the grass can also have children definitions - haven’t seen this on the engine preview yet, but I also haven’t gone looking for it.
It was a cool new concept that looked very similar to the procedural areas for trees/rocks, but used the grass node.
Overall, I would still love it if they parameterized the Alpha value of the paint layer as a variable accessible in the material…
I think you did a good job of outlining the issues there. A lot of improvements can be made to the grass system.
Filling in manually is pain staking for artists and wouldn’t be possible on larger open world maps. Also yeah duplicating a mesh in the grasstype file just to get around the density limit works, but it’s a hacky way to do it and probably creates additional drawcalls or at least needless complexity.
And for sure, tutorial assets should have no bearing on the engines functionality.
I’d be interested to see that live stream if you can remember which one it was btw.