Rigid body vs transform

Hi guys,

I have read a few things about this issue and naturally the difference between rigidbody and transform scripting surrounds the use of physics.

I have a question about the way I'm implementing movement in my 2d game. So far I have been altering the transform.position directly since I have no need for gravity or physics beyond some rudimentary collision boxes used for raycasts and triggers only. I am now concerned about whether this is the correct approach and whether I should be using the attached rigidbody2d instead. Could someone offer any advice, as well as the pros and cons of moving to rigidbody movement?

Furthermore, the 2d Roguelike project used a rigid body seemingly just because it used collision detection. I wonder then if it is inappropriate to use transform position or translate when using any sort of collision detection?

Thanks!

 

Rigibody is the physics device, whereas the transform is the objects physical location (including rotation, size).

Honestly, if you don't need physics, just use transform. I've used it before in projects and have had no issues with it. It means that you're not wasting compute time on calculating physics, which is always a good thing. Actually, if you just add a box-collider (I think you can still do this, haven't really touched unity 5 much as I've taken a while out) then you'd pretty much hit the same functionality, minus the compute for the rigidbody.

Imo in your situation its probably just best to drop it if you don't need physics calculations etc.

 

There's nothing wrong in moving things using transform (I could bet that rigidbodies does it under the hood as well).

It's just a matter to use something ready or do your own. If you need just collision checking, there's no need to use rigibodies, if you are happy with triggers and raycasts. On the other hand, if you need to collision processing (like avoiding entities cross a 2D wall, doors, etc) then I would go for 2D rigibodies.

 

Moving objects by their transform can cause glitches in the physics simulation, by which I mean that objects could be moved inside other objects or skip right over them etc. and therefore the physics simulation can be described as 'not realistic'

However, for the purposes of a 2D platform game, 'realistic' physics is unlikely to be a major issue, and I have had good results making 2D character controllers that mix using Rigidbody physics for the collision detection with manually moving the character via methods such as Rigidbody2D.MovePosition, Transform.Translate and directly setting Rigidbody2D.velocity.

I find these methods work much better (and are easier to code) than either using AddForce or not using Rigidbodies and the built in collision system detection at all, and instead writing my own collision functions.

Since the latest patch release I think Rigidbody2D.MovePosition is probably the best to use now as, according to the patch notes, it now doesn't cancel out the effect of gravity when you use it. (I haven't tested this works yet though).

 

Even though you do not use physics for your character and you move your character with transform with a collider attached, you still have to attach the rigidbody component to it since if you don't, Unity will see your character as a static collider instead of a dynamic collider, which causes Unity to have to update the caches every frame for the volume of the static collider because it assumes static colliders do not move. If you want further explanation, the tutorial of Roll-a-Ball explains it quite well.

 

This. Moving static colliders can be expensive. If it has a collider, and it moves, put a Rigidbody on it. It's counter intuitive, but this is more performant. This was improved in 5, but as I understand it is still relevant.

If you are going to move it around via its transform then simply make the Rigidbody kinematic.

 

https://docs.unity3d.com/ScriptReference/Rigidbody-position.html

 

In my case, the object behaves horribly when I use rigidbody in OnPhotonSerializeView. But it looks ok when using transform. I have no idea why.