Physics simulations and manual step

[FrenchKrab]

It would be nice to be able to run physics simulation under certain nodes and be able to manually call the step function (aswell as being able to disable the automatic physics calculations).

I think #20948 was a trying to achieve something like that, but the implementation was probably not flexible enough, and the pull request was closed. But an idea was given to be able to step a Space RID, which seems great and versatile enough.

The main use I see is for this feature would be networking and client/server reconciliation, where re-simulating the world on the server with newly acquired data is a common strategy.

[QbieShay]

Pardon my ignorance, but I thought that when you do multiplayer that involves physics there is only one machine, possibly the server, running the physics. (Also because bullet is non deterministic?)

[Calinou]

@QbieShay Godot's networking APIs do not require running the physics on the server (in fact, the Multiplayer Bomber demo runs all physics client-side). It's more exploitable, but it also has its upsides (such as decreased server resource usage, which can be of importance with high amounts of players or complex physics simulations).

[FrenchKrab]

@QbieShay About bullet being non deterministic, it seems (according to multiple posts on the pybullet.org forum, and some really quick tests I did in Godot (though i might not have tested it enough)) that Bullet is deterministic and so is Godot's implementation of it ?
It might be good to confirm that though, i'm not 100% sure at all.

[raymoo]

Floating point math behavior can vary between computers, so shouldn't be relied on to be deterministic. I think networked games which rely solely on a duplicated simulation (such as fighting games) normally use integer or rational math to update the game state. You might still be able to use the physics step for that kind of thing though, if you ignore or round the delta.

[Rubonnek]

@AndreaCatania could we have your input on this?

[Juankz]

I'm currently working on a networking demo where the player moves using forces, to perform client-server reconciliation the client needs to be able to re-simulate the last moves and provide a new output, all in one frame. This feature is required.

A workaround is to move the player by changing its velocity but that may leave the cases where for some reason you need a more physically accurate approach

[Calinou]

Is this a duplicate of #24769?

[Juankz]

@Calinou Related. The issue you mention propose 2 different ways to solve jitter on monitors with refresh rate other than 60 FPS: 1. iterate physics from script or 2. lock physics to the rendered frame rate.

The first solution fix our issue, which is something like what Unity does with physics.simulate

Worth to note the root issue is different, here we need to iterate physics from a script to implement a networking latency solution and #24769 is about jitter with monitor refresh rates.

[lawnjelly]

While I was working on #30798 I did try to have a little think about multiplayer (I've done stuff like client side prediction and rewinds before myself) but thought it might be a little much to get passed as a PR at the time, so that PR is aimed at single player much like the default ticking system, and is hard coded.

Given the new Godot proposals system, I was thinking I would put that PR up as a proposal, at least to gauge some interest. I'm quite happy to tweak the approach to a scriptable version and also get the kind of thing in this issue working, but it needs broad support to get merged because it is about the long term vision for Godot.

I have also built an unreleased system for allowing the user to create a callback for frame delta smoothing in gdscript etc, as I decided that might be better as non-hard coded, so a similar system could be used for ticking. I myself am open to the idea of having the whole time stepping being optionally user scriptable (it is quite easy to change from the hard coded approach in my PR, the concepts are the same). It isn't a bottleneck, so performance wise there isn't a reason why it couldn't be scripted. The only obvious potential snags I can see are in terms of future plans for multithreading, but obviously I'd have to investigate a bit more, it has to play nice with performance timers etc.

In terms of multiplayer rewind, rather than purely stepping the physics, I suspect what would be more useful is to run the entire physics tick (including the script physics_process) on demand, because you usually want to resimulate all the gameplay, not just the physics.

Tick history

You also typically need to keep a physics history in a circular buffer so you can revert to a particular tick, as well as a lot of other game data. This aspect is getting so game specific that it may be more difficult to expect the game engine / physics to retain a history, and be responsible for resetting back to previous ticks (especially as you don't want to be paying a price in single player games).

Even if you put support in the core physics for keeping the circular buffer and reverting, you have to deal with the issue that it may only be necessary to keep past data for certain objects (like players) and physics explosions for example might just be eye candy and not need reverting. So that side would require some thought, and if it ever got accepted initially, it would be more likely to be just the pure ability to step things manually, and leave it to the user to do stuff like reverting objects.

Anyway long and short, this may be quite doable, but it will require going through godot proposals and will probably require interest from reduz in terms of where he wants the engine to go.

[jonbonazza]

To add to the discussion, running a separate physics simulation on the client is sometimes desirable for certain uses of client-side prediction.