Spikes in UpdateActorInAccelerationStruture call

Development Asset Creation
, ,
1

Hello,

We have sometimes big spikes on a single call to UpdateActorInAccelerationStruture.

Here is an example with a skeleton mesh update, where for some reason one of the bone cost is much higher than other, on a single frame only (previous/next frames are perfectly fine and constant):

[Image Removed]

This one is just for a character single capsule transform update :

[Image Removed]

I have provided a utrace for you to see if you can get anymore info.

This one is for a Dev build to you should have more info, but we can see similar on Test build either.

I know it’s a bit light and hard to deal with, so feel free to ask for more information.

I don’t feel like this is related to any locking mechanism, we have already checked this.

I have also checked if ReoptimizeTree() is called but it does not seem to be the case.

Could this be related to any ForceRebuild processing ? Is there a way to trace this ?

Additionally, I wonder if there is anything we can do to tweak our acceleration structures (AabbTree?) using provided cvars.

p.Chaos.AccelerationStructureTimeSlicingMaxQueueSizeBeforeForce ?

Thanks for helping

2

Hi Romain,

You’re right, we’ll need more data to figure this out. I’d suggest as a first point that this function has a couple of profile markers added.

If you add one in the 3 scoped blocks I’ve added

[Image Removed]

That should be enough to narrow down if there is a lock hiding somewhere, or if the operation itself is taking ages.

If you could do that and resend to me, we can go from there.

Geoff