SkinnedMeshComponent::CalcBounds is using an identity matrix as the LocalToWorld for transforming the ComponentLocation when bIncludeComponentLocationIntoBounds is enabled causing the generated bounds to be incorrect in that they can be very large as you get further away from origin. Also cached transform adds the (world space) component position again.
This has caused some performance issues with the large bounds causing VSM invalidations and extra draws in these VSM tiles it would otherwise not cover.
Hi, thanks for reporting this, and sorry for the delay in following up. I had to spend quite a bit of time digging into the bounds code to understand what was going wrong and put together a fix. I’m not sure whether the bIncludeComponentLocationIntoBounds has ever worked correctly, but certainly it’s broken at the moment, as you described.
I have a shelf that refactors USkeletalMeshComponent::CalcBounds for you to try at CL 44837682. If you can’t access that, let me know and I can provide a patch. I think that these changes should resolve the issue and also rationalise the code a bit.
Rather than immediately transforming the cached bounds into the space that is passed in (via LocalToWorld), we now compose the bounds in local/component space. Only after that bounds transform has been composed (accounting for bIncludeComponentLocationIntoBounds, cloth bounds, etc) do we transform the resulting bounds into the LocalToWorld space.
I’ve done some simple testing on this with animations that translate the mesh away from the root of the mesh component and this appears to fix both the local bounds and the world bounds. But I would advise testing these changes thoroughly before committing them. I also haven’t yet tested the same changes that I’ve made to UChaosClothComponent::CalcBounds since I need to get some better assets to work with. But that code is effectively the same as in USkeletalMeshComponent::CalcBounds.
Let me know how you get on with this.
Thanks, I fixed it in the same fashion and it seems to have resolved the issue. But if you could post the patch file I can take that fix instead so my local change doesn’t cause any merge conflicts when your fix comes in via engine updates.
Thanks for following up, that’s good news. Sure, I’ve attached a patch with the changes. I can’t guarantee that the final fix will be the same as this, since it needs to be reviewed and go through a good amount of testing. But I’ve added the issue to our JIRA tracker so you can follow the status at least - Unreal Engine Issues and Bug Tracker (UE\-313532)