Auto Sync Transforms

Prior to this option, every time you modified a transform it auto-sync'd those changes to all respective physics objects immediately (prior to returning from your transform change). If you're making multiple changes to transforms then this can be expensive. It was actually quite common to see projects where a single transform set the position and rotation separately, even the scale. Each one of these caused physics updates.

With the option on, this legacy behaviour occurs for backwards compatibility. With it off however, the transforms are only sync'd prior to the simulation being run.

You also have the option to sync them manually whenever you like however that should be done with caution as it can affect performance.

Internally, manually syncing transforms is exactly what happens automatically prior to simulation being run. Whenever you change a transform (in any way) then it is flagged as changed. Internally, components can register their interest in such changes. We can then ask what transforms have changed for certain component types and process them. This is effectively what the manual sync-transforms is.

The above applies to both 2D & 3D physics. Note that this change was required for other non-physics reasons internally and all other systems use it. The difference in physics is that we had very specific behaviour when a transform changed whereas most other systems didn't. Due to this we had to ensure that we kept backwards compatiblity but also had a way to ensure we could meet the requirements of the deferred transform sync.

Hope that helps to clarify it.

 

I'm not sure I follow the question, you can simply turn it off. If the project involves setting a Transform then immediately querying physics then it's a bad thing to do anyway. Additionally you should consider that setting the Transform on a GameObject with physics components (something I make a forum post on about several times a week) is something you should never ever do as the Rigidbody2D is in charge of the Transform; it's what it's there for.

If the project doesn't do the above then just turn-off AutoSyncTransforms as it's checking for transform changes which you are not doing (or shouldn't).

If you want to change the body pose then you should always use MovePosition/MoveRotation. If you absolutely must change the position of a body immediately (not sure why you'd ever need to do this really) then set the body.position property.

 

I can only speak for 2D physics but when you "move" something in physics you should only ever do this by manipulating a Rigidbody(2D). If you're doing anything via a Transform then you're doing it wrong and perfomance will suffer. Of course we are forced to implement and catch this situation and will update stuff but it's still bad in every way.

So with that known, it should be clear that by modifying the Transform on a GameObject that only has a Collider is bad and is in-fact static. If it's supposed to move under your control then you should use Kinematic. If it never moves then Static. If it responds to forces etc then it's Dynamic. A Collider without a Rigidbody(2D) is Static.

If you absolutely must have them Static and must move them then add a Rigidbody2D and set the body-type to Static. If you don't add a Rigidbody2D then colliders are added to the hidden static ground-body that lives at the world-origin. In physics, bodies move, not colliders. By doing what you suggest, the collider needs to be recalculated and work done to move it. With a Rigidbody2D on the same GameObject then you can set the Rigidbody2D.position/rotation properties to get it to move.

 

I've seen this question asked and answered many times on the forums for 3D physics by @yant. Hopefully this mention here will get you the info you require.

Not true at all.

I checked this case and it's not assigned to 2D or 3D physics teams, it's assigned to the docs team (still).

 

Probably best to create your own thread and post some code. Sync transforms has nothing whatsoever to do with a rigidbody being positioned where it's created. It'll always do that.

 

This hasn't changed since day#1 and won't change. A Collider2D with no Rigidbody2D means you want it implicitly static meaning you're saying it isn't going to move and it'll be created on the hidden static ground body that lives at the world origin. Of course we know that devs will still move it (and even use the Transform which is bad) so we have to deal with it. Because 2D colliders live in the space of the body, such a colliders geometry is in world-space so changing its position means it has to be recreated completely because we can't move the ground-body.

Quite simply, anything in 2D physics that moves means moving the body so move the body but again, don't modify the transform ever.

Also there's a huge interpretation of what "moving" means. Instantly teleporting its position is far different than moving it through space. Anything that moves should be Kinematic so use that no matter how often it moves. If for some other reason you must have static then add a Rigidbody2D and set it to static body-type. There's no difference then not adding a Rigidbody2D component apart from the fact that you can directly control its position as you have a component to work with.

 

As I stated above, a collider with no Rigidbody2D is created against the static ground body so changing its position requires changing its geometry so a full recreate of the collider is required but this wouldn't be a problem because not adding a Rigidbody2D means you're stating it won't ever move right?

If there's a Rigidbody2D then you're only changing the Rigidbody2D position/rotation and the collider isn't touched.

Impossible to give you a figure. Less work is more. Just add a Rigidbody2D, there's no penalty so I'm not even sure I follow why it's even an issue.

 

Sure for heavyweight components but for a Rigidbody2D set to static it's practically nothing but yes, it's not zero although I've seen solutions like add a Rigidbody2D, move it then remove it which is beyond silly. There's zero extra CPU overhead when it's created and up and running apart from there being another b2Body in Box2D so unless you're creating hundreds of thousands it's not even an issue. Box2D pretty much ignores static bodies and only looks at them when there's a Dynamic body interacting with them.

I think it's worth reiterating for those who look at this thead and TLDR: The only things that move in 2D physics are bodies not colliders so if it moves, you should be moving a body. Anything else is "faked" and has a FAR higher cost such as "moving" a collider.

 

TBH I've explained it above twice so I just don't know how to explain it any other way. You don't have to do anything in any specific way. Some ways consume more CPU time because they're just us supporting actions you really shouldn't be doing.

 

That blog post is obviously referring to 3D physics which is the physx offering. I'm clearly referring to the 2D physics which is the Box2D offering. The two engines are different offerings. What I said is correct.