(This is a translation of a [Japanese [Content removed] by Nakamura.)
Currently, I am working on optimizing memory usage for my project, and I have observed that the memory usage of Physics is different greatly depending on the Level. So I am trying to identify the cause of this.
In Levels with higher memory usage, the Physics memory on Unreal Insights reaches 887 MB, while in Levels with lower memory usage, it stays about 73 MB.
Since the numbers of “Count” differ by orders of magnitude, I guess that the number of StaticMeshes and Actors placed in the Levels might be the cause. However, I have no idea specifically for what each item on Unreal Insights uses the memory , which makes it difficult for me to pinpoint the cause.
Would it be possible for you to help me understand why such items as ChaosAcceleration and ChaosGeometry are using so much memory?
Thank you.
Try “chaosgeometrymemory” on the console on a Development Build. You’ll get a breakdown of simplified/trimesh geometry memory usage.
Typical cause for this are meshes you intended to use with Nanite, but forgot to check the box, and using complex collisions.
[mention removed]
(This is a translation of a Japanese post by Nakamura.)
Thank you very much for your reply.
Thanks to your advice, I was able to reduce memory usage greatly by adjusting the vertex counts of the meshes and fallback meshes that were set to "Use Complex as Simple.
At the same time, however, even after the adjustment, the memory used by “Physics” remains quite high.
I have also confirmed that, apart from the adjustment made to the StaticMeshes, I can reduce the memory usage by converting the StaticMeshActors in the Level into InstancedStaticMeshes using the batch of MergeActor.
I have not yet converted the StaticMeshActors to InstancedStaticMeshes after the vertex count adjustment, because I am wondering if this method is the best optimization when ChaosAccelaration and ChaosGeometry occupy a great amount of memory. Would it be possible for you to share your opinion with me?
Thank you.
Well, thank you very much @Ernesto! I opened this to respond to Masa and you have already answered!
[Content removed] what I’d follow up with as some extra advice is that we have the Unreal Insights profiler available - which comes with a memory allocation profiler as well. This can help track down any unclear memory allocations as well.
https://dev.epicgames.com/documentation/en\-us/unreal\-engine/memory\-insights\-in\-unreal\-engine
Best
Geoff Stacey
Developer Relations
EPIC Games
That is a decent shout Ernesto. Out of interest do you use CVD as part of your workflow?
Much appreciated Ernesto!
I’ll get this ticket closed off now in that case.
Best
Geoff
[mention removed]
>Typical cause for this are meshes you intended to use with Nanite, but forgot to check the box, and using complex collisions.
Could you please let me know what “but forgot to check the box, and using complex collisions.” means?
Thanks
Hi.
If you imported a high poly count model that you intend to use with Nanite enabled, but you forgot to enable Nanite on it, the collision trimesh will be generated from that high poly count mesh (if you have your collisions set for that mesh as “Use Complex and Simple” or use “Complex as Simple”). When you enable Nanite on a mesh, the collision trimesh is instead generated from the fallback mesh, which generally has a much lower poly count.
“chaosgeometrymemory” should give you a list of loaded meshes sorted from low to high collision memory usage, and show you if they’re using simplified collision or collision trimeshes. You can run this command on the Editor as well.
Ernesto.
[mention removed]
Thank you very much for your detailed follow-up and advice. I really apreciate it.
There are different approaches depending on what your game needs.
Any meshes that don’t need collision precision should have a simplified geometry generated for them, and set to “Use Simple as Complex”. This will save you a lot of memory, as the simplified geometry is generally pretty cheap.
For meshes where you do need collision precision (Complex as Simple) , but the fallback mesh has more triangles than you require for collision, you might want to consider creating a simplified mesh that’s precise enough for your collision needs, and use the Custom Collision Mesh option to set it as the mesh to be used as trimesh for collision.
Instructions about these processes can be found here: https://dev.epicgames.com/documentation/en\-us/unreal\-engine/setting\-up\-collisions\-with\-static\-meshes\-in\-unreal\-engine
Hope this helps!
Ernesto.
[mention removed]
(This is a translation of a Japanese post by Nakamura.)
The main cause of the issue has been identified. The collisions for the Static Meshes are set to “Simple”, but the issue is caused by the large number of Instanced Static Meshes that are generated by PCG.
Each Actor has hundreds to thousands of instances created. So I would like to report that simply setting the collision preset of the PCG Actor to “NoCollision” resulted in memory savings on the order of hundreds of MB.
I am still trying to optimize this, but I would like to share the list of what I have verified so far for your reference.
(1) Setting the collision preset of Actors having thousands of instances created by PCG to “NoCollision”
→ This was the most effective, requiring the least man-hour.
(2) Reduction or simplification of the collision meshes for the meshes that use Complex Collision
→ This required handling each Static Mesh with high memory consumption one by one. So this is time-consuming, but it seems to be very effective.
(3) Combining Static Mesh Actors into Instanced Static Meshes
→ From the point of view of Physics memory consumption, this does not have so much effect. However, I have confirmed a reduction in UObject memory usage.
→ I guess that this is partly because the maps of the game we are developing are not so large.
→ I have high hopes for “Packed Level Actor” and “FastGeo Plugin”.
Please close this thread.
Thanks.
Hello.
I’m glad you were finally able to track it down. I wanted to point out that switching the meshes to “No Collision” response won’t automatically remove the collision information, because tentatively you could change the collision response at runtime. In order to make the engine completely remove collision information from the mesh at cook time, check the “Never needs cooked collision data” box on the static mesh editor. Once you cook your project, the collision data won’t be cooked and included with the game at all.
No worries, Geoff. We run into this in almost every project these days. With the advent of Nanite, it’s fairly easy to forget the check the box and one of the most common side effects is the collision memory shooting up.
I think I suggested a while ago to advertise more prominently the ‘chaosgeometrymemory’ console command, but also we’ve created some Content Browser custom filters like:
((CollisionComplexity = UseComplexAsSimple | CollisionComplexity = UseSimpleAndComplex) & triangles > 20000) | PhysicsSize > 131072which really help tracking down problematic meshes that can cause this.
Best,
Ernesto.
Hi Geoff.
Personally I think I’ve only used it once or twice to track down some physics interaction that wasn’t clear. But the lack of usage is more a testament to Chaos physics working generally well than anything else. Things like the discussion here are more asset-setup type of problems, and besides some of the solutions discussed so far to diagnose the problem, our teams generally also set up Data Validators to catch these issues early.