Moving gameobjects without colliders and rigidbodies

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).

 

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.

 

No, what I said above is accurate. You are not supposed to modify the Transform when using physics components on GameObjects.

2D uses Box2D.

 

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.

 

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.