Hacker News new | ask | show | jobs
by robrtsql 1420 days ago
> Physics interpolation in 3D

This is huge. Initially, Godot didn't support any interpolation, which meant you either ignore fps altogether (and your game literally plays slower, and therefore differently, if the game slows down from 60 to 30 fps), or you move physics code to the _physics_process() and suffer from stutter/jitter because the physics code and the rendering code slowly drift out of sync. Amazing!

EDIT: I forgot to mention the _third_ possiblity, which is that you write a bunch of custom code in GDScript or C++ which attempts to do the interpolation.

2 comments

Not entirely true. For a long time Godot has had Engine.get_physics_interpolation_fraction, which permits smooth interpolation of visual bodies ticking at render rate while their physics bodies tick at the physics rate (2D or 3D). I can run my physics at 2 fps (or any increment) and an object will smoothly move from A to B, because rendering is happening in _process and target positions are being calculated in _physics_process.

Placing a camera under the control of a physics node is just the way most people do it because they don't know any better. Decoupling an object's physics representation from visual representation is something many devs never learn, and they pay the price with frustrating visual stuttering under any engine -- as I did for many, many months back in the day under Unity until figuring it all out.

I'm looking forward to playing with the new baked-in physics interpolation (albeit only for 3D so far) with 3.5, but this has been easy to implement in 3.x for anyone familiar with "get_physics_interpolation_fraction".

Why couldn't you just run physics at the graphics frame rate (or double it if the graphics becomes too slow)? I don't think many games need fully deterministic physics do they?

Like

    x += v * dt
    draw(x)
Or is that what this does?
Collision detection is a major reason. If you only sample positions at the frame rate, you're going to have bullets go through walls without hitting anything.

Also, physics is costly to run, so usually it's not run on every frame.

And you really want your collision detection to be reasonably deterministic. Reasonable frame rates range from 30fps to 240fps, which is nearly an order of magnitude, and you want your bullets to behave the same over that range.
You only need physics to run at a "fast enough" rate. Let me rephrase:

Why not just snap physics frames to graphics frames?

Frame rate is variable.