Memory issues when spawning a large number of foliage instances through PCG

We are using a system similar to PCG Biome Core v2 to spawn a large number of foliage instances (~2 million) in the world in our multiplayer game (all in-editor and on demand, no runtime). When generated purely in the editor, we observed huge memory spikes on the server, way more than what we’d normally expect for that number of points. We are therefore exploring solutions to avoid loading so many instances at once. Following are our questions:

  1. What is the intended way to handle spawning a large number of instances through PCG?
  2. Are there settings in the PCG graph that can ensure components are not loaded on the server?
  3. If using runtime generation, what is the correct way to ensure everything is happening on the client, and what are some steps we can take to ensure spawning on the GPU is as efficient as possible?
  4. Keeping in mind that we are not using streaming, if we were to handle all spawning in the editor, how can we ensure all the instances don’t get loaded in at once? What would you advise as the best rendering component to use (in combination with PCG) to allow loading foliage in tiles close to the player - would it be the AFoliageActor and associated ISMCs or is there another rendering component we can use?
  5. Does any point data being tracked by a PCG component make it into the cooked build? If so, how can we ensure that it doesn’t?
    [Attachment Removed]

Hi Amritha,

Sorry for the delay in answering your questions.

Q1. Intended way to spawn large number of instances through PCG?

Spawning in the editor is a one-time thing, so while generation time is probably faster if it’s only on the smallest number of components possible, it can & will cause performance issues for multiple reasons - rendering will likely be slower, physics will take a long time to spawn etc.

Normally we partition the generation on appropriately sized-cells. It’s not only necessary for streaming, but in general might also behave better.

It would also allow you to do HLODs, which if I recall correctly don’t require streaming.

Q2. Settings to ensure components aren’t loaded on the server

If it’s the PCG component per se, then you can mark it editor only (either on the component or on the PCG graph) which will remove it in cooked builds (server and client too.)

It does not remove the rendering components from the server however.

I would expect the cost here isn’t really rendering but physics- maybe make sure you have collisions on just for the things that require collisions & simulation.

Q3. Ensuring things are executed on the client when doing runtime generation.

There’s a few things to do this:

  • there is a Get Execution Context node that can tell you if it’s a client or server (useful in some cases).
  • Runtime generation on gpu (w/ no collision) normally doesn’t run on servers (as far as I know - might be worth checking)
  • Actors that are spawned from PCG and require server authority should be marked as ‘replicated’ - then these will only be spawned by the server.

Q4. Without using streaming, how to ensure not all instances are loaded at once?

Internally, the foliage uses HISMs if I remember correctly, and will assumedly be more or less as costly if they have collisions.

You might want to look into HLODs for a proper setup, and do critical collision discipline.

Q5. Does any point data being tracked by a PCG component make it into the cooked build? If so, how can we ensure that it doesn’t?

I would assume you mean PCG data assets, either hardcoded (in the graph) or softcoded (through references or parameters on the instances). They’ll be gathered as normal dependencies unless the PCG component is editor-only - as far as I know.

Again, in your case, if you’re not doing runtime generation, you can ensure to make your graphs editor-only and that should have direct benefits.

Hope this helps,

Cheers,

Julien

[Attachment Removed]

Hi Julien,

Thanks for your response! It seems like setting the PCG graph to be editor-only was the key to solving our problem. I will be in touch if we have additional questions!

Thanks,

Amritha

[Attachment Removed]