Skip to content

Enable Physics Interpolation by Default#1241

Open
Plide wants to merge 1 commit intoRedot-Engine:masterfrom
Plide:master
Open

Enable Physics Interpolation by Default#1241
Plide wants to merge 1 commit intoRedot-Engine:masterfrom
Plide:master

Conversation

@Plide
Copy link
Copy Markdown

@Plide Plide commented Apr 17, 2026

When creating a new project, physics interpolation is currently disabled by default. This means that for developers who use 60 hz monitors (or otherwise make the physics tick rate match the refresh rate), everything will seem to work fine.

However, for those who use a monitor with a different refresh rate, the project may end up stuttery. This is most noticable if both _physics_process() and _process() are mixed within code.

By enabling physics interpolation by default, projects should behave far more predictably across hardware. This is important, since a developer shouldn't be expected to change a default setting when their project otherwise works perfectly on their hardware.

Summary by CodeRabbit

  • New Features
    • Physics interpolation is now enabled by default, providing smoother physics simulations and improved visual quality for physics-based animations without requiring manual configuration.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 17, 2026

Walkthrough

The default value for the physics interpolation global setting is changed from disabled to enabled in the SceneTree constructor. This makes physics interpolation active by default when the corresponding configuration is not explicitly set by the user.

Changes

Cohort / File(s) Summary
Physics Interpolation Default
scene/main/scene_tree.cpp
Modified default parameter value for GLOBAL_DEF("physics/common/physics_interpolation", ...) from false to true, enabling physics interpolation by default in the SceneTree constructor.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Enable Physics Interpolation by Default' clearly and concisely summarizes the main change: switching the default physics interpolation setting from false to true in the SceneTree constructor.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
scene/main/scene_tree.cpp (1)

2061-2068: ⚠️ Potential issue | 🟠 Major

Behavior change affects existing projects on upgrade, not just new ones.

GLOBAL_DEF only persists a value to project.godot if it was explicitly set (persist flag defaults to false). Since the previous default was false and this code now uses true, any existing project that never explicitly toggled physics/common/physics_interpolation will silently use the new default after upgrading — and via lines 2066–2068, will also have physics_jitter_fix forcibly set to 0. This can produce visible behavioral changes (different motion smoothing, different process visuals, loss of jitter-fix compensation) in shipped games when developers rebuild against a new engine version.

While the CONFIG_VERSION mechanism exists in project.godot and could gate this change, there is no evidence it is currently used to limit the new default to new projects only.

Consider:

  • Confirm this is intentional for existing projects, or use CONFIG_VERSION to gate the new default to only projects created after a certain engine version.
  • Call this out prominently in release notes / migration docs, since it can alter the look of shipped games.
  • Verify any docs/tutorials that state "physics interpolation is disabled by default" are updated.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@scene/main/scene_tree.cpp` around lines 2061 - 2068, The change flips the
GLOBAL_DEF default for "physics/common/physics_interpolation" to true which
silently affects existing projects and forces jitter fix off via
is_physics_interpolation_enabled() ->
Engine::get_singleton()->set_physics_jitter_fix(0); instead gate this behavior
so only new projects get the new default: detect project CONFIG_VERSION (or a
similar creation/version flag) before calling GLOBAL_DEF or before forcing
jitter fix, keep the prior false default for projects with older CONFIG_VERSION,
and only apply set_physics_interpolation_enabled(true) /
set_physics_jitter_fix(0) for projects created/updated to the new config
version; update logic around GLOBAL_DEF, set_physics_interpolation_enabled,
is_physics_interpolation_enabled and the
Engine::get_singleton()->set_physics_jitter_fix call accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@scene/main/scene_tree.cpp`:
- Around line 2061-2068: The change flips the GLOBAL_DEF default for
"physics/common/physics_interpolation" to true which silently affects existing
projects and forces jitter fix off via is_physics_interpolation_enabled() ->
Engine::get_singleton()->set_physics_jitter_fix(0); instead gate this behavior
so only new projects get the new default: detect project CONFIG_VERSION (or a
similar creation/version flag) before calling GLOBAL_DEF or before forcing
jitter fix, keep the prior false default for projects with older CONFIG_VERSION,
and only apply set_physics_interpolation_enabled(true) /
set_physics_jitter_fix(0) for projects created/updated to the new config
version; update logic around GLOBAL_DEF, set_physics_interpolation_enabled,
is_physics_interpolation_enabled and the
Engine::get_singleton()->set_physics_jitter_fix call accordingly.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ab48319a-5c87-41f5-a2f8-a0f0d8e007d9

📥 Commits

Reviewing files that changed from the base of the PR and between 2a02d9c and 003447c.

📒 Files selected for processing (1)
  • scene/main/scene_tree.cpp

@Arctis-Fireblight
Copy link
Copy Markdown
Contributor

This probably warrants further discussion. IMO this probably should have been the default behavior to begin with but it doesnt look like this feature has been around very long, the first mention I see of it in the docs is 4.4.

My main concern is that this appears to change the way people design their game logic from my casual reading of the documentation: https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/using_physics_interpolation.html

This is less of a breaking change per say due to it only being a default settings for new projects, but I can see situations where people might be following along with Godot tutorials, putting movement logic inside of _process instead of _physics_process, and then getting surprised by the results.

Another off hand concern I see might be latency, if we have a tick rate of 60 FPS, then game technically has to run a full physics tick ahead of what is being rendered on screen, introducing an extra 1/60th of a second of latency in exchange for smoother graphics. While I dont think this is a big deal for most types of games or at reasonable tick rates, the effect becomes a lot more noticeable if the game slows down to lower tick rates.

So while I am not opposed to making this the default behavior, I'd like to see more input from the community before making the decision to merge this or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants