Search Issue Tracker
By Design
Votes
1
Found in
2017.3.0f3
Issue ID
994647
Regression
No
Physics.SyncColliderTransform is extremely slow when a Gameobject with lots of colliders and a Rigidbody is changing scale
A parent object has 10 000 cubes with colliders. Its scale is being changed. If the parent object has a Rigidbody component, Physics.SyncColliderTransform is taking close to 1000ms. If the parent has no rigidbody component, Physics.SyncColliderTransform is taking less than 10ms
To reproduce:
1. Open user's attached project
2. Open scene "SuncTransformsPerfTest" and play it
3. Observe profiler
Expected result: Gameobject with lots of colliders does not significantly slow down the editor whether it has Rigidbody collider or not
Actual result: Gameobject with lots of colliders significantly slows down the editor only if it has Rigidbody component
Reproduced with: 2017.2.1p3, 2017.3.0p4, 2018.1.0b5
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Build fails when building a project containing an 18+ dimension array with IL2CPP
- [Android][Sentis] Human poses are not detected when using the BlazePose model
- Sprite Editor Outline Tool Overlay is not displayed when no Sprite is selected
- “No method with RuntimeInitializeOnLoadMethod attribute” warning from ReadmeEditor.cs is thrown after installing Project Auditor Rules
- Projection matrix is altered when using RasterCommandBuffer.ClearRenderTarget on DX12 and Metal
Resolution Note (2019.2.X):
When you have a root with N static colliders that translates into N PhysX static actors each having the corresponding shape.
When N colliders are parented to a Rigidbody that's a whole different story, it corresponds to one dynamic (kinematic in this case) actor that has N shapes.
Having a lot of shapes is not recommended in PhysX unfortunately, they even advise against that in their docs.