Question 2D Rigidbody Interpolation changes Z?

Does the 2D rigidbody interpolation change the whole transform? As in: does it also interpolate the Z position?

I had some issues and it seems like this is the case. I had to force set the Z position to the last frames value in the Update().

I might be wrong, but if that's the case:
- As the 2D rigidbody doesn't have any settings for Z, wouldn't it would make more sense if it didn't interpolate Z?
- Where in the update loop is the interpolation done? If I would need to override it, where in the frame would be the best place to do this?

Maybe a bit offtopic: in the case of one wanting to write a similar interpolation(to have more control over it), does rigidbody only interpolate the transform between two fixedupdates or does it do other calculations and checks?

Thanks!

 

Thank you for the reply!
I'm probably misunderstanding, but something is moving the Z between frames.

I've attached a super simple scene (using 2021.2). You can run and see the debug messages, but if you set Rigidbody interpolation to none the debug messages stop. Strangely enough, if you turn interpolation back on again it doesn't start sending debug messages.

I'm aware one shouldn't mess directly with the transform when using physics, but I was thinking it would be safe if I "only" change the Z as it's not used for 2D physics. If that messes with 2D physics, is there another way (except using 3D physics)?

 

Got you. I do understand that it's a new vector, I'm not sure I understand what the implication of changing the Z is for the 2D physics (since x,y are copied), why does it care if the vector was changed if its intention is to have full control, meaning it would assume nothing else changes it? Is it an internal check as a fail safe in case something external changes it?

My naive understanding was that you don't want to mess with the transform because the rigidbody can move through something while there is no physics checks and it won't know where it has been in the next fixed update (hence why I thought changing Z would be fine as it's not in the 2D physics calculation).

Sorry for harping on about Z, but I'm trying to understand if it will actually give problems for Physics calculations and I need to rehaul my whole aproach or if it's just a bit hacky.

Actually missed that there was an Approximately(), that will clean up my 'float-float smaller than' comparisons. Thanks!

 

Yes, that was the point of the test, which was my initial question in the original post. So it does, in fact, interpolate/change Z. The actual package I attached has nothing to do what my project, it was done in 5min to show the problem from my initial question.

Yes, I totally get how the approach can be done, but I wanted to make sure that my current solution is an actual problem before the overhaul. It's a 2.5D top down project with verticallity. The visuals are sprites slanted up to the camera to allow for shadow casting and other nice stuff that depth allows for. The reason this is a "rehaul thing" is that, from what I imagine at the moment, the rigidbody need to keep adjusting it's velocity to keep up with characters moving up slopes etc, or it would be much lower than the actual visuals and collision, hit boxes etc.

As mentioned in initial post, everything is actually working, but I was threwn off by the fact the 2D physics interpolation made the transforms Z change. In the end I might just switch over to 3D physics as it could make sense from a world movement perspective.

Thanks again!