So moving the gameobjects with colliders need to have rigidbodys added so they won’t be calculated as static and cause performance issues. How about gameobjects without both collider and rigidbody? How does a movement of that kind of gameobject affect to the performance? Cameras don’t have colliders and rigidbodies, and still it is not a problem to move them without them?
You’re thinking about this the wrong way around.
GameObjects don’t “move”. You just change the Transform. Renderers read the Transform and render and don’t care performance-wise what the Transform is. Physics on the other hand has to sync-up Transform changes to its internal spatial database of physics objects and is much more complex. Now the question of should you modify the Transform when using physics objects (Colliders or Rigidbodies) becomes a simple answer of: No. Never ever modify the Transform when using physics components. Ever.
When you add a Rigidbody(2D) you’re asking for it to control the Transform on your behalf and it’s its primary role. It performs simulation then writes to the Rigidbody(2D) pose back to the Transform. If you need to change the physics position then go through the Rigidbody(2D) itself by modifying its position/rotation (using MovePosition/MoveRotation) or changing its velocity. Worst case changing its position/rotation using its properties. But never modify the Transform.
So with the above said, you know you’re doing something wrong when you modify a Transform that has a physics component on it (or on any child).
3 Likes
That requirement is no longer valid since Unity 2017 at least (I think it was lifted in Unity 5 IIRC). You may move your GameObjects with colliders (and without Rigidbodies) without incurring in performance issues.
@MelvMay is this correct?
I remember reading that I should never move colliders without using rigidbody due to the performance issues and then I went to my game where I do just that (Unity 2019.2) and saw no difference or performance issues.
So I’m a bit confused.
That’s 3D and AFAIK the performance was greatly improved but moving a static collider is still something you should avoid. I mean, it’s implicitly static so don’t move it.
Anytime you modify the transform that has to be picked up later prior to the simulation running and has to be processed.
For 2D, it’s certainly an absolutely terrible idea but more simply, don’t modify the Transform ever.
As far as I know that doesn’t involve a significant penalty per-se in 3D. Specific scenarios (i.e. moving objects multiple times between simulation steps) may be optimized with Physics.autoSyncTransforms and Physics.SyncTransforms().
Yes, that’s mentioned in the Collider section of the manual several times under “Static Colliders”. However, since Unity 5 / PhysX 3 that doesn’t apply to 3D anymore:
https://unity3d.com/unity/whats-new/unity-5.0
The reason of why it’s no longer an issue is explained further in the blog post:
https://blogs.unity3d.com/2014/07/08/high-performance-physics-in-unity-5/
2 Likes
Well… sorry to intervene here, and I’m aware that you’re doing your best to help. But I think this is incorrect and may cause further confusion in the users. There are totally legit reasons to modify the Transform of physics components, as long as the consequences are understood.
Modifying the Transform of a physic object means “teleporting” it to a new location and many times you need to do exactly that: teleport it without any physics-wise consideration. For example: setting the initial position of an object, moving the player back to a respawn position, reconfigure the position of a collider in a rigidbody. I could describe more complex examples actually used in production projects.
What is wrong and will likely cause issues is modifying the Transform continuously in non-kinematic Rigidbodies. In this case both the physics and the user will be trying to modify the Transform values, which will surely cause unexpected effects.
Thanks for the info.
Is this true for 2D colliders as well? Does 2D physics use PhysX at all?
No, what I said above is accurate. You are not supposed to modify the Transform when using physics components on GameObjects.
2D uses Box2D.
This is inaccurate. There are many situations where you can modify the Transform of an object with a Rigidbody component and a collider component with no issues. You can change the position and rotation on the Transform of an object, and the Rigidbody will understand and behave normally. Doesn’t take much testing to see.
I have a game where I reposition objects using their transform in order to sync up the scene view with class info, absolutely zero problems whatsoever. Behaves perfectly, no issues.
I wrote the 2D physics integration, just saying.
There’s a huge difference between the bad behaviour a dev can do via scripts that we have to support (such as syncing from Transform changes) and how it’s supposed to be done which is via the Rigidbody2D API. Saying “it works” is just highlighting that we have to and do jump through hoops to support that kind of behaviour. It isn’t a confirmation of how it’s supposed to work. Modifying the Transform breaks all sorts of 2D physics behaviour such as interpolation, terrible performance with 2D Static bodies, Rigidbody2D not at the Transform position until a simulation step causing all transforms to be sync’d, the list goes on.
If “it works” is your criteria then that’s fine too however doing it correctly works with better performance that scales with no side-effects is quite another.
2 Likes
Gotta side with @MelvMay - “it works” does not mean “it’s right”, but I’m a bit confused by the documentation for IsKinematic:
“If isKinematic is enabled, Forces, collisions or joints will not affect the rigidbody anymore. The rigidbody will be under full control of animation or script control by changing transform.position”
So is the documentation saying it’s “right” to move an object with a rigidbody by modifying its transform directly if IsKinematic is true? or should we still be going through the rigidbody to update position and rotation in this case?
i.e. you have a target GameObject that you want to move back-and-forth with a script > it has colliders on it to detect collisions from projectiles > the movement of the target GameObject does not take any physics into account > in this case, would you add a kinematic rigidbody to the target GameObject?
Note that you’re referring to the 3D physics documentation BTW. For 2D that is an obsolete property too, it uses Rigidbody2D.bodyType to explicitly select the body type.
The thing is, it’s easy to point at one API reference and say it’s confusing but each of those pages doesn’t constitute a self-contained manual or tutorial. The wrong word in any of those can lead to “confusion”. You cannot figure out what’s in a house by looking through a keyhole. 
There’s also the API doc for 3D for MovePosition which is what you’re supposed to use for Kinematic 3D bodies. Physics has to support uses doing all sorts of things that are less than optimal such as constantly modifying the Transform, particularly the scale but there’s a big difference between what works and what is best to use. Personally, I’d say you’re correct, it really shouldn’t state for 3D to use a position but then again, lots and lots of devs want to use the Transform and no matter what is said, will continue to do so.
The simple rule though for 2D is: If it moves in physics, move the Rigidbody(2D) by its API. Everything else asked is just a scenario that comes back to this. Smoother visual motion via the Transform comes from using Rigidbody2D interpolation. Or for both smoother visual and physical motion with no interpolation, you can run the 2D physics simulation per-frame too if your project is suited to it.
1 Like