|
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 am developing for iOS/Mobile. Thank you and sorry for my english :)
(comments are locked)
|
|
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.
(comments are locked)
|
|
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: 1) 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. 2) 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. I hope my info can be useful. I'll check this alternative later. Thanks for the hint.
Sep 29 '11 at 07:41 PM
aldonaletto
(comments are locked)
|
|
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).
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);
}
}
Hi, to avoid having item rotating around the level when not needed, i just used the OnBecameVisible and OnBecameInvisible functions to disable the ItemRotator script when not visible by the camera. I think it's faster and cleaner :)
Sep 29 '11 at 06:54 PM
Andrea
It's cleaner, but not necessarily faster: be aware that visible and invisible in this case mean inside and outside the view frustum. If your map is square, when the player is at any corner and looking to the center, almost all objects will be considered visible!
Sep 29 '11 at 07:35 PM
aldonaletto
Yes, i know that visibility is triggered by the frustum. My game is 2D so in my case this it's not a problem. You can try using a big sphere trigger on your main character that activate all the item that get touched or maybe divide your level with big sphere triggers that activate the item close to them when the player touch them. Trigger are very fast and super optimized and you can avoid to check the distance in 200+ objects at the same time.
Sep 29 '11 at 09:28 PM
Andrea
(comments are locked)
|
