Custom Interpolation for rigidbody2d.position modification instead of MovePosition?

Since moving a rigidbody2d by directly modifying rigidbody2d.position causes it and its collider to move instantly and resets the interpolated position for that frame until the next simulation step, are there any resources for setting up a custom interpolation that allows for direct modification of rigidbody2d.position without interfering with interpolation?

Because I need to move rigidbody2d.position multiple times during FixedUpdate in order to raycast against the newly updated collider positions to determine some customized physics behavior involving those raycast results. But this breaks rigidbody interpolation, so I need to come up with an alternative to still achieve visual smoothness.

https://www.kinematicsoup.com/news/2016/8/9/rrypp5tkubynjwxhxjzd42s3o034o8

This is the only resource I've found so far, but I was wondering if there were any others.

 

I do use kinematic bodies and use raycasts to determine collisions. Particular edge cases require me to limit movement to a fixed distance to allow for fixed length raycasts to handle those collision checks. So if something is moving faster than that fixed distance, the movement needs to be broken down into multiple steps shorter than that fixed distance and then run the collision raycasts after each step or it risks tunneling past the rays' origins. But this requires collider and position to update instantly in FixedUpdate so the subsequent steps' raycasts can work properly. It can't wait for the sync in the internal physics step, so MovePosition can't be used.

