UPCGStaticMeshSpawnerDataProvider::PrepareForExecute_GameThread() hitches

We are using runtime PCG graph to spawn large amounts of static meshes (foliage). This is required so we can dynamically change what is going to be spawned. We are happy with the GPU-enabled static mesh spawner PCG element GPU performance in general. The GPU footprint is within our requirements. Most of the heavy logic is pre-cached and the runtime kernel just selects from prepared set of meshes and sends the data to the spawner in this trivial graph:

[Image Removed]

The only issue we currently have with this approach is the CPU side cost, namely spikes in the UPCGStaticMeshSpawnerDataProvider::PrepareForExecute_GameThread() function call.

[Image Removed]

The code creates a PISM component for every mesh spawned by the GPU spawner, unfortunately leading to several milliseconds long hitches on the game thread.

I was wondering, can this be moved out of the critical path (i.e. GameThread)? Is there a way how we can directly spawn fast-geo instances instead of “classical” mesh components? Please note that we are using fast-geo plugin for most of our other geometry. Also please note that some of those instances require physics state.

Hi! Thanks for pointing me to the componentless cvar in the documentation. We’ve enabled the plugin and the cvar, it mostly fixed the performance issues (the spikes were greatly reduced). That’s good news. We’ve encountered strange behavior when trying to play with cvars like FastGeo.Show, it looks like PCG can create FastGeo in the editor (outside of PIE), but the rest of the system is not prepared for that.

We will look into the two layer grid (small for CPU/collisions, larger for GPU) soon. I will get back to you when we learn anything new.

Thanks again.