Is Adding Rigidbody To Every Moving Collidable Object A Good Practice?

Hello everyone,

I read an article on Unity tutorials about Best Physics Practices: http://unity3d.com/learn/tutorials/modules/intermediate/physics/physics-best-practices

At the end of the article, there is a part called Rigidbody. Author uses this statement: "When moving a game object, it’s imperative to add a RigidBody to it."

What I understand from it is that if any GameObject on the scene with a collider is supposed to change its position during the gameplay, then it should have a Rigidbody as well. I always thought more rigidbody components would cause more hardwork on the engine as it has properties like Drag and Gravity. But is it still a better choice than not having a rigidbody on those objects?

Please share what you know about this subject with me (and the community).

Thank you!

 

Yes, this is good practice.

It's actually one of the things that trips me up even to this day, because I forget to think about it - Anything that may move is better off having a kinematic rigidbody (or dynamic if it needs physics simulation, of course). There is a hidden cost in PhysX to moving static objects - it causes the physics engine to rebuild a bunch of data.

Unity 5 will alleviate this issue (in fact I think it eliminates it, but I'm not sure - someone from UT would need to confirm that), due to the PhysX upgrade currently planned for that release.

TL;DR: The only colliders that should be static (no Rigidbody component) should be things that absolutely do not move, like static pieces of a level. Everything else should have a kinematic or dynamic rigidbody.

 

Thanks for the quick reply. I'm really surprised that I haven't heard this practice before. From now on, I will be more careful with non-static colliders

 

It is THE only practice.

also, never move a non-convex mesh collider (rigidbody or not). another big no no.

 

Yep. If it moves, it should have a Rigidbody.

If it has a Rigidbody and you don't want it to respond to physics then it should be marked as kinematic and ignoring gravity.

The docs do cover this but they're not nearly as clear about it as they could be. Rigidbody is treated as if it's primary purpose is to add physics behaviour to colliders but that's a bit misleading because that's actually only a part of what it does. As a result people leave them off because it's counter intuitive that "adding physics" to something they're not applying forces to actually makes it go faster.

 

The physics docs used to be quite good.

I think they got superceeded with ultra crud versions

 

It does feel odd/wrong/unintuitive to put rigidbodies on UI elements (when they use box colliders and raycasting to check for taps/clicks, and are moved around at least for transitions)...

 

And never scale mesh colliders, either. (Especially not lots of them, every frame...)

 

How about 2D? Does Box2D play by the same rules?

 

Probably a stupid question, but does this apply to games that don't use any colliders or physics at all?

 

In the strictest of logic... if you "add a rigidbody to every collidable object", and your game has no collidable objects... you're following it by default aren't you?

 

If your moving an object it should have a rigid body attached. Don't resize a convex mesh each frame it seems to kill the frame rate on mobile. Oh another thing is to make sure the scale of your objects match to the real world equivalent or you will find the simulation acts weird and people will complain. Infact everything will get screwed up from fog to whatever, it's one thing that the asset store doesn't really do is have a standard scale for everything.

Ever notice you buy a particle effect, it's too big, it's too small etc. you got resize, rescale etc. we should have one standard

 

Only if it has a collider. If there's no collider it's not required.

 

Hey, I take up the topic to expose a case: what happen in the case you have already a GameObject with a Rigibody and then 2 more GameObject with Colliders each one but they are child of the first GameObject. Do they need using Rigibody too or in this case as the parent have already a Rigibody is not necessary.

 

Does this go for character armature too which may have colliders attached?

 

That's how cars are rigged in racing games in Unity; so, although not 100% sure, I think a Rigidbody in parent is sufficient.

 

Anyone know if this still applies in Unity 2019+ ? ie. If it moves and has a collider, it should have a rigidbody.

 

Pretty much yeah. If a collider doesn't have a rigidbody, pretty much all it's good for is receiving raycasts.

 

Excellent, thank you @StarManta .

 

@StarManta In terms of performance, I'm no longer sure about this. This video has planted a seed of doubt in my mind (see 7:23):

 

You absolutely should add a rigibody for moving colliders that will have some form of interpolation or if doing any kind of work involving it within FixedUpdate.

Basically if you're teleporting chunks of level around you don't need to add rigidbody. But if you are doing a lot of work or using platforms etc, you should or it won't be smooth. As for performance, test it

 

Do you know how it is right now in the end ?
I just cannot trust this unity people anymore.

 

@koirat I haven't had firsthand experience about this in quite some time so I can't share definitive metrics but I believe what the video says, so no Rigidbody for moving colliders unless it's needed