I think essentially it would be like how I believe Unreal allows for physics substepping (never used it so I don't know for sure, but the concept I think is the same).

 

Oh I missed your idea of returning the rigidbody2D to the original position and then using MovePosition for the adjusted movement. That actually seems so simple and works, thanks!

And that would be cool if Unity added that new SimulationMode2D option.

 

@MelvMay
Though actually while I have you, I was curious if you had any insight on this even though it's not technically related to 2D Physics.

I made this thread because I'm currently not using rigidbodies but am looking to switch to it for the various benefits including the built-in interpolation. I'm currently using transform.position for movement and Physics2D.SyncTransforms() after each of my 'steps' in FixedUpdate so the colliders sync with the transform changes so the subsequent collision raycasts can properly detect the newly positioned colliders of each step. (And for visual interpolation I have a custom transform interpolation script that lerps transform positions in the Updates between fixedupdates)

But one issue that prevents me from switching to using rigidbody2d.position is that I'm currently using a set of child transforms in order to use their positions as the start positions and end positions of

Physics2D.Linecast(start, end)

since child transforms automatically move/rotate/scale properly in relation to the parent object that is moved by transform.position += . The problem is if I switch to instead use rigidbody2d.position +=, am I right to believe that that is no longer possible unless I continue to still move the transforms alongside it? As illustrated here:




Given the number of positions I need to track for my linecasts' start and end positions, manually calculating each new start and end position for each linecast for each substep the object gets moved in FixedUpdate has in my experience been significantly worse performance-wise compared to being able to simply use the child transforms (as shown above) since they automatically internally update any position/rotation changes from the parent transform they inherit from.

The closest I came to in terms of matching that performance was by using the transform's transformation matrix myself, but even that was worse than whatever happens internally to child transforms. But since using rigidbody2d.position doesn't also instantly move the transform, the transform's transformation matrix would be unusable anyway to my understanding.

This is the only idea I have for that. Where after every rigidbody2d.position move I'd run a script like this's UpdateSensors() to update those sensor positions

Code (CSharp):

1. public class SensorTest : MonoBehaviour
2. {
3.     private Vector3 _center = new Vector3(0, 0);
4.     public Vector3 Center { get; private set; }
5.  
6.     private Vector3 _bottomLeft = new Vector3(-1, -1);
7.     public Vector3 BottomLeft { get; private set; }
8.     private Vector3 _bottomRight = new Vector3(1, -1);
9.     public Vector3 BottomRight { get; private set; }
10.  
11.  
12.     private Vector3 _topLeft = new Vector3(-1, 1);
13.     public Vector3 TopLeft { get; private set; }
14.     private Vector3 _topRight = new Vector3(1, 1);
15.     public Vector3 TopRight { get; private set; }
16.  
17.     public void UpdateSensors(Rigidbody2D rb)
18.     {
19.         Quaternion rotation = Quaternion.Euler(0, 0, rb.rotation);
20.         Vector3 position = rb.position;
21.  
22.         Matrix4x4 matrix = Matrix4x4.TRS(position, rotation, Vector3.one); //not sure how I'd properly do scale with a rigidbody2d instead of a transform
23.         Center = matrix.MultiplyPoint3x4(_center);
24.         BottomLeft = matrix.MultiplyPoint3x4(_bottomLeft);
25.         BottomRight = matrix.MultiplyPoint3x4(_bottomRight);
26.         TopLeft = matrix.MultiplyPoint3x4(_topLeft);
27.         TopRight = matrix.MultiplyPoint3x4(_topRight);
28.     }
29. }

Sorry if that was hard to follow, but do you have any ideas for that?


****
Actually now after doing tests, using rigidbody + updating the raycast sensor positions with the

Matrix4x4.TRS

using each new

rigidbody.position

and

Quaternion.Euler(0, 0, rigidbody.rotation)

now seems to be much faster unless I set up the test wrong.

I was originally doing the test with 500 instantiations of either the rigidbody.position script or transform.position script, and had them all spawn on the same position while I moved around. And the rigidbody version hung from the profiler showing Physics2D.Simulate>Physics2D.FindNewContacts despite all my collisions in the collision matrix being disabled which I thought was odd. But after staggering them on spawn so they're not on top of each other, the rigidbody version is much faster. (Though I'm still not sure why them overlapping would call Physics2D.FindNewContacts if they're not supposed to be able to detect one another anyway with the each checkbox in the collision matrix being disabled)

 

Thanks for the detailed response. And yeah I originally was thinking purely about transforms which in my head wasn't Physics2D related but ended up being tied directly to it. And the reason I felt I was forced to use transform.position and Physics2D.SyncTransforms() was ultimately because both convenience and a lack of understanding that made rigidbodies (wrongly) appear impossible to use.

Specifically being

1. Previously being unaware rigidbody.position instantly moved colliders without waiting for internal physics step like MovePosition does

2. Previously believing

rigidbody.position +=

irreparably broke rb interpolation before realizing I could move it back to the original position and then use MovePosition and still get the interpolation.

3. Depending entirely on the transform.position of child gameobjects for key functions since they update instantly alongside

transform.position +=

of the parent, but not with

rigidbody.position +=

.

So an overall lack of knowledge made me believe I was trapped into using transform.position and Physics2D.SyncTransforms(). I can't know for sure if I can still use it this new way until I completely switch my system over to using rigidbody, but I think it should work.

But to give a bit more reason why I needed the instant movement in FixedUpdate is because for my Sonic-like 2D controller, and this could be a lack of knowledge trapping me again, I didn't see how else I could achieve something like the picture below. With my current knowledge, my only options were to either subdivide the movement + raycast collisions myself in FixedUpdate, or achieve the same thing by setting the fixed timestep to an unrealistically tiny number to subdivide the hyper-fast movement into steps small enough to work. Which I assume isn't a good idea, so I chose the former.



This movement speed is probably 30x faster than any object will ever move, but there are other reasons why I felt I needed to do it this way. This one was just the simplest way to explain it. Though it's also nice that it works properly if I ever want to move this fast. But the non-linear nature of the movement made me believe traditional Physics2D and just using the internal physics step wouldn't work, but again that could be coming entirely from a lack of knowledge.

But now that I have an idea of how it could still work with rigidbody.position, I will try to switch the system over.

 

To determine collisions, I do employ kinematic bodies and raycasts. To allow for fixed length raycasts to handle certain collision tests, I have to restrict movement in some edge circumstances to a fixed distance. The movement must be divided into steps that are individually less than the fixed distance if something is travelling faster than that; otherwise, it runs the risk of tunneling past the sources of the collision raycasts. But for the next steps' raycasts to function properly, collider and position must update quickly in FixedUpdate. MovePosition cannot be utilized because it cannot wait for the internal physics step to sync.

It would effectively work the same way, in my opinion, that Unreal supports physics.

 

@MelvMay

I took a break from this but came back to it and realized I'm still having an issue with updating my 'sensor' positions when using rigidbody.position to move my 2D Controller instead of transform.position, and I can't figure out a performant way to handle it.

It's technically a hyperoptimization that I don't really need to do, I just am so curious how child transform positions and rotations get updated so cheaply.


When I was using transform.position += to move my controller, I was using 10 empty child gameobjects (seen above) attached to my controller simply for the fact that their transform positions and rotations update automatically and seemingly for no cost whenever I moved the the controller transform with transform.position += or transform.rotation =. (I don't know how they get updated under the hood).

I used these empty child transform positions for the start and end positions of my collision sensors (linecasts) since the positions got reliably updated instantly and automatically with any transform movement I needed to do in FixedUpdate (like adjusting the transform position whenever a collision linecast hit something, which would update the positions for subsequent linecast positions that same frame).

However, if I were to instead use rigidbody2D.position += to move my controller, I lose access to this because the transform doesn't move until the internal physics update, so I can't use child transforms for the 'sensor' positions anymore.

I thought I could get away with doing this

Code (CSharp):

1. public class SensorTest : MonoBehaviour
2. {
3.     private Vector3 _bottomLeft = new Vector3(-1, -1);
4.     public Vector3 BottomLeft { get; private set; }
5.     private Vector3 _bottomRight = new Vector3(1, -1);
6.     public Vector3 BottomRight { get; private set; }
7.     private Vector3 _topLeft = new Vector3(-1, 1);
8.     public Vector3 TopLeft { get; private set; }
9.     private Vector3 _topRight = new Vector3(1, 1);
10.     public Vector3 TopRight { get; private set; }
11.     //etc
12.     public void UpdateSensors(Rigidbody2D rb)
13.     {
14.         Quaternion rotation = Quaternion.Euler(0, 0, rb.rotation);
15.         Vector3 position = rb.position;
16.         Matrix4x4 matrix = Matrix4x4.TRS(position, rotation, Vector3.one);
17.  
18.         BottomLeft = matrix.MultiplyPoint3x4(_bottomLeft);
19.         BottomRight = matrix.MultiplyPoint3x4(_bottomRight);
20.         TopLeft = matrix.MultiplyPoint3x4(_topLeft);
21.         TopRight = matrix.MultiplyPoint3x4(_topRight);
22.         //etc
23.     }
24. }

But I realized I would need to call UpdateSensors() every time I move rigidbody2D.position += in order to perfectly mirror the way transform.position += updates its child transform positions/rotations under the hood.

I tested it and it seems to be much worse performance-wise than the empty transforms.

So my question is, is it possible to replicate the fast way child transform positions and rotations seem to get updated when their parent moves except with hardcoded Vector3s instead that get transformed by the rigidbody position and rotation?