Hello, i’ve been reading that moving static colliders (without rigidbody) it’s bad… but what about triggers? In my game i have many pickable items, and these items use sphere triggers. To make these items look nicer i rotate them every frame and so, at the same time, i am rotating the triggers too. Is this a problem for performance? Or because the triggers are ignored by the physic engine it’s fine?
About the colliders. In my game for walls, fornitures and floor i use many static colliders. For performance reasons i would like to know if the engine calculate all the collider at the same time or just the ones that are visible by the camera. And i would like to know too if there is a performance loss if these static colliders intersect with each other.
I downloaded Unity Pro (trial) so that i could test things myself using the profiler and that it’s what i have discovered:
With 200 rotating items with sphere triggers on the screen:
Between having or not the Kinematic Rigidbody the performance difference on the physics side wasn’t very noticeable. But with 200 kinematic rigidbody components on my items i had a great overhead on the scripts side.
The best solution, that gave me a dramatic performance boost was (obviously) to create an empty gameobject, put in it the sphere trigger and the pickable item script and then parent the mesh with the rotating script to it. Doing so the item could continue rotating but the trigger sphere didin’t move.
Triggers are colliders, so yes- if you’re going to move them put a kinematic rigidbody on them. They are still treated as physics objects whether they’re triggers or not.
I have the same problem: about 200 pickable items with spherical triggers and rotating all over my level. I created a static boolean variable to enable or disable the rotation for all of them at once, and tested the difference. From the physics engine point of view, the extra time is zero or totally negligible. The rendering time, on the other hand, seems to be about 10% bigger when the items are rotating! (doesn’t make too much sense, for sure).
At the end, I adopted a simple cycle saver measure: if the distance from the player is above some limit (500 units, in my case), I simply disabled the renderer and stopped the rotation. This made a reasonable difference - in the worst case, the frame rate was 17 with infinite distance and 23 with a 500m limit.
I implemented this using a static Transform variable with the player transform, and in the rotating items I included a simple distance comparison.
This was added to the Control.js script (attached to the player):
static var trPlayer: Transform;
static var limitDist: float = 500;
function Start(){
trPlayer = transform;
}
And this was included in the rotating items script:
function Update(){
var dist = (Control.trPlayer.position - transform.position).magnitude;
if (dist > Control.limitDist){
renderer.enabled = false;
} else {
renderer.enabled = true;
transform.Rotate(0, 360 * Time.deltaTime, 0);
}
}
