koobas.hobune.stream
Is a collider that enables/disables considered stationary?
I was watching a video on optimization from Unite 2012. One of the lecturers stated that if a collider ever moves it should have a rigid body attached (since every time a collider without a rigidbody moves a bunch of collision geometry needs to be recalculated).
My question is: If the collider is stationary (i.e. never moves) but you enable/disable it. Does it have the same impact as moving a collider? Should I add a rigidbody and set kinematic to true?
In the scene in question it's a box collider that prevents items from dropping away. At some point it is disabled, the items drop away (get destroyed when off screen) and then it's re-enabled.
Unfortunately the physics chapter of the Unity manual doesn't make this any clearer:
Static Colliders A Static Collider is a GameObject that has a Collider but not a Rigidbody. Static Colliders are used for level geometry which always stays at the same place and never moves around. You can add a $$anonymous$$esh Collider to your already existing graphical meshes (even better use the Import Settings Generate Colliders check box), or you can use one of the other Collider types.
You should never move a Static Collider on a frame by frame basis. $$anonymous$$oving Static Colliders will cause an internal recomputation in PhysX that is quite expensive and which will result in a big drop in performance. On top of that the behaviour of waking up other Rigidbodies based on a Static Collider is undefined, and moving Static Colliders will not apply friction to Rigidbodies that touch it. Ins$$anonymous$$d, Colliders that move should always be $$anonymous$$inematic Rigidbodies.
What I'm doing is basically level geometry (it stays in the same position for its life) it just gets disabled periodically.
Bump. Still interested in the answer to this.
Should a collider that is statically positioned yet gets enabled/disabled have a rigidbody applied? When I enable/disable is it doing a recomputation (same as moving an object)?
Still interested in a definitive answer to this question.
$$anonymous$$y question has no achieved a "Famous Question" badge, but still no answer.
Anyone have any input?
I really do not like the unity manual guides. I am not very good with studying, and I usually find that their answers/examples only slightly point me in the right direction. There is always the possibility that the answers are outdated for older verions of Unity as well. I am not sure how often they update?
But anyways I believe the problems you are describing only occur when an object is moved with physics. So just enabling and disabling the object, I believe it should be fine as a static object.
This is however an interesting thing I need to consider for my own projects. Is it really that bad to move an object with a collider without a Rigidbody? I did not realize this could cause performance issues thanks for posting this question.
Anyone know more details about this? Seems counter-intuitive that a more simple object would be more performance heavy. Maybe this only applies to AddForce for the PhysX? If it applies to transform.position to even without a rigidbody... then well, I am confused.
And can't you check the tickbox to determine whether an object is static? It seems they are saying it's an automatic function?
It is really rare when the Unity manual actually helps me. I find that solving problems based on their examples/answers is usually like banging my head into a wall repeatedly until I happen to hallucinate the right solution.
They should really have more in depth examples and guides for those of us who aren't "pros", or "geniuses".
It almost seems like they want you to have trouble learning this stuff, or they are VERY bad teachers.
I first heard about it in this video on performance optimization from Unite 2012. I can't be bothered to rewatch it right now, but I don't remember them specifying moving using physics, just moving it at all. The manual seems to agree (if it doesn't stay stationary.. meaning the same transform to me) then it should have a rigidbody (and of course is kinematic to true).
I'm mainly wondering in my case if I'm getting overhead by enabling/disabling or I'm not and it's best kept that way do to the overhead of a rigidbody (which isn't all that bad in this case as it's just one simple collider).
While not a huge deal in my current usage these are things I like to know. Of course I'm the type of person that gets overly concerned with what my OR$$anonymous$$ is doing so I can avoid extra round trips to the DB.
Yeah, I wish I had the answer too. Hopefully someone will come along to clarify this for us.
I also think I read somewhere that you should always use AddForce with Rigidbodies never transform. So maybe it is ok to use transform without Rigidbodies? Or do all movements require a rigidbody?
I have found that moving Rigidbodies with transform works perfectly as far as I can tell...
So once again there guides have been very unhelpful to me. Please someone clarify this?
Anyone? Still curious about this, I cannot seem to ever find the time to fully read through all the documentation as it generally just leaves me with more questions like this.
I'm still interested too. The documentation is ambiguous. If all else fails I can go to the optimization talk at Unite 2013 Vancouver (if they have a talk on that) and ask the question there. I'd kinda like to know before then though.
I would so no, reason being is as follows:
Each collider that is created static gets copied into the physx engine, this then combines and optimises into a single optimised mass collider routine, so basically they would not be one collider but get grouped so that near calculations can be made to work out which colliders should be tested.
If you enable or disable any of these, unity only tells physx to ignore collisions (in the same way as how layers work and ignore colliders work) but the grouping remains.
However if you create a new one or move a static one, the whole lot gets recalculated...which is really slow.
Ultimately any questions on whats faster, what will affect performance...just write a quite test and check the performance.
If I had pro I would definitely profile it. Easy enough.
Someone from Unity Tech should be able to give a definitive answer though. At this point it's just conjecture. Yeah a new collider or moving a static will definitely be poor performance, but this may be an edge case since enabling/disabling isn't the same thing as moving or creating a new one.
You can use Time.realtimeSinceStartup to measure time functions take for example stick this in your update and check the debug log:
var time=Time.realtimeSinceStartup;
for(int i=0;i<10000;i++)
{
this.TestCollider.enabled=!this.TestCollider.enabled;
}
Debug.Log("Time taken="+(Time.realtimeSinceStartup-time));
$$anonymous$$y results show:
0.06993103 seconds (69ms)
On my mac book air. So if you're toggling 10000, then start to worry!
You won't get an answer from Unity Tech, as it's not really a Unity question, it's a Physx question, and so would really be something to be asked at Physx.
I'll try it on mobile see if there's any notable difference between static and dynamic.
