How does rb2d.MovePosition() interact with Physics2d.Simulate()?

How does rb2d.MovePosition() interact with Physics2d.Simulate()?

Background:

I use raycasts and transform.translate for a 2D application with the following pattern:

Code (CSharp):

1.  
2. [RequireComponent(typeof(RigidBody2D))]
3. public class KinematicRigidbody2DObject
4. {
5.     private void Awake()
6.     {
7.         // I don't need world.step
8.         Physics2D.autoSimulation = false;
9.     }
10.     private void Update()
11.     {
12.         var hits = PerformRaycasts();
13.         var posDelta = Calculate(hits);
14.  
15.         transform.Translate(posDelta);
16.     }
17.     private void LateUpdate()
18.     {
19.         // run once per frame
20.         // make sure box2d sees updated body positions for raycasts
21.         Physics2D.SyncTransforms();
22.     }
23. }
24.  

But based on the following discussion,
https://forum.unity.com/threads/smooth-movement-test-application-2d-webgl.734021/

I'm trying out the following pattern:

Code (CSharp):

1.  
2. [RequireComponent(typeof(RigidBody2D))]
3. public class KinematicRigidbody2DObject
4. {
5.     private void Awake()
6.     {
7.         Physics2D.autoSimulation = false;
8.     }
9.     private void Update()
10.     {
11.         var hits = PerformRaycasts();
12.         var newPos = Calculate(hits);
13.  
14.         rb2d.MovePosition(newPos);
15.     }
16.     private void LateUpdate()
17.     {
18.         Physics2D.Simulate(Time.deltaTime);
19.     }
20. }
21.  

I didn't need a timestep in my original method, but now I need to supply a timestep in Physics2D.Simulate.

From what I understand, MovePosition sets the velocity of the rb2D to move to position over a single physics simulation step, then resets the velocity. This allows it to interact with colliders along the way rather than teleporting, which is nice to have.

But what's correct value of timestep? MovePosition sets velocity, velocity is distance over time, what time step was used? When I try Physics2D.Simulate(100), it doesn't work properly.

Thus my questions:
- What timestep should I use?
- What's the relation between MovePosition and Simulate?
- If I MovePosition and Simulate in an Update frame, is the transform immediately updated?

Also, the following passage is a little concerning:
https://docs.unity3d.com/ScriptReference/Rigidbody2D.MovePosition.html

Side question: How expensive is multiple invocations of Physics2d.SyncTransforms if there are no dirty transforms?

 

Thanks! Your post was illuminating! Actually I already understand most what's in the preface, let me summarise and clarify a few points:

I want precise control of my simulation by using raycasts and moving directly to a computed point. All I need from Box2D is raycasts, overlaps, etc. with it's shapes, I don't need to world.step the simulation, I don't use velocity, drag, etc., so I turn off autoSimulation. Then I update Unity transform directly, then make sure Box2D has an updated internal representation by using SyncTransforms (Unity -> Box2D), so that my raycasts using Box2D isn't using outdated data.

But I'm aware that it's always been recommended in documentation and various sources to work with Box2D representation directly using the rb2d. In the past, Box2D only happened during FixedUpdate. Because FixedUpdate and Update run on different frequencies, it's caused various problems for me in the past, so I've always used my previous pattern and used Update only.

But now I'm aware of Physics.Simulate, which allows me to sync manually in Update. Which means I can use MovePosition as recommended to move Box2D shapes internally, then Physics.Simulate to make sure Unity transforms are updated (Box2D -> Unity) in Update.

My original question was, within one Update frame, I use MovePosition to move directly and precisely to Point X. Now I want to use Physics.Simulate() to:

1. Perform the move, triggering any collisions/triggers along the way
2. More importantly, update Unity transform with the new position X in Box2D internal representation

What should be the argument in Simulate(timestep), since MovePosition is moved using velocity, which is distance/time.

If I understand correctly, I can use any argument for timestep after the fix e.g. Physics2D.Simulate(100) and Physics2D.Simulate(0.001) would work, and they would give the same result? This is within the context of one call to MovePosition only, to move directly to a point. I'm not interested in simulating bodies due to velocity, drag, etc.. Of course, if I were interested in simulating the movement of a body with an applied velocity over time t, I would specify Physics2D.Simulate(t) specifically.

My default Physics2D.maxTranslationSpeed is 100. From documentation, that's "maximum linear speed of a rigid-body per physics update". For the sake of argument, let's say I want to move an object from (0,0) to (10000,10000) using MovePosition + Physics2D.Simulate() in a single frame. Is each call to Physics2D.Simulate(t) a "physics update" regardless of t? In that case, does that mean that it exceeds maxTranslationSpeed? How then would I move a large distance using MovePosition?

