Best Practices For Large Number of Colliders on a Vehicle

I have a vehicle with a lot of interior objects which the bad guys need to be able to shoot, hence I've given them colliders (no rigidbodies since they are parented to a GO with a single rigidbody) but this is causing occasional drastic performance hits (all the way down to 3fps instead of the usual 40 - 50 fps) whenever the vehicle is near enough colliders in the landscape. The odd thing is that the following tutorial actually advises people to use a large number of child colliders in place of a single mesh collider, based on the reasoning that a mesh collider is a lot slower than large numbers of primitive colliders: https://unity3d.com/learn/tutorials/topics/physics/physics-best-practices

Since most of the child objects on my vehicle don't need to collide with anything in the landscape - they only need to be hit by bullets - I thought maybe I could place most of them under a separate parent GO and then use a script to position that GO at the main vehicle GO's position every LateUpdate, so that at least the interior colliders aren't being used for rigidbody physics, which I assume should speed things up considerably. Alternately, I could drastically scale down the colliders by only approximating interior objects, or write my own code to check bullets against simple geometric zones (boxes and spheres) whenever the bullet gets inside the vehicle. Or maybe there's a better method? Any idea what the most effective method is?

 

How many colliders we're talking?

Did you profile the game running in the editor or an actual build? The editor and a build often have significantly different performance and memory allocation characteristics. Performance issues that occur in the editor, might no issue in a build. Profile a build on the target platform to be sure.

Spoiler

Sounds like it might be a good idea to introduce a "Bullet" physics layer and configure it to not collide with the landscape/default layer (or any other layer).
See "Layers and Collision Matrix": https://unity3d.com/learn/tutorials/topics/physics/physics-best-practices

 

I would probably do something like have a single simple colliider that encapsulates all of your other colliders that need to trigger a bullet hit. When you instantiate your vehicle create a list of Bounds based on your detail colliders then destroy the detail colliders.

Now when a bullet hit's your single simple collider, just project a ray from the bullet forward and iterate over your bounds. Update the bounds position, and do a square magnitude check and a Bounds.IntersectRay call. square magnitude in case it hits multiple so you can see which one it should have hit first. Or you can use that to have some type of penetration logic also.

Untested but should perform significantly better.

 

This is what I'd do first. If those colliders are only there for being shot at I'd just have them ignores for any other logic.

Surely the physics system already has a bounding volume hierarchy internally to do this kind of stuff for itself? That's not to say you couldn't get better performance with case-specific assumptions in place, but I think I'd only go this route if the simple stuff didn't get me enough performance.

 

It absolutely does this.

 

Use collision layers.

setup one "big collider" for situation where you're checking vehicle collision against against environment, and a separate set of colliders on a different layer for the interior. You don't really need to check for collision between the road and the steering wheel, right?

So, utilize layers.

 

I tried setting the interior colliders to a layer that doesn't collide with anything, but that didn't prevent the slowdown.
Would it work to make these colliders triggers, so they still are detected by the raycast used for bullets but do not collide with anything?

 

Did you profile the game?

 

The Profiler showed that the main problem was the script that applies force to the rigidbody in FixedUpdate, and it turns out that it was caused by directly changing the rotation rather than using AddTorque. Changing the rotation had caused the script's FixedUpdate function to jump to up to 95% CPU usage, but only when near groups of colliders and with several dozen internal colliders on the vehicle. Not sure why it would have such an enormous effect.