Physics.SyncTransforms() questions

So I have a few questions regarding this feature:

1. When autoSync is turned on, does the system actually force everything to sync positions/rotations every time, or does it have some kind of optimized way of only moving the rigidbodies that are "dirty"? If so, how expensive is the "dirty" check (in other words; how great are the potential performance gains of doing it manually if we weren't moving rigidbodies by using transforms anyway?)
2. A sync is only needed when a transform with an attached Rigidbody/Collider was moved directly; not when a Rigidbody was moved directly with .position, .MovePosition, .velocity, or through physics forces/impacts. Correct?
3. Right now, a MovePosition() is only really applied after the FixedUpdate phase. Does calling SyncTransforms apply it instantly or affects it in any way?
4. If moving a Rigidbody with rigidbody.position or MovePosition, and autoSync is turned off, does it automatically do all the sync work for child Rigidbodies/Colliders, or do we have to call SyncTransforms manually to sync children?
5. Will turning off autoSync cause any sort of unexpected behaviour with rigidbody interpolation? (does interpolation rely on changing the transform's position internally and not the rigidbody's?)

Basically, with all this, I am trying to figure out if I really need more than one single sync per fixedUpdate. I already make sure all of my rigidbodies are moved through rigidbody methods, and none of my vanilla colliders are moved at all (if they are moved, I'll make them kinematic rigidbodies). So from what I understand, one sync would be enough (?)

thanks!

 

Just for clarification.
The compatibility mode that is ran by default. Is that when autoSync is false?. So if you have autoSync to false, it syncs the transforms before a raycast. But if you have it to true, it flushes everytime you move something?

To me, it sounds like there is 3 modes in the document.
Compat: Flush before FixedUpdate & before Raycast.
Off: Flush before FixedUpdate
On: Flush When Something moves.

 

Thanks!
This is a super useful feature for Multiplayer Lag Compensation where we have to roll back time to do Raycasts etc and then roll it back agian all within a frame.

Great job. And thanks for the clarification

 

Not sure if I've hit a bug or just don't understand the feature. I couldn't find any information really on does this relate to objects moved via forces.

2017.3 latest patch update, I have a physics object that is only affected by AddForceAtPosition, and it behaves completely different with auto sync disabled. The code is actually the open source buoyancy script, I disabled auto sync and the first thing that went wrong is all my ships sunk about 500 units then shot up in the sky. Isolated it into a fresh scene with just a cube, rigidbody,and script same result. So obviously forces come into play somehow.

After that, I added Physics.SyncTransforms() calls to before/after every position read, and before/after the force calls. No effect.

 

Heads up! I found a potential issue when autoSync is turned off - setting transform.localScale while using Rigidbody2D.MovePosition in the same frame causes the object to freeze. This suggests that its not only transform.position / transform.rotation which need manual syncing, but editing the transform component at all overrides physics changes.

Setting transform.localScale in Update, and then using MovePosition in FixedUpdate works - however breaks interpolation and smooth movement.

Is this consistent with your findings?

 

I've just done some testing on my project, which does do some updating of transforms that have colliders on them (due to 2d hinge joints not behaving wonderfully- when i push on a collider on a hinged rigidbody it behaves like a spring and can be separated from it's anchor and pushed across the world, which is nonsense, none of the hinges in my home do that)

anyway, here are the results on my project, maybe they will help someone:


with the fancy new manual sync transforms implemented like this:

Physics2D.autoSyncTransforms = false;
Physics2D.autoSimulation = false;
...
//update physics once per-render-frame via Update:
Physics2D.SyncTransforms();
Physics2D.Simulate(physicsDeltaTime);

PC: 2017.3.1f1, .net 3.5, mono, 2 minute soak, 122fps average.
PC: 2017.3.1f1 .net 4.6, mono, 2 minute soak, 118fps average
PC: 2017.3.1f1, .net 4.6, mono, 2 minute soak, 131fps average

Android 2017.3.1f1, .net 3.5, il2cpp, 28 minute soak, 14fps average
Android 2017.3.1f1 .net 4.6, il2cpp, 28 minute soak, 15fps average


old way:

Physics2D.autoSimulation = false;
...
//update once per-render-frame via Update:
Physics2D.Simulate(physicsDeltaTime);

PC: 2017.1.1f1, .net 3.5, mono, 2 minute soak, 172 fps average
PC: 2017.1.1f1, .net 4.6, mono, 2 minute soak, 120 fps average
PC: 2017.1.1f1, .net 4.6, mono, 2 minute soak, 115 fps average

Android 2017.1.1f1, .net 3.5, il2cpp, 28 minute soak, 20fps average
Android 2017.1.1f1, .net 4.6, il2cpp, 28 minute soak, 19fps average


Android took a significant performance hit with 2017.3.1f1. back to 2017.1.1f1 for us.

 

Why duplicate tests?

and:

Typo?

Also I don't see why changing net, IL2CPP etc has any bearing on the unity engine code which is completely separate. This is a seriously flawed set of tests.

 

* our SyncTransforms

because those ones were quick, to get an idea of the variance of data. tests were run in multiple configurations to benchmark those differences as well. not labcoat, but back of envelope.

to be fair, unity's profiler indicates that we may be spending almost 50% less time syncing transforms in some nasty situations with the new method on android. but whateverthehellallelse is new in 3.1f1 makes our android project go much slower.

 

@hippocoder @yant
Just to be really clear,
"When set to false, synchronization only occurs prior to the physics simulation step during the Fixed Update."
If autosimulation is set to false, do we need to call Physics2D.SyncTransforms(); like @herb_nice did in his post or not?

autoSyncTransforms just change the sync method but did not disable sync, but it's done during FixedUpdate, and autosimulation change the way the physics works, FixedUpdate still called but not for Physics.

 

I'm seeing character controller being pushed by kinematic rigid colliders on navagents through the terrain collider with autosync off
Why is this and how to remedy?

 

where can i get the pdf doc? the previous link isn't working any more.
thanks

 

thanks for your reply. No, just want to learn more about this subject. If there is any summary about this, it will help a lot.

 

For my understanding, SyncTransforms is needed only when moving rigidbody without the method of rigidbody, for example move the Transform directly. But I'm not sure, hope there will be a summary about this too, help a lot.

​

 

Does setting Rigidbody.position/rotation immediately updates the physics engine state? Or we are obligated to call SyncTransforms?

In my case, I want to test with Physics.OverlapBox that moved objects do not overlap. If they overlap then revert position change. And I'm trying to do this in one frame, without spreading logic across several FixedUpdates

 

For future whose missed that part

 

Thanks for clarifying this!

Does this mean that every Physics.XXX() methods like Raycast, BoxCast, SphereOverlap etc will use new values right after Rigidbody.position/Rigidbody.rotation are set by a script?

What about changing Collider parameters? For example, changing center and radius of a SphereCollider