Auto Sync Transforms

Can someone Explain to me Auto Sync Transforms ??

It seems to be turned off by default in newer unity versions, bugged my code and caused me a ton of frustration and debugging to find this out?

According to unitys docs: To avoid affecting performance, set autoSyncTransforms to false if you want to perform multiple Transform changes and queries in succession.

Is this supposed to be done manually now? if so HOW?

Probably by performing Physics.SyncTransforms() after all your transformations has been applied.
https://docs.unity3d.com/ScriptReference/Physics.SyncTransforms.html

It's not 100% neccessary to do it manually. If you don't need it - turn Auto Sync on.

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.

11 Likes

Hey @MelvMay !

I am wondering how to properly handle updating a legacy project and turning this off. A contract I am working took a project from a version prior to 2017, and is now in 2019. We need to up performance for some of the platforms we are targeting.

Thank you!

Patrick R.

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 appreciate the quick response! My question comes down to, I'd like to turn this off to increase performance, but since it is a legacy project, turning it off causing some unwanted results.

Sounds like somethings are doing the incorrect things and turning off the AutoSync is showing their true colors. I will take a look into the objects that are having issues and make sure that they are handled correctly.

Thank you again!

[quote=“MelvMay”, post:5, topic: 726328]
If you want to change the body pose then you should always use MovePosition/MoveRotation.
[/quote]
What if we’re only using Colliders without rigid bodies, how should we move those?

[quote=“AcidArrow”, post:7, topic: 726328]
What if we’re only using Colliders without rigid bodies, how should we move those?
[/quote]
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.

1 Like

[quote=“MelvMay”, post:8, topic: 726328]
I can only speak for 2D physics
[/quote]
Thank you for the reply once again, but we’ve arrived at this point before.

I want a similarly clear answer for 3d physics, I’ve been trying for years on the forums.

I even opened a ticket ( 873057 ) almost 3 years ago, with a minimal repro that shows that adding moving colliders with rigidbodies is slower than just moving colliders and asking that if it’s a bug it should be fixed, or if this is the way it works you should update the manual (which you did, BUT IT STILL SAYS THE SAME THINGS). QA says they reproduced it and then… nothing.

At this point I can only conclude that someone changed stuff in 3d physics 3-4 years ago, then left Unity and no one knows what’s going on any more.

In any case, thank you for replying, it may not be what I was looking for, but I have a pretty good understanding about how 2D Physics in Unity work at this point.

[quote=“AcidArrow”, post:9, topic: 726328]
I want a similarly clear answer for 3d physics, I’ve been trying for years on the forums.
[/quote]
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.

[quote=“AcidArrow”, post:9, topic: 726328]
At this point I can only conclude that someone changed stuff in 3d physics 3-4 years ago, then left Unity and no one knows what’s going on any more.
[/quote]
Not true at all.

[quote=“AcidArrow”, post:9, topic: 726328]
I even opened a ticket ( 873057 ) almost 3 years ago
[/quote]
I checked this case and it’s not assigned to 2D or 3D physics teams, it’s assigned to the docs team (still).

With the setting off :
I am currently in the situation where I have the player in the middle of the screen (position 0,0), and I instantiate an enemy out of screen (supplying the position in the Instantiate() method, albeit I believe that's the same as changing the transform afterward), but the physics still thinks the rigidbody is in the middle for that physics frame...thus, damaging the player once. Is this intended behaviour? @MelvMay

[quote=“ihgyug”, post:11, topic: 726328]
Is this intended behaviour?
[/quote]
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.

1 Like

[quote=“MelvMay”, post:8, topic: 726328]
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.
[/quote]

[mention|EjwAtzzDBJA3qB8R6pfQbQ==] Are we still suppose to do that in 2019.4 (LTS) (adding RigidBody2D to static colliders just to move them once in a while)? *I thought that moving static colliders does not cause performance penalty anymore. *

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.

[quote=“MelvMay”, post:14, topic: 726328]
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.
[/quote]
So, is there a performance difference when changing position of Collider2D without Rigidbody2D through transform vs Collider2D with Rigidbody2D through Rigidbody2D? (Each frame)

How big that difference is? Cost of recreating collider and re-inserting it back to the data structure?

[quote=“VergilUa”, post:15, topic: 726328]
So, is there a performance difference when changing position of Collider2D without Rigidbody2D
[/quote]
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? :wink:

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

[quote=“VergilUa”, post:15, topic: 726328]
How big that difference is?
[/quote]
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.

1 Like

[quote=“MelvMay”, post:16, topic: 726328]
As I stated above, a collider with no Rigidbody2D is created against the static ground body so changings its position requires changing its geometry so a full recreate of the collider. 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.
[/quote]
Well, there’s always a memory cost of adding extra component. Its CPU vs memory as always.
You’re right though, for something that is moved every frame its probably worth adding Rigidbody2D.

[quote=“VergilUa”, post:17, topic: 726328]
Well, there’s always a memory cost of adding extra component.
[/quote]
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.

1 Like

[quote=“MelvMay”, post:14, topic: 726328]
Instantly teleporting its position is far different than moving it through space
[/quote]

@MelvMay

I’m teleporting the gameObjects:

gameObjects.transform.localPosition = new Vector2(x, y);

I’m doing that outside any Update function, just a function that instantly moves (teleports) all cubes down.

Does that count as moving?

Do i still have to add RigidBody2D(s)?

Sorry if this became like a broken record :smile:, but i’m trying to understand everything i’m doing and note things down.

[quote=“FadiObaji”, post:19, topic: 726328]
o i still have to add RigidBody2D(s)?
[/quote]
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.

1 Like