Does Godot's 3D renderer interpolate/extrapolate physics?

wkk

Hello there!

I'm experimenting with VR and physics in Godot, but I get a choppy feeling when using physics-based movement...

I was wondering if Godot was doing any kind of smoothing when it comes to geometry moved by the physics engine?

For example, let's assume physics are running at 90Hz and renderer 120Hz, when moving objects will Godot's 3D renderer compensate for the missing physics frame and move mesh instances according to the last known linear/angular velocity? Or do I need to implement this myself? Or is it a stupid idea to begin with?

TwistedTwigleg

Welcome to the forums @wkk!

To the best of my knowledge, there isn’t currently any form of smoothing for physics when the physics and display FPS differ. There is a proposal for adding some form of interpolation though, so this may be changed in future Godot versions.

Megalomaniak

@wkk said: I was wondering if Godot was doing any kind of smoothing when it comes to geometry moved by the physics engine?

I do not know the answer but my gut feeling says no. It is an interesting question though and I do hope that someone more familiar with that will come and answer it.

cybereality

I found I got the smoothest response from handling player input on process rather than physics_process. The physics runs at 60Hz by default (you should be able to change it in the project settings) but I'm running a 160Hz monitor, so things look choppy the default way.

wkk

Thank you for the answers,

@TwistedTwigleg said: [...] There is a proposal for adding some form of interpolation though, so this may be changed in future Godot versions.

I have plenty to read thanks to your link!

In the meantime I also noticed that some of the clunkiness came from my scripts x)

dotted

I found I got the smoothest response from handling player input on process rather than physics_process. The physics runs at 60Hz by default (you should be able to change it in the project settings) but I'm running a 160Hz monitor, so things look choppy the default way.

This is also my expectation. Inputs change at the speed of human motion. It's a bit whacked to sample it at 60hz gobbling up cpu time calling functions that repeatedly return the same thing.

Wolfe

I've got a whole different jumble of numbers from @cybereality, running physics at 240Hz, with inputs fed to the physics in process(), while the camera follows along in physics_process(), primarily testing on a 144Hz screen (occasionally a couple 60Hz alternatives).

I found the camera's following behavior has to be on _physics_process() to be in sync, but then I have no complaint about the results on all three screens. One of them is a non-gaming laptop that musters about 30fps from my project, which produced somewhat erratic results in 3.2.3 but is better-behaved in 3.3.

cybereality

Running physics at 240Hz sounds like overkill. It would probably be really taxing on the CPU.

Azedaxen

By default, Godot doesn't have any sort of physics interpolation, but there's an addon that helps with adding interpolation to physics: https://godotengine.org/asset-library/asset/447

I definitely wouldn't recommend running physics any higher than 60hz, (72hz might be okay if you're making a VR game since that appears to be the standard for VR right now) it's wasteful for any monitor that can't refresh that quickly, and 60hz still appears to be the most common refresh rate, so I think it makes the most sense to just leave your physics rate at that and interpolate if you want things to appear smoother on high-refresh monitors.

wkk

@Azedaxen Unless I hit a wall with Godot Physics performance I'll keep it at 90Hz since I'm targeting decent hardware, and because I am experimenting with a physics based game I'll sync it with the mid-range of PC VR headset refresh rate. I'm mostly inspiring myself from Boneworks to be honest, and physics run at 90Hz there, and I have my headset running at 90Hz too (even though it could go to 120Hz and 144Hz).

I've already quickly looked at that addon, and experimented with my own code on what currently are VR hands to see if I would gain anything from actually going that direction. And it seems like smoothing would work for me :)

Wolfe

240Hz is not overkill or wasteful in the slightest for the purpose of a tire model and vehicle simulation. :) It's a special case that requires more precision than 60Hz. I have slid the value up and down throughout development to see how low of a value I can get away with.

One issue is that the behavior of a common tire model like mine is essentially undefined at rest. Tire forces rapidly tug in all directions, reacting to the "micro slip" of tiny velocities in a simmering chain reaction that creates unwanted effects. I have added a couple other measures to minimize this inherent weakness.

Too low of a value is also noticeable in the handling when driving.

I just wanted to chip in the input that putting camera movement in _physics_process() keeps my camera in sync with the car, regardless of the framerate or screen refresh.

cybereality

I see okay. Good to know.