How to reduce the memory allocation for Chaos::FAABBTree

Development Platform & Builds
, ,
1

(This is a translation of a [Japanese [Content removed] by Masaki Yoshinori.)

Thank you for your continued support.

[Issue]

When profiling a certain scene in our game using MemoryInsights, I found that the memory allocation for Chaos::FAABBTree is large.

[Image Removed]

As this seems to contribute to increased memory usage, I would like to reduce this allocation as much as possible.

[Questions]

(1) I guess Chaos::FAABBTree is a structure used for physics simulation. Is this correct?

(2) Are there any ways to reduce the allocation for Chaos::FAABBTree?

For example:

a) Removing mesh collisions

b) Adjusting collision presets

c) If there are any other ways, I’d appreciate it if you could let me know.

Thank you.

2

Hi Masa, and thank you for your question.

1) Yes the AABBTree is a physics simulation structure. It is used to quickly remove as many non-colliding object pairs as possible before the more expensive steps in the physics are run. There are also 2 of these in a normal UE situation - one on the game thread which is used for scene queries, and one on the physics thread which is used for collision.

2) The general advice to reduce this memory footprint is to

  • use instancing where possible (ie ISM when you are replicating large numbers of the same asset)
  • use primitives when you can (ie spheres, cubes etc) since they are cheaper and faster (but less accurate)
  • reduce the mesh complexity (this can be run into when clients use nanite and use a really high density mesh without a good amount of simplification)
  • use hydration if this is a large world - this allows clients to avoid loading the actor at all (including the physics) unless it is needed
  • use geometry collection simplification if they are being used
    • (all stored as CVars in GeometryCollectionPhysicsProxy.cpp) - bBuildGeometryForChildrenOnPT/GT, bCreateGTParticleForChildren - these will only create the physics for the smaller ‘broken’ bodies when the object is broken, potentially saving memory
  • avoid caching overlapping leaves (this will cost scene query performance, but reduce memory)
    • (all stored as CVars in PBDRigidsEvolution.cpp) - GAccelerationStructureCacheOverlappingLeaves - great for speedup of scene queries, but can cost memory
  • removing any physics geometry which isn’t needed for physics or scene queries

I think they are the main ones - collision presets won’t make much of a difference to memory, it is mainly for runtime performance.

Please let me know if you’d like more information on the above

All the best

Geoff Stacey

Developer Relations

EPIC Games

3

Hi Geoff,

>> collision presets won’t make much of a difference to memory

What happens if the preset is set to “NoCollision”? Will physics consume memory in this case?

4

Hi Eugene,

In this case the geometry will still be loaded, just unable to collide with anything. The use case for this kind of function is more temporary, or transient - if this were to unload when all channels were disabled we’d end up getting performance hitches as it loads/unloads data.

Best

Geoff

5

(This is a translation of a Japanese post by Masaki Yoshinori.)

Thank you very much for your reply.

We’ll be considering whether we can apply your advice to the project.

Thanks.