2D vs 3D MovePosition (dynamic rigidbodies)

I am a 2D physics dev so I can only really speak with authority on the 2D side but I do know some of the history here. The above 3D physics behaviour was already in-place long before 2D physics came along. PhysX AFAIK only supports Kinematic swept pose changes (targets) i.e. MovePosition/MoveRotation. When doing this on a Dynamic body, the choice therefore was to not allow it and push a console message or just instantly change the pose (teleport). The choice made was to just set the global pose instantly. Note that a move on a 3D Dynamic body does not support interpolation as you indicated above.

For 2D which uses Box2D there is no support for this whatsoever so we had to implemement this from scratch. The implementation here didn't care if it was a Kinematic or Dynamic body-type so it's naturally supported for both so no decision on how to handle Dynamic was needed.

So why doesn't 3D now follow what 2D does? It'll probably come down to several factors including maybe nothing/little posted about this being an issue nor bug reports nor it being a priority. I did speak to a 3D physics dev before posting this and they confirmed the above.

In short, the MovePosition/MoveRotation for 3D is designed around the PhysX feature to set a target which is limited to Kinematic body-types only and doesn't require any Unity code to do so. Box2D has no support so it's entirely handled by Unity code (at least setting it up for a targetted move).

 

If you change the Transform or Rigidbody2D position/rotation then there's no interpolation until the next simulation step and this is on purpose. For instance, if a dev was to change the position by 1000m on the X axis then the body would be interpolated over that distance. We explicitly disable any running interpolation because of that. Next simulation step, it will be set-up again. This is why MovePosition/MoveRotation exist.

I'm totally confused on what you're trying to achieve here with 2D. Interpolation works perfectly fine and so does MovePosition so I'm here scratching my head.

Calling MovePosition/MoveRotation doesn't modify the Rigidbody2D at all. It simply flags the position/rotation target is required for the next simulation step. When the simulation runs, the move happens. After the simulation step the body position is at the target you specified and the Transform interpolates from the position/rotation before the last simulation step to the current position/rotation.

 

Yes, as I mentioned above, calling MovePosition on a 3D rigidbody does NOT issue a moveposition, it just sets the RB position instantly because it's not support by PhysX. This is why you can read it because it's essentially the same as just setting the RB position. Here's the internal code:

Code (CSharp):

1. void Rigidbody::MovePosition(const Vector3f& position)
2. {
3.     ABORT_INVALID_VECTOR3(position, position, rigidbody);
4.  
5.     GetPhysicsManager().SyncBatchQueries();
6.  
7.     if (GetIsKinematic())
8.     {
9.         UpdateKinematicTarget(Vec3ToPx(position));
10.         m_DisableReadBack = false;
11.     }
12.     else
13.     {
14.         m_Actor->setGlobalPose(PxTransform(Vec3ToPx(position), m_Actor->getGlobalPose().q));
15.     }
16. }
17.  

So a Dynamic body just instantly sets the global pose which again is the reason you can read it instantly after.

Yes, as I said above, changing the position directly on the RB or indirectly via the Transform resets any interpolation until the next simulation step.

In the end, it's not complicated though; In 2D, when you call MovePosition/Rotation it flags the target but does nothing. It makes no difference when you call it, the result is the same and you cannot ready the target position from the body because it's not been set yet. As I just said above, in 3D this happens for a Dynamic body because it's NOT doing a MovePosition. When the 2D simulation runs, the move happens. After the simulation step the body will be at the position so you can read it then. Interpolation is set-up when the simulation runs; it's the point at which everything starts so subsequent frame(s) interpolate. During that period and until the next simulation step, interpolation happens. If, during that time you modify the body position then interpolation is reset until the next simulation step at which point it'll start again. Also note that any issued MovePosition is cancelled if you subsequently change the position.

For the curious, here's what happens when you set the Rigidbody2D.position property:

Code (CSharp):

1. void Rigidbody2D::SetPosition(const Vector2f& position)
2. {
3.     ABORT_INVALID_VECTOR2(position, position, Rigidbody2D);
4.  
5.     // Ignore if no body is available.
6.     if (m_Body == NULL)
7.         return;
8.  
9.     // Clamp the position.
10.     const b2Vec2 clampedPosition(
11.         clamp<float>(position.x, -PHYSICS_2D_LARGE_RANGE_CLAMP, PHYSICS_2D_LARGE_RANGE_CLAMP),
12.         clamp<float>(position.y, -PHYSICS_2D_LARGE_RANGE_CLAMP, PHYSICS_2D_LARGE_RANGE_CLAMP));
13.  
14.     // Set body transform.
15.     m_Body->SetTransform(clampedPosition, m_Body->GetAngle());
16.  
17.     // Wake the body.
18.     m_Body->SetAwake(true);
19.  
20.     // Reset any linear movement state.
21.     m_RigidbodyMovementState.ResetLinearMoveState();
22.  
23.     // Reset interpolation movement state.
24.     m_RigidbodyMovementState.ResetInterpolationState();
25. }