Thanks in advance for your time and your detailed responses!

 

Yeah haha no, it's pseduocode. It's only run once per frame in a Manager object.

 

Yup, I only have moving kinematic bodies and non moving static bodies (implicitly added by colliders).

Mainly 2D top down and platformers. When I first started Unity 4 years ago I grappled endlessly with the physics system trying to get it to do precisely what I wanted. In the end I found it much easier to just move transforms directly and only use physics for raycasts and overlaps.

But the documentation and forum posts has always made it clear that moving transforms directly with rb2d is not recommended. So now that there's a "proper" way to do things, to move the physics objects directly and update the Unity transforms from the physics objects. I'm experimenting and intending to try the new pattern starting from my next mini project.

Before doing that, I want to understand and assess whats going on under the hood, what the limitations are, etc.. That's why I'm speaking in hypotheticals somewhat instead of discrete examples. And, through my experimentation, it doesn't seem that straightforward (to me) compared to my original pattern, mainly because:

1. I need to supply an additional timestep argument
2. MovePosition doesn't move to position directly, it does so via a calculated velocity, which is subject to some limits

My conclusion so far is:

Option A:

1. Use rb2d.position to set position directly, thus foregoing callbacks such as OnTrigger if it teleports through a trigger collider
   
2. Physics.simulate(t) to update Unity transform. Technically, any t will do.

Option B:

1. Use rb2d.MovePosition to move to position. This will trigger callbacks such as OnTrigger if it passes through a trigger collider. However, this cannot move exceedingly large distances due to limit of maxTranslationSpeed
   
2. Physics.simulate(t) to update Unity transform. Technically, any t will do.

Just to clarify:
If I rb2d.MovePosition from (0, 0) to (5, 0), and Physics.simulate(0.02), I would end up with an internal linear speed of 5/0.02=250 in one physics update, which exceeds the default of 100.

But if I rb2d.MovePosition from (0, 0) to (5, 0), and Physics.simulate(1), I would end up with an internal linear speed of 5/1=5 in one physics update, well below 100.

And since they both achieve the same effect, speaking purely from the perspective of performing MovePositions only, no velocities or drag, I should just Physics.simulate(float.MaxValue) to keep my linear velocity low.

 

Thanks for clarifying regarding triggers! It was an incorrect assumption of mine.

I thought "Physics2D.SyncTransform" was (Unity -> Box2D), to synchronise Box2D's internal representation with Unity's transform.
"Physics.simulate(t)" is (Box2D -> Unity), it will simulate, then update the Transform pose with the Box2D pose in the write-back phase as you alluded to above. In my example I was using rb2d.MovePosition followed by Physics.Simulate in an Update() to update the transform positions.

Because [0.0001, 1000000]

Yup, just making sure my understanding was correct that time didn't really matter in this case. I'd most likely use Time.deltaTime.

Haha, again because [0.0001, 1000000], and confirming my understanding that time didn't really matter.

THANK YOU! This is kind of what I needed. If I understand this right, setting rb2d.position in Update will update Box2D's internal representation immediately. Subsequent physics queries will have updated values. No need for sync or simulation. This is not documented in the manual nor in C# source since it just delegates to native calls.

Honestly, I feel all this technical architecture, internals, etc. should be documented somewhere in the manual. Most of the time I find myself going over various sections of the manual trying to decipher and piece together what's precisely going on under the hood so that I can design my architecture and implementation properly, otherwise it would result in unexpected or unperformant behaviour and hair pulling bugs down the road (and it has happened).

Thanks! I really enjoyed our discussion, and now have a much clearer understanding of what's happening internally!

 

Before I go on, I really want to take the time to thank you for entertaining my seemingly pointless questions, it's been really helpful to me

I was just putting out a hypothetical to understand the limits of what I can or can't do if I adopt this approach. Again, I'm not simulating so it doesn't really apply. But for the sake of info for future users:

• Just to make sure we're on the same page, I'm assuming that 1 metre = 1 unit.
• 1000000 units per physics time step is the maximum limit.
• Thus, if I simulate 0.01s, then it can move 10km, or 10000 units.
• I use PPU values to match tileset, so 128 PPU, and each sprite takes 1 unit. Not a problem.
• But I've seen recommendations to use 1 PPU for pixel art games. Old advice, awful for physics, and Unity has pixel perfect packages now, but for the sake of argument, let's say I use 1 PPU.
• If my sprites are 128x128 pixels, then each tile would occupy 128x128 units
• Moving a tile 80 tiles horizontally would mean 80 * 128 = 10240 units horizontally, which exceeds the limit if I use Physics.Simulate(0.01)

