Extrapolated physics interpolation mode

[Wunder_Wulfe]

Extrapolated physics is a very nifty way of doing physics based on values such as Ping where instead of interpolating between values you already have, you try to predict ahead slightly both on server and on client based on how long it took that physics information to get there. This means if someone was going 10 u/s west and was at <0, 0, 0>, if it took 0.2s for that information to go from one client to the other, the client (and server in total) should have the position adjusted to <-2, 0, 0> to compensate. This means that what you see on each machine is roughly syncing ahead with velocity and rotvelocity. One of the challenges with doing this manually is when there are many constraints to evaluate, and moving things manually might make them react poorly. Here are the advantages of this form of physics networking:

• Syncs “ahead,” keeping objects like vehicles and characters in roughly the same position on all machines

What’s the difference?

Car A wins on their screen, but Car B is the real winner, maybe? Client A could have won server-side if their ping was low and Client B has high ping.

Positions synced accurately, Car A is the unquestioned winner.

• More locally simulated physics at a larger scale results in more accurate collisions and interactions

Since the positions are more synced, that means if 2 vehicles hit each other, the collision accuracy is far better as the vehicles would react on time and realistically.
How does this look?

---

Interpolation:

1. Improper momentum transfer due to delayed impact and reaction
   1st Perspective (Huge impact delay):

https://cdn.discordapp.com/attachments/399314021934825487/771280372419657738/Ex1Client1.mp4

2nd Perspective (Car hits late and stops early):

https://cdn.discordapp.com/attachments/399314021934825487/771280361015214080/Ex1Client2.mp4

2. Inaccurate collisions due to delayed replication

1st Perspective (Car does not react to impact, also occurs if trying to hit someone who is moving fast):

https://cdn.discordapp.com/attachments/399314021934825487/771280383924371496/Ex2Client1.mp4

2nd Perspective (Hitting past hitbox, therefore not colliding with current hitbox):

https://cdn.discordapp.com/attachments/399314021934825487/771280394721034280/Ex2Client2.mp4

Extrapolation:

1. Proper momentum transfer from syncing position data more accurately
   1st Perspective (Momentum transfer occurs locally first then is corrected to actual outcome from server):

https://cdn.discordapp.com/attachments/399314021934825487/771280439859871774/Ex1Client1.mp4

2nd Perspective (Hit occurs locally at the right time):

https://cdn.discordapp.com/attachments/399314021934825487/771280434842697738/Ex1Client2.mp4

2. Accurate collisions due to extrapolated replication

1st Perspective (Same reason as above):

https://cdn.discordapp.com/attachments/399314021934825487/771280443974221834/Ex2Client1.mp4

2nd Perspective (Same reason as above):

https://cdn.discordapp.com/attachments/399314021934825487/771280443731345408/Ex2Client2.mp4

---

Further demonstrations of extrapolated physics:

https://cdn.discordapp.com/attachments/399314021934825487/771270666946740224/Example1.mp4
https://cdn.discordapp.com/attachments/399314021934825487/771270675293011978/Example2.mp4

---

I feel like this is something that the physics system has been needing for quite some time and it would greatly reduce the number of headaches spent over attempts at manual replication, as well as improving the quality of standard racing, derby, and shooting games by more accurately syncing the physics information (although, at a cost to physics performance impact). This is something that most engines already allow you to change, usually with some sort of toggle or menu, so it would be great if it was a feature in this one.

[GeorgeOfAIITrades]

The feature you’re looking for Roblox to implement is predictive pathing. Your first example (the drawings) demonstrates in a 1 dimensional way. Car A being ahead of Car B in a straight line.

Unfortunately things get more complex of course when trying this in all 3 dimensions for say example, a Plane game.

This is something I’ve been trying for, for quite some time but the answer I’ve usually got is that Roblox will not be spending time and effort towards this (at least any time soon)

[Wunder_Wulfe]

This is precisely why extrapolation and interpolation is used. Extrapolation takes the information from the previous frames in order to compute the trajectory of objects as they move across the area, and interpolation is used when applicable to correct trajectories that are incorrect, such as someone turns left after previously steering toward the right. This works fine in relatively slow speed situations with a modern and stable internet connection, but in a fighter pilot jet simulation game at very high speeds and players with bad connections, this system would have more difficulties, especially when players have a poor connection to the server. My implementation does exactly that, but it is rudimentary at best as I continue to make changes. This system works very very well for most land vehicles though due to the nature of their control. Most land vehicles are very heavy and have a lot of mass, giving them a lot of momentum and preventing immediate and direct control. This makes it easier to hide some of the problems by masking them with the vehicle’s weight.

[GroupyClumpy]

Great writeup and examples! We’ve already been experimenting with extrapolation internally, but we haven’t made any decisions yet. There are a lot of potential pitfalls/issues that we need to figure out first.

[Subsz (Sub)]

Any updates on this?

[MSDLF (Masol)]

The fact that we have streaming enabled makes sense that we should have a “ModelPhysicsStreaming” property

It would work by calculating the ping between each model or packet.
So each model takes time to arrive to the client and that’s measured.
the model also sends the velocity properties to the client.

The property “Extrapolate” is set to zero by default meaning the model received is exactly where it was
setting it to 1 means the model is extra polated forward (this can look a bit glitchy)
setting it to .4 means the model is partially extra polated so it gives a decent enough indication of where the car is.

Can also have some lerp for smoothing.

[ultra_2033]

Any update at all on this mate