koobas.hobune.stream
Can i Move/Rotate triggers without Rigidbodies? And other collider questions.
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 :)
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 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.
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);
}
}
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 :)
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!
Since you're developing for mobile devices, some compromises may help making this more effective: use the far clipping plane at the shortest distance possible, so objects beyond it will not rotate (due to your code) nor be rendered (only objects inside the frustum are drawn).
Yes, i know that visibility is triggered by the frustum. $$anonymous$$y 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.