It's a contrived example, but it does highlight to me these limits exist, it can possibly happen in an unlikely scenario, and I should be aware of these limits when developing my applications, however unlikely I am to run into them.

Also, if we didn't have this conversation, I wouldn't know about how MovePosition works internally, and wouldn't have connected this method call with maxTranslationSpeed, for which the default value is 100. I would've done Physics.Simulate(0.02f) with the default limit, which is a maximum translation distance of (100 * 0.02f) = 2 units, possibly running into janky behaviour and much hair pulling trying to figure out what's wrong.

From reading the manual and documentation, I'd always connected RigidBody2D.* methods with FixedUpdate. Internally, I'd conceptualised my mental model as, the physics system is a separate subsystem which only gets called during FixedUpdate. Calling rb2d.position only caches these values somewhere, and the physics system only gets called during FixedUpdate to update it's internal representation of the new position.

My understanding was wrong, and as you clarified, the Rigidbody2D *is* the Box2D body. Calling rb2d.position updates the physics system internal representation of body positions immediately, it isn't cached and only updated during FixedUpdate.

I dont mean those methods specifically, I mean in general, the technical architecture and internals. I don't have a clear understanding of what's happening, and have to form a mental model based on the manual, scattered blog posts, multiple Unite talks, C# source, then implement and hope I've done it correctly and nothing goes wrong because my mental model was totally flawed.

I mean, alot of it still *just works*, and I think you've mentioned in another thread, you have to anticipate what devs will do, and code defensively for that, even if it's the "wrong" way of doing things. For example, I think you've always advocated that transform should *not* be modified directly with a rb2d, instead the rb2d should be manipulated with rb2d.* methods and act as a proxy for the transform. This whole thread is me trying to do it the "recommended" way, and finding out that I can just use rb2d.position + transform.translate in Update directly, against your recommendation, and filling a gap in my mental model, although I could've just fumbled my way through, and it would still have worked, short of some totally unnoticeable performance issues and maybe unexplained extremely rare bugs.

All of this is not apparent from reading the documentation. I like to have a clear mental model of what's happening during implementation to avoid issues like the above. I use libGDX in a commercial non-game context, and whatever gaps and unexplained bugs I have, I can jump directly into and read off the source. The MovePosition issue would not have occurred, cause I would have read the source code and seen that it computes velocity, uses maxTranslationSpeed, and understood precisely how it works, and understood the gotchas and limits.

I mean, I love Unity's ecosystem and tooling, but the partially closed source nature and having to piece together a clear mental model frustrates me sometimes.

NOT AT ALL! If anything, I'm honoured that a Unity staff member would spend the time to type out replies to me with so much detail.

Sorry for the long post /endrant

 

I actually thought of using MovePosition because

1. I'm using kinematic bodies, and in the manual it says "Kinematic Rigidbody 2D is designed to be repositioned explicitly via Rigidbody2D.MovePosition or Rigidbody2D.MoveRotation"
2. You mentioned in the other thread, "MovePosition needs to be superior to just setting the position because that can cause collision tunnelling because it just instantly teleports to that position."

Therefore, my conclusion was, use MovePosition if possible, which in my case is an incorrect usage due to incomplete understanding and glossing over that section in documentation. Also, I wouldn't have moved large distances normally, but was hypothesizing for the possibility that I might in the future. Knowing that this limitation exists, and that I don't really need it and can set position directly, I'd just use setPosition in my application.

I think this is one of our main differences in how I see the 2D physics system. I'm not interested in the physics simulation, practical limits on velocity, or representing realistically in metres. I just want to perform mathematical intersect and overlap tests on convex polygons in 2D space which Physics2D can do for me. I believed that the only limitation is max and min position based on size of the data type used to repesent the position (float). And I was confused with the proper way to update the position of physics shapes, using MovePosition instead of .position directly.

[edit]
I'm now using this pattern:

Code (CSharp):

1.  
2. [RequireComponent(typeof(RigidBody2D))]
3. public class KinematicRigidbody2DObject
4. {
5.     private void Awake()
6.     {
7.         Physics2D.autoSimulation = false;
8.     }
9.     private void Update()
10.     {
11.         var hits = PerformRaycasts();
12.         var newPos = Calculate(hits);
13.  
14.         rb2d.position = newPos;
15.     }
16.     private void LateUpdate()
17.     {
18.         Physics2D.Simulate(0);
19.     }
20. }