Is there any possibility to choose which World Partition Runtime Grid to use for specific foliage type?
So for example I have trees which I want to be drawn far, but grass to be drawn only near.
Currently the grass and trees are using the same runtime grid which were created by default - MainPartition.
I was trying to set to Procedural Foliage Volume the name of a separate grid I created - but did not helped, obviously 
So, taking a look at project settings and the parameter for how far procedural foliage are drawn in there - I guess there is nothing like what I asked at the moment, and who knows when it should be. Or will it be even.
Seems I either misunderstood the cases for which it must be used, either PCG graph will substitute it. Either anything else.
Dont know about PCG particularly, but procedural foliage can have multiple volumes set to run and populate different things.
Or the same volume set to populate based on a color map or landscape even.
In all cases, this is just pre-processing.
You want to create a script of some sort that places objects automatically in a randomized manner within a pre-defined area.
With a little patience you can probably script this in Python even on the latest engine
(Don’t know why you would, since you get 5fps, but that’s a different matter).
On the other hand - traditional “grass” from tutorials is just made using landscape + grass node. Thats entierly different alltogether than whatever the new world partion may or may not offer…
And you can probably combine both to get what you want since thet are separate things…
Thanks for your time.
I do understand I have the possibility to place objects in a randomized manner for specific area
Maybe I misunderstood something in your answer, but my question raised because of optimization problem due to huge amount of grass instances on the map, even if they are culled, even really close to my character. My map is 4k.
And the reason I was trying to find the possibility to use approach I asked is because of World Partition itself - it handles the process of loading and unload objects from the memory (grass in my example).
Generally if you put the grass into the foliage you are fine - but the landscape grass is generally better when you can use it (never since landscapes dont work right).
You need to make yor grass right for performance. There are several posts on the subject if you search the forum.
Aside from that, instance count doesnt really matter if your meshes are rifht and have the rifht tris count - and they aren’t one on top of the other distribution wise.
Can you please elaborate?
It works creating special “grass maps” which are precomputed, and it allows you to set up instance culling and a bunch of other options.
Check out the docs/and videos about it.
Just don’t go thinking it will solve anything.
As I said. Landscapes are so underperformant that you need to replace them with meshes to get anything playable - this precludes the ability to “just use the grass nodes”.
Still, all the techniques and concepts shown within that subject are applicable to instances - even if you just have to code the shader to get the same effects going yourself.
As I recall Sjoerd gave a fairly good overall overeview/fetuatures to implement anyway in his more recent and already old as dirt space to insect talk.
All of the stuff im mentioning is a pre-concept anyway.
Something that generally needs to be done in any engine and with any system to get a videogame to run on the avarage user’s pc…
Thanks a lot, I’ll try to investigate more for things you have described.
Im currently trying to do the exact same thing. I have a 8km square map with a 4km square playable area that is covered entirely by dense forest. I want the trees to always remain loaded but have the undergrowth only be loaded when its close to the player. I can’t seem to do this with world partition because it only loads the entire foliage actor in or out, not the individual foliage types, so I can’t just put my trees on a different runtime grid to my undergrowth. My load times are insane due to the millions of foliage instances on the map. My foliage is extremely performant after 3 years of constant development and there’s nothing much more I can do to get better performance out of it. My only real issue is the unacceptable load time that comes with having all the foliage loaded at once, even when everything but the trees are culled when they’re not close to the player. I have tested using landscape grass types to do my undergrowth and left my trees as procedurally generated foliage and it works perfectly with amazing performance and super quick load times even inside the editor, however I cannot use grass types as they don’t have collision or ways of interacting with them like a foliage instance static mesh does. All of my foliage needs to be interacted with in various different ways so grass types are out of the question. I am currently working on using HLODS for the trees so they remain visible in the distance while my foliage actors are loaded with world partition and it seems to be working but as chopping trees down is a major part of my game, I know I’m going to run into the issue of having my HLODS no longer accurately representing my trees as they get cut down. Does anyone know of a way to update a specific HLOD at runtime? Ideally when I chop a tree down I would want to remove its instance from the HLOD. Would be so much simpler if unreal would let you assign different runtime grids to different foliage components or treat the painted/generated foliage loading and unloading the same as they do grass types.
Hey, you know if you utilized punctuation and new lines once in a while I’d actually try to read the whole thing…
Aside from that and all the bla bla bla, have you ever considered just loading in what you need yourself?
Put placeholder single tris meshes with a collision hull down using the foliage tool.
Add a cylinder around the player that is set to not be visible in game, on a specific collision channel that only responds to the instances you placed, and obviously make sure you have overlaps and sweep on.
With that, just get a collection of the instances that are overlapped, and swap them out to the right mesh models while retaining the original random transforms used by the foliage system.
Very Similar to this - DynoFoliage: UE4 Interactive Foliage
The difference being I was swapping foliage with animated skeletal meshes.
Even with Billions of instances, the load cost of a single tris should make things bearable.
I still don’t understand why you bother at all with trying to use a bad engine and an even worse system.
If you just go back to world composition you would have no issues at all.
And in theory, you can also parse through and swap Grass meshes, but you need to create classes in C++ to read the collection data, so its a lot more involved that just using BP.
They write a lot of bs everywhere, particularly in the engine tooltips where no one revviews or approves them.
The legacy system works. It will probably keep on working and not be discontinued ever, even if it eventually should be.
Meanwhile, the "new"system hasnt had a single forum post that wasn’t a complaint about it bot working one way or another since its launch.
Do with that what you will…
Your solution would cause the same issue im already having, except worse.
My foliage instances already have “query only” collision enabled so that I can do traces to interact with my foliage when needed. The foliage components cull method handles the culling a short distance from the player, no need for manual overlaps(which would likely cause a thermonuclear meltdown given how many foliage instances I have).
Mesh complexity isn’t the problem here and I’ve tested that by replacing all my foliage meshes with a single tri each like you suggested but no noticeable benefit.
Once the map is loaded everything works great with my trees being visible at all times and my undergrowth being culled a short distance from the player. FPS is good and stable. The problem im having is the load time at the beginning of the level is several hours which is obviously no good.
I wanted to have the trees on separate runtime grids from the undergrowth so I could load the undergrowth foliage in as I needed and not all at once at the start, but that won’t work because even loading a very small number of foliage instances in causes noticeable stutter due to the way unreal engine renders foliage instances. It does the same thing even when just trying to remove a couple of dozen instances at a time.
Disabling collision on my meshes all together seems to be the fix, getting me significant cuts to load time, which is one of the big reasons why grass types have such good performance.
For the moment it seems the best option is to try find a way to have collision on my undergrowth turned off initially and turn it back on when they’re close to the player.
EDIT: The problem is definitely the collision hulls that have to be generated when the map loads. When “query only” collision is enabled it takes hours to load, when collision is disabled it takes a couple of seconds to load. Need to find a good way of dynamically enabling and disabling collision close to the player without stutter. Hope this is of help to someone
Maybe target smaller maps as the part of a whole.
I generally run 8km maps that make up a whole area of over 224km.
Over a billion foliage instances per tile.
Never had the loading take more than a second using world composition and the normal streaming…
They are static and ever present, not generared.
So what are you on about precisely?
Simply having them set to collide or not collide wouldn’t cause loading to change at all unless the loading itself is somehow testing collision to decide if to spawn the item or not.
And if that is the case you have bigger issues somewhere or an engine bug present.
Might be ue5 being a broken mess then.
All of my foliage actors are loaded at all times so I can have my trees visible from the other side of the map. All my other foliage like grass, ferns, bushes etc are culled at about 15-30 meters away from the player.
All I know is that when I run the packaged game, it takes hours to load. Unless I use world partition to load only a small number of foliage actors at a time or if disable collision on the foliage instances.
When my foliage has collision enabled, overlaps are set to “off”, collision response to all channels is set to “ignore”, collision type is set to “query only” and the static meshes for the foliage only use “simple collision”. I only need them to have query collision on so I can interact with them via raytraces etc.
But disabling collision is like a miraculous cure.
I’ll look into the potential of an engine bug with the collision testing on load like you suggested. Most of the foliage is generated by procedural foliage spawners and they do do a “collision with world” check when you generate the foliage, so maybe its bugged out and trying to generate again on load or something stupid.
Thanks for the idea.
Are you using PCG Volumes and running a PCG graph to generate your foliage, or are you using the Procedural Foliage Volume?
The Procedural Foliage Volume gets compiled out of builds, so can’t possibly be re-generating foliage in a packaged build.
Doing a quick scan through the source, it looks like the PCG Component and PCGGraph can run in a packaged build, so if you’re using those, it does seem most likely that your PCG is being re-run on startup. If you’re happy with what it’s given you in-editor, you can disconnect the generated instances from the PCG and either delete the PCG Volume or move it into a WP runtime layer that you never load.
Hey Fafhrd thanks for the help
Im using procedural foliage volumes, haven’t played around with PCG volumes yet.
Am I correct in thinking that when the foliage instance meshes are loaded, the collision hulls are also loaded, regardless of if collision is enabled or not?
It’s just very strange the night and day difference I get from load times when collision is enabled vs disabled. Especially given that my foliage has overlaps disabled and is set to ignore everything.
I did a test where I had my foliage collisions disabled by default and then after the level is loaded I enabled “query only” collision on all my instanced foliage components. The level loaded in a few seconds as I expected and then when I enabled collision again the game froze for ages like usual while the collision setting was applied.
I think it must have something to do with how slow it is to cycle through all the foliage instances when you want to change something, but I don’t know why it would take so long when the map loads because the values are already set before runtime so it shouldn’t have to do any of that.
I know adding, removing, or changing other parameters at runtime, even on a very small number of foliage instances, causes a very noticeable stutter just because of how the foliage instances are managed in unreal, so maybe it has something to do with that.
I have to remove patches of foliage in my game when the players inventory is accessed or when buildings are placed etc and I have to use material opacity to make foliage instances invisible instead of removing, transforming, or changing visibility etc because of the stutter that happens when you modify foliage instances.
Maybe there’s a clue there.
You are definitely doing something wrong.
Changing anything is near instant when done right (vheck videos from dynofoliage).
how you do it is just about the only thing that you can ve doing wrong too.
Using loops in BP, for instance, is an immidiate fail.
Directly accessing via editor the instances will also likley just crash the engine.
Any mode or modality in which the engine does something to all instances has a self contained recipy for failiure.
Afterall, to run 1ms operation on each item out of 1b would take some 300 hours.
Changing out or swapping foliage instances in a set area is instant, suffers nothing anywhere, has no runtime load except for the operation you perform - and generally even manages to pop in whatever new instance without flashing the lowest level MIP like stuff often does in unreal.
If you are placing meshes, and not BPs containing meshes, then you really never have issues with foliage runtime.
When you start placing BP instances, then you can always have issues.
Ranging from the Tick occurring on each instance which would likely get you 2fps after 1000 or so instances to any other possible thing you may be doing in the on-play graph or any other event graph.
If you have BP instances that do somerhing with collision on begin play, then thats probably the culprit…
Hey there
Im not placing BP instances, just static mesh foliage. I know loops are bad for that kind of thing, I don’t use them.
An example of when I would get stutter issues from foliage removal was when my player would access their inventory, I would need to clear the foliage in a 2 meter square area in front of the player. I would use a multiboxtrace to collect the individual foliage instances that were hit, store their instance index’s in an INT array and use the “remove instances” function(that takes an INT array as an input) to remove them.
I don’t see how using the official function that is made to remove a bunch of instances at the same time is the wrong method to be using.
The number of instances I was trying to remove was only around 75-150 as well and still always the same stutter.
Collision hulls are part of the static mesh object, so yeah, they’re loaded even if collision is disabled on the instance.
Are you using a custom FoliageInstancedStaticMeshComponent or something? Because I can’t think of a reason why the initial load in a packaged build would take more than a minute or so, even with millions of instances, unless you’re doing something non-standard in the initialization of the Instanced Foliage Actors.
When you say it loads fast with collision disabled, are you disabling collision in the FoliageInstancedStaticMesh components on the Foliage Actors, in the Static Mesh, or in the Foliage Type?