I apologise if I've missed a vital point you were making. Lots of moving parts, tired eyes, I miss stuff.

 

Probably because how interpolation is done there; Interpolation is a function of the physics system and it's a completely different system after all.

Yes, calling it immediately before the simulation during FixedUpdate won't change interpolation for the reasons I already mentioned above and that it's only affected during the period in-between simulations. It's updated per-frame. It makes no difference if you change it and the next step is a simulation because again, that's when the interpolation is set-up. The first jittery body in the GIF shows this.

It is the same because you turn on the option and it works. To be fair, you're using a method call that's outside of it' scope i.e. MovePosition on a Dynamic body to you're expecting the 3D fallback to be the same as the 2D one but the 2D one doesn't have a fallback, it's fully supported.

But this is an oversight and not a feature. I can see where potentially being able to set a position for interpolation might come in handy but it's very edge-case and would cause a huge amount of confusion for most users.

I hear what you're saying though in that uniformity would help you here but it'd come at a cost.

 

BTW I wanted to add that whilst I'm replying to your points I wanted to ensure you understand I'm not trying to counter/push-back everything you say and ignore it. I might misunderstand some of your points but I'm always interested in discussing this stuff so feel free to continue. Until I can clearly see where 2D is doing something it shouldn't and not just another "Can 2D behaviour be the same as 3D even though it's wrong and/or not supported" then I'm unable to take action on it. I spoke to the 3D physics dev about this and they confirmed they just never got around to working on Dynamic move-position because it wasn't a priority.

Again, setting position on the body or transform should not be an interpolated event and it isn't in 2D so if it's happening in 3D then that is actually a bug.

 

Yes I mean exactly that but also the way interpolation is done in Unity code for each physics system i.e. how the previous and current body positions are stored (etc) and how its simulation step works on the Unity side. I'm just highlighting that conceptually stuff is similar but no code is shared and implementations are guided by internal needs of the underlying physics system.

I showed the code above. I think though you're referring to interpolation which has nothing to do with MovePosition directly and maybe the source of confusion or at least incorrect focus in the discussion. MovePosition/Intepolation are not a compound operation. It's not like you do a MovePosition and it sets-up some interpolation, not at all.

I'd ilke to agree but I don't know what setting you mean and specifically what you'd want to see changed in 3D. Maybe if you could focus on one specific thing. The initial discussion was about why tunnelling occured for Dynamic 3D bodies using MovePosition but the discussion drifted into Interpolation which is confusing me at least on what specifically it is that you'd like to change being as the two are not the same thing.

 

Saturday morning, got a coffee so let me try to clarify my thoughts. Actually, clarity on a Saturday morning isn't something I do well so forgive my potentially unstructured reply.

It's actually always true from the physics POV. I think you're referring to interpolation which is just Transform smoke/mirrors and whilst it might interpolate between positions, the new position is already set in the body. This means teleporting and potential for tunnelling (for Dynamic body as it just has its pose set).

I will say that though that the fact that you can set the interpolated target is a bug in 3D physics. You should never be able to do that. MovePosition is always the way its been designed.

My fear is that adding in an explicit interpolated target is going to add a lot of confusion because it'd have to be used at a specific time and users will set a position of the body which changes instantly and it will interpolate the Transform so you'll get tunnelling so it'd be a bad version of MovePosition which won't collide in the interveining space. Also, interpolation doesn't just need old/new positions; it needs to know time-wise where inbetween fixed updates it is. We cannot control when the user will call this so what do we set as the current time? It'd mean it could potentially be half-way inbetween fixed updates so it'd immediately be set half-way which would be a big jump. Yeah add some docs but experience tells me it's just another confusing thing.

Personally I don't like the above idea as it upsets my spider senses. I'd probably go for an option in 2D physics that allows you to control if interpolation is reset if an explicit position/rotation is set either directly on the Rigidbody2D or via the Transform. It could default to true (existing behaviour) but could be turned off. It'd mean you could potentially set huge position jumps and interpolation would work which would look odd but it's an option rather than a method change.

I'm always talking about 2D unless I say 3D. When you set a 3D Rigidbody position then interpolation is reset until its set-up again next simulation step; same as 2D. It's as simple as that. Again, this is for Dynamic bodies. MovePosition for 3D Dynamic Rigidbody doesn't reset the interpolation position which is a bug and just sets the position immediately. it'll interpolate to that position. This bug is useful to you though.

