I’ve watched 3 tutorials on how to do PCG grass, and they all use a Static Mesh spawner to place the foliage. This seems like it would be inefficient. There’s already both a Static Mesh Foliage actor and a Landscape Grass Type actor in UE, so you’d think we’d have a way to simply spawn those instead of spawning a static mesh.
The PCG interface just seems a little alien to me at the moment, so I can’t figure out how.
Spawn Actor doesn’t seem to work when I’d image it should.
Any thoughts?
The PCG static mesh spawner uses HISMs to place meshes, same as foliage types. Basically a different, much more flexible format the for the data. Landscape grass is its own (old outdated) system that is being replaced by gpu PCG. The old systems may still have use but have baggage that doesn’t make sense to drag into PCG.
Ok, fair point. Just seems strange that if a Landscape Grass Type already includes the data for multiple meshes and culling distance, you’d think you could grab that.
I see what you’re saying. Epic could have used the same data assets and build a PCG system around them to do similar so it would be more plug and play.
Now that PCG is ‘production ready’ we might see some of this? I kinda doubt it as it seems like they are just fully ditching the old stuff for PCG. It makes sense to me, the older systems were a bit half-baked. PCG is far more powerful once you get comfortable with it, esp runtime and gpu gen, not to mention PCG-Ex.
Pcg is its own thing but the baseline issue is the same.
You don’t use BPs because of cost associated with it all. (Mind you, you probably can, its just bad practice and a bad idea).
To get a BP up and running you need an AActor. And its got tick, plus whatever else you code in it, then possibly skeletal mesh.
Once you spawn up about 100 instances or so you’ll start to dip into performance quite heavily. And if you incorrectly use tick or even just have them set on the incorrect group you pay computation costs that shouldn’t even exist.
Compare this to a regular HISMC that you can even self manage without PCG. All it stores is a transform value for each instance along with the mesh index that it uses. No tick, no issues. Plain and simple. And it can have billions instances because if it’s simplicity.
The grass on landscapes is/was its own thing with its own pipeline that actually outperforms both HISMC and foliage. It was not the best it could be (in fact there was much it left to be desired like anything epic made), but it did offer some somewhat reasonable improvement if you had to use landscapes and couldn’t just do what you should always do and use static meshes instead.
Second to landscape grass is the foliage tool.
That works a little faster than HISMC because of pooling and aggregation. Since it was designed to work on landscapes it clustered (back in 4.18 at least) the rendering up to different blocks, making them load and stream in faster with less drawcalls.
Then you have the regular hierarcical instanced static mesh component; There is no real clustering here. Each instance is subject to its own calculations for occlusion which is costly and sometimes actually demented when used for foliage - but it is what is avaliable and therefore what everyone uses.
PCG grass is slightly faster than a regular HISMC probably - but what PCG really does is it allows you you pick and choose placement much better and without having to create your own tool to do so like it would otherwise be when dealing with a regular HISMC.
With all that in mind:
The engine does a ■■■■ poor job at grass - look up some ghost of tsushima dev talks for how grass should be made and actually optimized.
Take that further. The storage of grass data should really just be a flat file of sequential numbers rather than meshes in the first place (I’d link you to a video explaining this, but need to find it. Will edit if I do).
And then you have the obvious issue with foliage itself (trees brushes rocks etc).
You don’t want these to be blueprints because of what I wrote above - but if you do still want to make them interactible, that’s when you create a replacement system similar to my plugin ( DynoFoliage: UE4 Interactive Foliage ). In essence, the immidiate area around the player swaps out instances off from foliage on the fly with something else (a BP of said foliage that has an SKM of said foliage for instance).
That way you have instances and counts that aren’t necessarily proibitive while still being able to support AAA style interaction.
With regards to re-using the UI/Info inside the landscape grass node, and its assets - they are exclusive to it because of the special rendering the engine does with them. Unlike foliage they were specifically designed to he kept and keyed separately making things even more confusing. I do agree with you that they should have re-purposed these to keep tutorials and old info somwaht relevant… at the same time as you can see by the book I just wrote in a simple jab to the surface of this subject there is likely 0 point and everyone should really come up with their own instance placement system that works for their project without relying on Epic… (matter-of-factedly if you make a .usf to do the grass right you save so much on performance with the same tris count that you can then do crazy things such as 3b tris meshes even with-out Nanite existing)…
Anyway. Hope this explains some stuff you or others may not have known or realized…
I’d go with much better, but not fantastic. Performance on the GPU is near-instantaneous spawning of the grasses themselves. It matches what you get with landscape-grass as in the meshes are just-there at the beginning of runtime. Runtime performance itself seems better and less-overhead as far as I can tell.
As well, since we’re able to read RVTs, physics-layers, et-al on the GPU we effectively get the same benefits of landscape-grass in that you can use the material to drive where grass spawns. We have access to the weight of the layer so that can be used to help influence size, etc like we would in a material (meaning the alphas are not binary in this regard).
Functionally, it’s equal-to or greater than what you get with landscape-grass and since it’s centered around PCG, has capabilities to expand in feature-scope, as well as integration with other systems you might design in PCG, ala Biomes and what not that would be DOABLE w/landscape-grass + BPs, etc, but as would be centralized in PCG, likely easier and more-capable than before.
The only real-drawback that you get is the lack of physics on the gpu-spawned models, but that can be easily sidestepped with culling points to a very small radius around the player and passing-off a path to the CPU where it spawns invisible physics models for local-interaction.
It really does seem to be all-there, but you do have to build it. I’d call it a thumbs-up? I mean if you want grass/foliage/stuffs as far as the eye can see, yeah, PCG can do that, with grass, today.
You’ve paid attention to my posts over time and I’m not the best at any of this but even I can get something to the point where the above applies, ACCESSIBILITY is a thing to, so there is that as well.. 
PCG does have an option to serialize data if you wish, fyi.
Well but that is likely just index and transform of mesh. What I was talking about is actually storing the mesh itself as a simple flat file of numbers so that the load times are near instant and the calculations can happen faster.
Traditional mesh stores all vertex with multiple values. All you really need to store is a single digit per vertex if you do so sequentially the right way. Think of it as an encrypted mesh?
The gpu processes it with a function by taking in the data stream and it goes on the screen instantly with all that it requires but storage and loading wise you have maybe 1/10 of what a mesh currently requires…
The benefit comes in with stuff like grass where you have billions of instances. 1/10 of a billion is really easy to manage for a GPU… 1 billion isn’t as it clogs stuff up…
I think, in principal, this is what dehydration does for us; reduce the thing we need to keep track of to it’s literal bare-minimum components?
As far as the billions of instances, I can say i have fairly dense grass out to 1km and it’s not really costing me much in overhead. The visbuffer (obviously) is 99% of that goes up the more-grass, but managing, transforming, placing, etc is all very-quick. Compared to a few progressively-better systems from landscape-grass and onward this lets me get to 90ish+% of the way there (IMHO) to ‘the bilions’. At least far-beyond what I would have lot capable with me investing time into all the LODs, etc. As far as systems go, this lets me get up and running far-faster and to a far-greater degree vs pre-nanite/PCG.
Weird. I don’t get all of those options. Are you using something other than a Spawn Actor node in the PCG to get those options?
Yeah, I thought the foliage system was better than HISMs because of the clustering. Honestly, I’m probably just going to stick with landscape grass. The only thing that bothers me is the fact that there’s an initialization period with LSG where it takes a few seconds to load in that you don’t get if you either hand paint the foliage or use PCG. I was hoping that PCG grass would be the best of both worlds.
I am on 572 if that is different than your version?
Yea, careful with that. Landscape grass works off pre-built grass maps. I have had them get invalidated in final builds testing due to the fact I was hacking some landscape editing parts and forcing instances off via material. When you do that, they won’t rebuild because the game is not built with the editor…
That was another reason to never use landacapes again on top of the sheer perfoemance loss you get from using them in the first place…
You have PCG, you may have nanite, you definitely have RVT… I can’t in good conscience tell you that using landscape and landacape grass is a good idea. It would likely derail the project long term unless Nanite is at a point where the landscapes are out of the picture for the final scene…
Agreed. Functionally, it’s as-good or better to use the newer technologies. Yes it does mean you need to learn a few new things, but it’s not really that hard overall, and it sets you up for what the new-normal will be with using PCG.
I have a post here if you need a leg-up: Procedural Landscape Layers - #31 by Frenetic
You can……put a static mesh as foliage then change it for your desired actor
