koobas.hobune.stream
Temporary disable collision, what's best performance-wise
Hi, Unity 5.5 here. If I want to prevent a collider from having collisions for a while and then starting having those again,what is better performance-wise between enable/disable collider and change layer to one without collisions?
p.s I'm ignoring activating/deactivating the gameobject as it's probably the most expansive operation.
Actually, enabling and disabling a GameObject is not a expensive operation at all. If it is just a simple collider, you can just disable and enable it again when needed, if it is a group of colliders, just disable the parent's GameObject (or their own GameObject, if grouped together in the same GameObject).
You should not assume that some operation is expensive if it is not mentioned in the Scripting API or elsewhere that it actually is. If not sure, you can always use the Profiler to test things out.
Dude, I am not assu$$anonymous$$g. Of course it's the most expansive one: I want to disable collision and deactivating a gameobject will disable any other component I have on the gameObject, which is useless overhead if the goal is just to temporary disabling collisions.
Of course? So you made some test to assume this?
It really depends from case to case what is the best thing to do.
Changing layer is not a heavy operation to do as well, but just changing layer will make the collider still be evaluated in the Physics update, what is not true when deactivating or disabling the collider
Disabling the collider, will make the physics ignore it's existence.
Disabling the GameObject, will make the entire game ignore it's existence.
Disabling the GameObject will not change everything, internally it is just a bool that "if true, we do that thing, if not, we do that other thing."
Of course, if there are scripts in the same GameObject that you do not want to be disabled, you will disable only the collider, if there would be no difference, then disabling the GameObject would not harm anyone.
I thing you just don't know how the engine works behind the scene and, ins$$anonymous$$d of accepting some advices from someone who already did some tests around, you are ignoring and making assumptions based on what you think.
if i know right, most performant way is changing "isTrigger" flag, this way, collider does not get affected by physics but remember that they still calculate some trigger events. but i mostly use this technique for disabling collisions just for a while and enable it again. Don't Quote on me about this. i am not sure if this is the best way to do this. but from my personal experiences (and profiler results) this is very performant against anything i can think of. i hope this helps.
Actually, it only disables it's collision, but the collider will still be evaluated by the physics, as it is still active, the only difference is that now it is a trigger. Also, remember that things could go very wrong if the opposite way (trying to disable a trigger by changing the isTrigger to false).
and that what we want.Actually, it only disables it's collision
remember that things could go very wrong if the opposite way (trying to disable a trigger by changing the isTrigger to false).
Yeap.
i still think this can serve better than other ways most of the time.
I have run a test.
I've put 250 GOs with boxcollider in layer L1 and the same number in layer L2. If I take 500 brand new GOs with boxcolliders as well, and I switch their layer from L1 to L2 back and forth once alternating layer each frame, I get 0.3 - 0.4 ms of computing time.
If I let those 500 GOs sit in a layer and enable/disable their collider i get from 0.55 to 0.8 ms with spikes sometimes.
If I deactivate the GOs the computing time never goes under 1.1 ms.
So, apparently, chainging layer to a "no collision" layer is the fastes way to obtain the no collision effect in unity 5.5.
Nice data, maybe put it as an answer for others see. Already converted $$anonymous$$e as a comment to clean up the page a bit.
Thanks for driving me, I will change this to a comment as I have run better tests.
Ok so some tests.
First Scenario:
250 GOs with BoxCollider in layer L1
250 GOs with BoxCollider in layer L2
500 GOs with a BoxCollider and a SphereCollider
Changing layer from L1 to L2 and back alternating each frame is the fastest with 0.45 ms of minimum and 0.7ms of maximum.
Enabling/Disabling the colliders on all 500 objects letting them sit in L1 with the other 250 has 1.4 on average when disabling and 1.6 of average when enabling.
Activating/Deactivating all 500 GOs is the slowest with almost 2 ms of average on enable.
Second Scenario:
Same setup per layer but this time one GameObject with 500 BoxColliders and SphereColliders.
Activating/deactivating it has averageof 1.5 ms when deactivating and averageof 2.1 ms when activating.
Enabling and disabling all the colliders is 1,5ms on average when enabling and 1 ms when disabling.
Changing layer is surprisingly good. It stays between 0.3 and 0.4 ms when you group all the colliders in one game object and you switch layer.
That is really surprisingly, probably for constant operations around this changing layer turns out to be the best choice. Otherwise, enabling and disabling colliders still have a better performance overall if not being done constantly, as it compensates latter during the physics cycle..
Turns out that now activating and deactivating GameObjects is heavier than before... Still not something to worry about, but still is something always good to know. Gonna take note about that!
Try running more tests on your own and let me know if you find something that might deny my datas as I'm quite interested in this subject.
