Our level has about 150k body instances and most of them are StaticMeshActor and instances of PackedLevelActor. We found that while the player progressing through the level and the streaming level of cells are added to world, the engine spent much time to build the AABB tree. We have noticed that as the picture shown below, the AABB tree building time regions are highly overlapped with the frametime spikes thus we thought they are relevant.
[Image Removed]
We tried to use the ChaosVisualDebugger to debug the static AABB tree at a sample time, and the depth is 14.
Question 1: Does this AABB tree too complicated? If so is it caused by the scene contains too many densed body instances? And how do we optimize it?
[Image Removed]
Question 2: Does split all the static collisions into proxy meshes with spatially loaded off and set the original meshes to no collision worth trying?
Question 3: The CVar p.aabbtree.MaxProcessingTimePerSliceSeconds is kept as default 0.001s but why the AABBTreeInitialTimeSlice and AABBTreeProgressTimeSlice could be up to 50ms?
(And we are sorry a full trace file could not be provided since it might contains some sensitive information, if more information is needed please let us know)
I believe you’re on the right track in saying AABB tree work is causing the frame spikes based on the graph, but it’s hard to pinpoint without a trace file.
Before I get into your questions, there’s this discussion: [Content removed]
discussing world partition streaming performance. Notably, version 5.6 contains a lots of “streaming” related improvements if you were planning on updating to 5.6.
If not, there are some CL mentioned in the above discussion.
1.) The tree doesn’t seem too complicated, I’d imagine the spike mainly comes from adding a bunch of body instances at once when streamed in.
If possible, an optimization is when adding collision, have it spread across multiple frames.
Depending on the shape, if you’re using a complex collision, using a simpler one may help.
2.) Yes, this strategy should be worth trying due to the optimization above. Very useful if the mesh doesn’t require real time collision.
3.) The p.aabbtree.MaxProcessingTimePerSliceSeconds cvar doesn’t look to be a hard limit and it could go up to 50ms in your example if the AABB tree generation needs to do a bunch of work that can’t be sliced mid operation.
If you’d like, if we’re unable to figure out something speculatively, we could make this case a confidential one where you could provide a trace in private.
Thank you, we just read the referenced post carefully and find that we have some moving body instances and their count is probably exceeds the limit of AccelerationStructureTimeSlicingMaxQueueSizeBeforeForce which causes those full rebuilt.
After mitigate most of those moving body instances, most time the cost of building the AABB tree is now getting dropped to the time set by p.aabbtree.MaxProcessingTimePerSliceSeconds.
But we still have some spikes, while traveling over the level, and yeah it’s probably caused by some cells have numerous body instances. We will see if these getting better in 5.6 in the future and would like to try the FastGeo plugin.