- Home /
Unity 5: RigidBody or No RigidBody?
I have slow moving gameObjects that are moved exclusively with code. They have colldiers and are never affected by physics in anyway.
Up until now, it was clear that I needed to have a rigidbody2d (mine is a 2d game) attached, flagged IsKiematic, for optimal performance because of the way the physics engined worked internally.
I am aware that Unity 5 has optimized the engine so that there is no longer the performance penalty that was seen prior when moving a collider without a rigidbody.
Still, since I'm obsessed with squeezing out every last possible ounce of performance, especially for mobile, can I get the last word about whether or not there is still a performance gain to be had, no matter how small, with having a rigidbody as opposed to not? Or the other way around?
I've search the Internets but have gotten conflicting thoughts, most of them very vague and probably just guesses.
Thanks, Manny
Unity 5 includes a profiler, even with the personal edition; this sounds like an ideal opportunity to learn to use it by conducting performance tests yourself with and without rigid body components. Please do share your results.
I have observed that when moving a collider by assigning its transform.position, then the collider gets removed and recreated, causing a fair amount of overhead (still in unity 5 beta17). Is that the performance problem you mean?
Answer by MelvMay · Mar 13, 2015 at 04:37 PM
This applies to 3D physics (PhysX), not 2D physics (Box2D). It's quite simple; static colliders are called static because they are designed to not move so never ever do so. All static colliders are added (behind the scenes) to a single static body. This means we don't have a static body for each static collider which, for obvious reasons, is far better however it also means that this single static 'ground body' lives at the world origin thus when you 'resposition' a static collider, it has to be recreated at the new position you specify. Technically the colliders geometry is transformed to the position but the single static body stays at the world origin. This isn't normally a problem because nobody should ever move (during gametime) a static collider. So never move a static collider. You can trust me on this because I wrote the physics code that does it. :)I am aware that Unity 5 has optimized the engine so that there is no longer the performance penalty that was seen prior when moving a collider without a rigidbody.
Is this still the case?
I have some sprite-men that move around in a sidescroller-like game. Each of them has a box collider (trigger, to catch clicks) and a sphere collider (non-trigger, for the head), but no rigidbody. I move the men using transform.position = ??? in Update(). I have about 20 on-screen at the same time, and I don't seem to experience any lags or inconsistencies. I successfully have rocks (with rigidbodies) falling onto their heads, and bouncing off. None of the prefabs are set to be Static, if that makes any difference. How does one set a collider to be static or not?
Is it still advisable, to only move my sprite-men in FixedUpdate? And is it still advisable to attach a rigidboy to them, and set it to Is$$anonymous$$inematic? It seems like a lot of overhead, just to be able to move a bunch of colliders.
I read up on it, and apparently the answer is "Yes."
At least for 2D, if it moves, it should have a rigidbody and be moved in FixedUpdate using either:
physics-methods e.g. ApplyForce()
rigidbody.$$anonymous$$ovePosition(), which interpolates kinematic objects to the given position, but teleports non-kinematic rigidbodies instantly.
rigidbody.position = someVector, which teleports both kinematic and non-kinematic rigidbodies instantly.