A Rigidbody or Rigidbody2D have a small structure associated with them. What these structures contain is different for each but in common they have a target pose (pos/rot) and a flag saying if interpolation is active or not. If Interpolation is off for the body then this structure is not used. If interpolation is on then it is used. Prior to simulating the world, this structure is set-up snapshoting the current body pose and this is used as the from pos/rot. The simulation runs and the interpolation target i.e. the new pose is stored in the structure. Then the physics callbacks occur and it returns and it's done. Then, during each frame (Update) these Rigidbody(2D) structures are iterated and any that are enabled have their Transform pose calculated with a pos Lerp and rot Slerp. The Transform is set. Multiple frames happen with this Lerp/Slerp process. Next update this all starts again.

If at any point in time a Rigidbody(2D) position/rotation is set and the body is set to Interpolate then this interpolation structure simply has its enabled flag set to false. This immediately stops interpolation of the Transform. To be clear, none of the above changes the body pose; it's all about Transforms.

You're asking about MovePosition and in 2D as you know, it's only actioned in the next simulation step. This is true for 3D too apart from the above-mentioned fallback where you do this with a Dynamic body. It doesn't support that so its fallback is to just set the position instantly and yes, it is a teleport action. It will NOT contact anything inbetween the previous and new position. It's a bug that it doesn't reset the interpolation target there which I can understand you're using as a feature but it's an oversight/bug. As I said above, for 2D we support both Kinematic & Dynamic seemlessly so both get actioned when they should i.e. during the next simulation step and both interpolate and both move through the intervening space thus no tunnelling.

It's all good. I'm happy to provide any kind of information as long as I know it's not making things more confusing and is in-fact helping.

In short, there's nothing to fix/change in 2D MovePosition as it's doing what it should do without issue. 3D MovePosition however does not support Dynamic bodies but just does a RB.pos = pos but also doesn't (bug/feature) reset interpolation so it gives you what you want. The only common solution would be to have a setting in both 2D/3D that stopped the intepolation reset (until next simulation step) when you explicitly set the RB pos/rot. This would mean you can consistently set that but I will say, doing this on a Dynamic body is BAD and introduces tunneling which you showed clearly on your first image (3D failed, 2D didn't).

 

There is no target explicitly, it's the current body position and angle so changing them naturally sets a new "target". What it won't do with the above option off is just disable interpolation.

 

I'm not sure what (when) you mean here by "before FixedUpdate" because technically there isn't anything like this. Physics only runs during FixedUpdate which is after the user callbacks and then during each Update it interpolates so I'm honestly not sure what else is going on there.

Certainly the interpolation per-frame doesn't mean it'll get to the final (current) body position. When the FixedUpdate runs in 2D, the Transform is temporarily set to the current body position (the new simulated position) in-case someone reads it after the simulation has run (for things like manual simulation etc) but in Update the Transform will be set at the first interpolated/extrapolated position.

I looked at physics and there's only a FixedUpdate, EarlyUpdate, Update callbacks. There's no pre-fixed-update callback being used here from what I can see. There's also a lot of old legacy code in 3D and some SyncTransform so it's likely what you're seeing might be by accident.

Honestly though, I am not the person to speak to regarding 3D physics, that would be @yant.

 

I understand that and I wasn't implying user callback, I'm talking about inside the engine and the 3D physics system isn't hooked into anything like that; only the ones I said and it cannot be inside the Update callback because that has no idea if the FixedUpdate is next or not (there might be several before a FixedUpdate).

But yeah, Anthony Yakovlev is the man to discuss that with. Maybe he knows.

 

Interpolation has nothing to do with it. If you set the position of a Rigidbody(2D) then it's at that position. Bringing in interpolation just makes the question confusing.

Contact pairs are generated when the simulation runs.

Interpolation interpolates the Transform, it has nothing whatsoever to do with physics, contacts or positions of bodies. It's purely a visual feature allowing per-frame updates to Transforms because the physics (by default) doesn't run per-frame.

 

I'm not implying anything; they can and always have been available to be used on Dynamic bodies.

What specifically does it say that tells you that you cannot use it?

https://docs.unity3d.com/ScriptReference/Rigidbody2D.MovePosition.html

Also, please don't necro old posts. Please create your own thread and ask your own questions there.

 

Whilst that note is techically correct, it is intended for Kinematic bodies, it does work with Dynamic bodies as long as you understand the caveats described above it. Kinematic bodies don't have a collision response as described in the above text. Besides, if it didn't work with Dynamic bodies, it would do nothing or issue a warning. A quick test would show that it works perfectly fine.

Maybe that can be changed to say that it will work with Dynamic bodies (as described above) but is primarily intended for Kinematic bodies.

If you only read that but didn't read any of the above you'd be confused and/or you didn't know that Kinematic bodies don't collide and stop moving because of collisions.