Physics interpolation (3D) #92391

rburing · 2024-05-26T18:05:19Z

Adds 3D physics interpolation to the rendering server, based on @lawnjelly's

This PR does not yet include support for multimeshes (#91818) or particles.

3d-physics-interpolation-just-dropped.mp4

To-do:

Make it compile.
Make it work.
Bind some RenderingServer methods and add their documentation.
Include more follow-up fixes/changes that came after the initial PR.
Test more extensively.

This PR is sponsored by My Spare Time™.

Production edit: This closes Physics interpolation is not implemented for 3D #89846 and
closes Add physics step interpolation in 3D (implemented in 2D since 4.3) godot-proposals#2753.

Calinou · 2024-05-26T18:29:22Z

Some early testing with physics ticks set to 10 Hz and physics interpolation enabled in the project settings:

It works in Truck Town, but wheels act wonky when the car moves fast enough (due to the wheels spinning too fast for a single physics tick to handle). Also, the FOV change based on speed isn't aware of interpolation so it looks stuttery:

simplescreenrecorder-2024-05-26_20.22.58.mp4

Here it is without the FOV change:

simplescreenrecorder-2024-05-26_20.23.55.mp4

Interpolation doesn't seem to work in Platformer 3D and Kinematic Character though:

simplescreenrecorder-2024-05-26_20.25.15.mp4

simplescreenrecorder-2024-05-26_20.26.18.mp4

Note that in Platformer 3D, AnimationTree is used to animate the character, but root motion is not used (unlike the TPS demo). AnimationTree with the Physics Process update mode isn't handled by physics interpolation in 3.x (which leads to stuttery character animations even if movement is smooth), so hopefully this could be implemented in 4.x.

rburing · 2024-05-27T17:28:42Z

This now includes all the follow-up fixes/changes, so it is ready for (re-)testing and review.

SpockBauru · 2024-05-28T01:49:30Z

Hello, I downloaded the artifact and made a test scene with a car. Here is the scene:
physics-interpolation-test.zip

Testing with physics ticks set to 15 Hz, the car handling seems to behave the same with physics interpolation on and off, but the wheels shows in a strange way:

physics_interpolation_test_01_edit.mp4

lawnjelly · 2024-05-28T06:15:05Z

There seems some confusion here:

Wheels, helicopters and fast rotating objects cannot easily be natively handled by physics interpolation. I mentioned it here (and several other places if I remember right), although it may not be in the docs yet:

#52846 (comment)
#72207

The problem is that in the VisualServer the only information you have for rotation is a basis, which is effectively capped between e.g. 0 and 360 degrees. The interpolation can only assume a shortest arc between the two most recent samples, e.g. 0-40, 170-190, 350-20 etc.

The problem is that if an object moves more than 180 degrees in one tick, the interpolation will be wrong:

Wheel moves 0-190, the interpolation will be from 190-360 (because that is the shortest arc), i.e. the interpolation will rotate in the opposite direction. You can't use intelligence to decide that from the previous move it is likely to move from 0-190, because, well it could be moving in reality from 190-360, and in some circumstances the intelligent version would be wrong.

So for fast rotating objects you either have to up the tick rate, or turn off physics interpolation for that object and handle it manually on the client side (rather than server). It is possible the vehicle wheel class could be modified to handle this client side.

This has already come up in users games, and they have taken the approach to switch off (using physics_interpolation_mode) and handle it manually.

You will probably need to use get_global_transform_interpolated() to get the wheels to line up to the interpolated car body (else the wheel positions will not be interpolated, and will lead the car).

passivestar · 2024-05-28T07:46:40Z

So if an explosive force sends a box rotating quickly you'll see interpolation artifacts? Doesn't it mean that you can never be sure and will have to go back to manually interpolating all unconstrained rigid bodies if you want reliable results? Could angular velocities be taken into account when interpolating maybe?

lawnjelly · 2024-05-28T07:49:04Z

So if an explosive force sends a box rotating quickly you'll see interpolation artifacts? Doesn't it mean that you can never be sure and will have to go back to manually interpolating all unconstrained rigid bodies if you want reliable results? Could angular velocities be taken into account when interpolating maybe?

Yes, ideally it would be nice to modify the physics / render server to be able to send across something like a delta so we could deal with this problem correctly. The current situation is due to historical design, which didn't foresee physics interpolation.

A little background
It took a lot of lobbying / convincing and politics to get physics interpolation into 3.x, so the emphasis had been on minimally intrusive approach. As time has gone on the community has learned that this is not a fringe feature, but essential for most games (in some form - in multiplayer you may use different approach, and pixel perfect games may use different techniques).

So now (in 4.x at least) it is a lot more feasible to consider more intrusive engine changes to make things work as easily as possible for users (like sending delta to VisualServer).

On the other hand we have to trade off the engine code complexity and maintenance, as e.g. sending deltas can makes physics interpolation code creep into more areas, and contributors often have to be aware of how it works in order to make changes / not break things, so there is a definite cost.

There's the maintenance of 2 paths - with and without interpolation, and we ideally don't want physics interpolation to add a cost to projects that don't want to use it.

Calinou · 2024-05-30T01:44:42Z

I gave the latest iteration of this PR a try, here are my findings:

Interpolation works great on the TPS demo, Platformer 3D and Kinematic Character demos now.
Movie Maker mode works correctly when physics interpolation is enabled (it's expected, I checked just to make sure). Adjusting time scale while the project is running also keeps physics interpolation functional.

Is spinning VehicleWheel shrinking a problem at 60 ticks per second?

Unfortunately, it's still an issue at 60 ticks per second, even at moderate speeds (< 100 km/h). It's noticeable enough that even on 60 FPS footage with the game running at 120 FPS, it can still be seen. (On this particular example, this is because I used ShareX for recording, which isn't 100% perfect in terms of frame pacing like Movie Maker mode would be.)

It might be worth looking into a client-side solution (i.e. a solution implemented directly in VehicleWheel3D, where the node itself has interpolation disabled but interpolation is performed in the node). I haven't checked if VehicleWheel2D suffers from this issue yet.

physics_interpolation_wheel_wobble_60_tps.mp4

Are sudden position/rotation changes (e.g. caused by explosions that impact rigid bodies) a problem?

From a quick test, they don't appear to be a problem, even at very low tick rates (like 10 TPS):

Bouncing cylinders

Warning

Firefox doesn't seem to display the videos recorded with Movie Maker mode then converted to MP4 with FFmpeg for some reason. Use a Chromium-based browser, or right-click > Save Video As... and view in a media player.

physics_interpolation_cylinders_10_tps.mp4

Changing tick rate during the simulation doesn't incur a noticeable hitch, as long as the change is smooth (and not a sudden change like 60 -> 20 or the other way around):

physics_interpolation_dynamic_tick_rate.mp4

physics_interpolation_dynamic_tick_rate_sudden_change.mp4

Boxes explosion

Recorded with Movie Maker mode.

boxes_explosion_10_tps.mp4

boxes_5_tps_time_scale_05.mp4

Testing projects:

SheepCommander · 2024-05-31T07:08:40Z

Hey I just tested it on a certain personal project and it crashes at the end, without printing the final crash error to the editor console.

This is the most recent error in the debug console (NOT the cause of the crash)

15 TPS Interpolation + Crash at end:

interpolated2.mp4

For reference: 15 TPS No Interpolation (But no crash)

not-interpolated1.mp4

scene/3d/node_3d.cpp

SheepCommander · 2024-06-02T09:41:58Z

I tested it again with the Console open this time.

Full log: godot.log

The final error before crashing seems to be

USER ERROR: FATAL: Index p_index = 0 is out of bounds (count = 0).
   at: LocalVector<int,unsigned int,0,0>::operator [] (.\core/templates/local_vector.h:173)

SheepCommander · 2024-06-02T09:59:25Z

I found the log for the crash in my previous reply, and I'm a bit confused?

In that previous instance there is _not_ any fatal error before crashing, it just suddenly crashes.

USER WARNING: Target object freed before starting, aborting Tweener.
   at: PropertyTweener::start (scene\animation\tween.cpp:550)

================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.beta.custom_build (36dcc8382955ecf5ab981bafa6df7223039e5f56)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] <couldn't map PC to fn name>
[1] <couldn't map PC to fn name>
[2] <couldn't map PC to fn name>
[3] <couldn't map PC to fn name>
[4] <couldn't map PC to fn name>
[5] <couldn't map PC to fn name>
[6] <couldn't map PC to fn name>
[7] <couldn't map PC to fn name>
[8] <couldn't map PC to fn name>
[9] <couldn't map PC to fn name>
[10] <couldn't map PC to fn name>
[11] <couldn't map PC to fn name>
[12] <couldn't map PC to fn name>
[13] <couldn't map PC to fn name>
[14] <couldn't map PC to fn name>
[15] <couldn't map PC to fn name>
[16] <couldn't map PC to fn name>
[17] <couldn't map PC to fn name>
[18] <couldn't map PC to fn name>
[19] <couldn't map PC to fn name>
[20] <couldn't map PC to fn name>
[21] <couldn't map PC to fn name>
[22] <couldn't map PC to fn name>
[23] <couldn't map PC to fn name>
[24] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================

Full log here: godot2024-05-31T00.00.15.log

matmas · 2024-06-03T01:09:43Z

scene/3d/node_3d.cpp

+	data.client_physics_interpolation_data->timeout_physics_tick = Engine::get_singleton()->get_physics_frames() + 256;
+
+	// Make sure data is up to date.
+	update_client_physics_interpolation_data();


This function seems to be called twice per process frame - once here and the other time due to calling tree->client_physics_interpolation_add_node_3d(...) at the end of this function. Since update_client_physics_interpolation_data() is not idempotent the variables global_xform_curr and global_xform_prev will end up having same value which results this function returning transforms that are not interpolated as (a + (b - a) * f equals a when a == b.

Yes but see the method, it doesn't update the previous if it's on the same tick, right?

It is often called twice, yes. The function contains a tick counter which ensures it only operates once per tick.

The data must get updated, but if get_global_transform_interpolated() is called before the tick update, it is refreshed early. The logic admittedly isn't super clear, but it works this way to prevent an order of operations bug.

Yes, it is true that global_xform_prev is updated only once per tick.

The not so obvious thing is that when update_client_physics_interpolation_data() gets called from SceneTree::ClientPhysicsInterpolation::physics_process(), the function Engine::get_singleton()->get_physics_frames() is returning incorrect value due to being updated late. This way the newly changed value from get_global_transform() is stored into global_xform_curr even before we actually change global_xform_prev. The next call to update_client_physics_interpolation_data() from get_global_transform_interpolated() we finally see that the tick has changed and we set global_xform_prev to global_xform_curr which is the same as get_global_transform() and so both global_xform_prev and global_xform_curr end up having the same value.

AThousandShips

Looks very intriguing! Looking forward to this

servers/rendering/renderer_scene_cull.cpp

core/math/transform_interpolator.cpp

scene/3d/visual_instance_3d.cpp

lawnjelly · 2024-06-04T13:09:48Z

I found the log for the crash in my previous reply, and I'm a bit confused?

In that previous instance there is not any fatal error before crashing, it just suddenly crashes.
Full log here: godot2024-05-31T00.00.15.log

Given the amount of errors in your log, it is possible you are just blowing the message queue. If you can fix the errors with the Tweener and get_pixel() that might be helpful to see if you still get a crash.

The interpolation warnings has a built in timer to prevent excessive error spam.

matmas · 2024-06-04T14:24:51Z

Here is another test project that shows a potential issue:
test-physics-interpolation-camera-godot4.zip

test-physics-interpolation-camera-godot4.mp4

The NinePatchRect with the 4 corners doesn't stay centered on the ball. The issue is visible only when camera is moving. Project is using 10 physics ticks per second.

Interestingly enough this issue is also reproducible in Godot 3.6-beta5.
Here is the Godot 3 version of the project:
test-physics-interpolation-camera-godot3.zip

If instead of the built-in physics interpolation we use lawnjelly's smoothing-addon (https://github.com/lawnjelly/smoothing-addon/tree/4.x) then this issue disappears:

test-physics-interpolation-camera-godot4-smoothing-addon.mp4

Here is the Godot 4 version using the smoothing-addon:
test-physics-interpolation-camera-godot4-smoothing-addon.zip

To reproduce the first video you might need to get get_global_transform_interpolated() working first. I used this:

diff --git a/scene/3d/node_3d.cpp b/scene/3d/node_3d.cpp
index 30f5d6f88a..3c36909732 100644
--- a/scene/3d/node_3d.cpp
+++ b/scene/3d/node_3d.cpp
@@ -400,18 +400,18 @@ void Node3D::_disable_client_physics_interpolation() {
 }
 
 Transform3D Node3D::_get_global_transform_interpolated(real_t p_interpolation_fraction) {
-   ERR_FAIL_COND_V(is_inside_tree(), Transform3D());
+   ERR_FAIL_COND_V(!is_inside_tree(), Transform3D());
 
    // Set in motion the mechanisms for client side interpolation if not already active.
    if (!_is_physics_interpolated_client_side()) {
        _set_physics_interpolated_client_side(true);
 
-       ERR_FAIL_NULL_V(data.client_physics_interpolation_data, Transform3D());
        data.client_physics_interpolation_data = memnew(ClientPhysicsInterpolationData);
        data.client_physics_interpolation_data->global_xform_curr = get_global_transform();
        data.client_physics_interpolation_data->global_xform_prev = data.client_physics_interpolation_data->global_xform_curr;
        data.client_physics_interpolation_data->current_physics_tick = Engine::get_singleton()->get_physics_frames();
    }
+   ERR_FAIL_NULL_V(data.client_physics_interpolation_data, Transform3D());
 
    // Storing the last tick we requested client interpolation allows us to timeout
    // and remove client interpolated nodes from the list to save processing.
@@ -423,9 +423,6 @@ Transform3D Node3D::_get_global_transform_interpolated(real_t p_interpolation_fr
    // would be machine dependent.
    data.client_physics_interpolation_data->timeout_physics_tick = Engine::get_singleton()->get_physics_frames() + 256;
 
-   // Make sure data is up to date.
-   update_client_physics_interpolation_data();
-
    // Interpolate the current data.
    const Transform3D &xform_curr = data.client_physics_interpolation_data->global_xform_curr;
    const Transform3D &xform_prev = data.client_physics_interpolation_data->global_xform_prev;

Adds 3D fixed timestep interpolation to the rendering server. This does not yet include support for multimeshes or particles. Co-authored-by: lawnjelly <[email protected]>

rburing · 2024-07-07T20:21:48Z

This PR now includes the latest follow-up fixes that were already merged into the 3.x branch.

ansdor · 2024-08-15T13:34:53Z

when this gets merged, will it also work with third party physics engines like jolt and rapier?

Calinou · 2024-08-15T14:50:51Z

when this gets merged, will it also work with third party physics engines like jolt and rapier?

Looking at the list of modified files, it looks like this PR should work with third-party physics engines out of the box (no GodotPhysics code was changed).

rburing · 2024-08-15T14:54:14Z

Yes, I confirm it works with Godot-Jolt and any other 3D physics engine GDExtension you can find. It's physics engine agnostic, all the physics engine has to do is tick.

akien-mga · 2024-08-16T08:54:46Z

Thanks @rburing and @lawnjelly for the amazing work! 🎉

I know the community is eagerly awaiting this, please all make sure to test it well (will be in 4.4-dev1 and beyond) and report any issues to fix before 4.4.

KingKrouch · 2024-08-26T14:29:13Z

So I just gave this a shot on the 4.4 Dev 1 release.

Setting aside not being enabled by default (I personally think enabling it by default would be a good precaution for those just getting started with the engine), it instantly makes stuff like the GDQuest TPS controller demo way smoother without any extra work needed. Fantastic PR!

reubenmanning · 2024-08-26T17:27:09Z

I've done a quick FPS test project. I can still notice some slight jitter on my 165hz monitor when I move the camera around. It's most apparent when I slowly walk around a small cube and keep it centered on screen. It's almost as if the camera movement is causing the jitter. Unless my character node setup isn't ideal.

If I don't look around, it looks buttery smooth while moving.

test-fps-physics-interpolation.zip

lawnjelly · 2024-08-26T17:54:03Z

I've done a quick FPS test project. I can still notice some slight jitter on my 165hz monitor when I move the camera around.

Be sure to read the documentation regarding cameras.
https://docs.godotengine.org/en/3.6/tutorials/physics/interpolation/advanced_physics_interpolation.html

mrjustaguy · 2024-08-26T20:26:27Z

this should NOT be enabled by default, as there's plenty of stuff you need to know about to properly take advantage of this and not introduce potentially massive bugs in your games

mrjustaguy · 2024-08-28T09:39:24Z

Case in point: TokisanGames/Terrain3D#470

Physics Interpolation breaks the Terrain here. It's unclear if this is a Terrain3D issue with it not properly using Interpolation or Godot messing something up with it.

Disabling Interpolation on the Terrain3D node and/or camera that it centers on does nothing..

Though given that just enabling the Physics Interpolation and absolutely disabling it in the Scene tree (by setting root node PI to off) it does seem like Godot's in some way at fault here...

rburing · 2024-08-28T19:17:08Z

@mrjustaguy This PR has been merged, please create a new issue with a minimal reproduction project and I can take a look. (This goes for all potential issues.)

rafa985 · 2024-09-13T16:47:35Z

Cant get it to work on quest 3 standalone. Is it mobile compatible?

Calinou · 2024-09-16T23:04:41Z

Is it mobile compatible?

There's nothing that should prevent physics interpolation from working on mobile/web platforms. However, there may be XR-specific issues with physics interpolation. Does it work on a Quest 3 tethered to a PC? I suggest opening a separate issue.

this should NOT be enabled by default, as there's plenty of stuff you need to know about to properly take advantage of this and not introduce potentially massive bugs in your games

While we should not change the default value to avoid breaking existing projects, I'd say we should consider enabling it by default in newly created projects using the approach described in godotengine/godot-proposals#4834. Physics interpolation really ought to be enabled in any shipping game in 2024, as you will never get 100% smooth movement without it (due to different monitor refresh rates or temporary framerate drops). It's an issue that plagues a lot of Unity games released to this day due to its 50 Hz default update rate – and modders are generally unable to fix it.

The sooner you enable physics interpolation in a new project, the better you'll be able to diagnose and fix related issues before releasing your game.

rafa985 · 2024-09-16T23:24:12Z

I have not tested that yet but I suspect it would behave just like in non VR on pc. I don’t know why it’s just native on quest that it turns off

…

On Mon, 16 Sep 2024 at 19:05 Hugo Locurcio ***@***.***> wrote: Is it mobile compatible? There's nothing that should prevent physics interpolation from working on mobile/web platforms. However, there may be XR-specific issues with physics interpolation. Does it work on a Quest 3 tethered to a PC? — Reply to this email directly, view it on GitHub <#92391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQY535AJXHQHZ46HQ2IGKNDZW5P2NAVCNFSM6AAAAABIUDSULCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJUGE3TSOJVHE> . You are receiving this because you commented.Message ID: ***@***.***>

mrjustaguy · 2024-09-17T07:41:53Z

Calinou, no, under no circumstance enable this by default, you'll flood Godot's issue section with Bugs related to Physics Interpolation that aren't Godot's fault but just the fundamental principles of PI in action.

People Must Know what they're getting into, and the added complexities of dealing with PI, Period.

Physics Interpolation isn't and cannot ever be made into "just works" as you have to know when to reset Physics Interpolation (say teleportation of objects) and when to manually handle Interpolation when Godot doesn't understand what you're doing (say handling a gimbaled camera that's moving and rotating) to get the desired results that just work without PI.

the First cannot be resolved ever, and the only "patch" would be to add a "Teleport" function that handles this and hope users figure out that it exists before experiencing Teleportation Interpolation issues
the Second is an endless game of whack-a-bug as there'll always be some case where Interpolation will not understand the user's intentions, and you may very easily break existing stuff when trying to patch an edge case.

Jamsers · 2024-09-17T08:14:17Z

Godot's interpolation already has the "teleport" function: reset_physics_interpolation()

For scenarios where you don't want physics interpolation (or want to do your own custom interpolation), you can selectively disable interpolation on a node by node basis, and all its children inherit this property (by default):

In fact, even if physics interpolation is enabled in the project, if your root node has the physics interpolation property turned off (and all other nodes are left at default), it'll be functionally similar to having physics interpolation disabled.

Given these facts, I can see a better argument for having (project) physics interpolation enabled by default. The scenarios where a user would benefit from interpolation far outnumber the scenarios where users would want interpolation off. And in the scenarios where you would want interpolation off, it's far better to disable interpolation for the specific nodes involved in said scenario, rather than turning it off for the entire project.

mrjustaguy · 2024-09-17T12:37:21Z

The main problem is the user has to KNOW they're using Physics Interpolation, something a Beginner WILL NOT KNOW, nor be informed of the implications of using it, and you totally missed the point of the 2 examples I've given above.
I know that that function exists, I also know that I can disable Physics Interpolation and do my custom logic easily.

A User that doesn't even KNOW they're using Physics Interpolation will not KNOW that they need to reset physics interpolation when teleporting, nor that there may be cases where they need to write their own Interpolation Logic, simply because they won't even KNOW that they're using the Feature, It'll just Manifest to them as Bugs that'll needlessly frustrate the unaware users

Physics Interpolation can be Heavily Recommended in the Documentation with getting started (and project setting) and all with all the relevant links to the documentation regarding proper usage, but it cannot be stressed enough, this CANNOT be on by default.

Don't get me wrong, I'd love to have Physics Interpolation as Standard, but this cannot be enforced by Godot, as Godot can only enforce things that are blatantly obvious to the user, or things that "Just Work"

mvccogo · 2024-12-01T21:25:26Z

The main problem is the user has to KNOW they're using Physics Interpolation, something a Beginner WILL NOT KNOW, nor be informed of the implications of using it, and you totally missed the point of the 2 examples I've given above. I know that that function exists, I also know that I can disable Physics Interpolation and do my custom logic easily.

A User that doesn't even KNOW they're using Physics Interpolation will not KNOW that they need to reset physics interpolation when teleporting, nor that there may be cases where they need to write their own Interpolation Logic, simply because they won't even KNOW that they're using the Feature, It'll just Manifest to them as Bugs that'll needlessly frustrate the unaware users

Physics Interpolation can be Heavily Recommended in the Documentation with getting started (and project setting) and all with all the relevant links to the documentation regarding proper usage, but it cannot be stressed enough, this CANNOT be on by default.

Don't get me wrong, I'd love to have Physics Interpolation as Standard, but this cannot be enforced by Godot, as Godot can only enforce things that are blatantly obvious to the user, or things that "Just Work"

I am not entirely convinced that having it enabled by default is the correct thing, but this argument does not make much sense. There are thousands of things a Godot beginner will also not KNOW, and that's why the documentation exists. In contrast, how many "camera jitter bugs" would go away if interpolation was on by default? It seems like a rite of passage that could easily be dealt with now.

A Godot beginner will most likely go through the "Getting Started" articles, so why can't we respect them a bit more and assume they will also read a big warning note if it is added there?

rburing added enhancement topic:rendering topic:physics topic:3d labels May 26, 2024

rburing added this to the 4.x milestone May 26, 2024

rburing force-pushed the fti_3d branch from c790ec7 to 9b561ac Compare May 27, 2024 17:25

rburing marked this pull request as ready for review May 27, 2024 17:26

rburing requested review from a team as code owners May 27, 2024 17:26

rburing force-pushed the fti_3d branch from 9b561ac to 36dcc83 Compare May 27, 2024 20:03

audeck mentioned this pull request May 28, 2024

Jittery camera movement when physics tick rate doesn't match FPS ramokz/phantom-camera#241

Closed

This comment was marked as off-topic.

Sign in to view

matmas reviewed Jun 1, 2024

View reviewed changes

scene/3d/node_3d.cpp Outdated Show resolved Hide resolved

matmas reviewed Jun 3, 2024

View reviewed changes

AThousandShips reviewed Jun 4, 2024

View reviewed changes

core/math/transform_interpolator.cpp Outdated Show resolved Hide resolved

core/math/transform_interpolator.cpp Outdated Show resolved Hide resolved

scene/3d/visual_instance_3d.cpp Show resolved Hide resolved

scene/3d/visual_instance_3d.cpp Outdated Show resolved Hide resolved

rburing force-pushed the fti_3d branch from 14a2901 to 1a8c91b Compare July 7, 2024 20:12

Fixed Timestep Interpolation (3D)

2f8ab4a

Adds 3D fixed timestep interpolation to the rendering server. This does not yet include support for multimeshes or particles. Co-authored-by: lawnjelly <[email protected]>

rburing force-pushed the fti_3d branch from 1a8c91b to 2f8ab4a Compare July 7, 2024 20:15

FilipLundby mentioned this pull request Jul 12, 2024

Physics interpolation (3D): Issue when setting the position of a Rigidbody or Kinematicbody #59173

Closed

tbillington mentioned this pull request Aug 16, 2024

Support interpolating values from fixed-timestep systems bevyengine/bevy#1259

Open

akien-mga merged commit 46c6865 into godotengine:master Aug 16, 2024
18 checks passed

rburing deleted the fti_3d branch August 16, 2024 10:01

Jamsers mentioned this pull request Aug 25, 2024

Jittering and smearing on physics objects in motion, especially those held by the physics gun Jamsers/Bistro-Demo-Tweaked#39

Open

rburing mentioned this pull request Oct 8, 2024

Camera2D with physics_interpolation_mode off triggers editor and runtime errors #97957

Open

yythlj mentioned this pull request Oct 24, 2024

4.4.dev的物理插值合并 WeDot-Engine/WeDot#8

Closed

MJacred mentioned this pull request Oct 26, 2024

Deprecate redundant fract_delta property in GPUParticles #55743

Open

tetrapod00 mentioned this pull request Nov 7, 2024

Add physics interpolation docs to 4.3 godotengine/godot-docs#9738

Closed

Physics interpolation (3D) #92391

Physics interpolation (3D) #92391

Conversation

rburing commented May 26, 2024 • edited Loading

Calinou commented May 26, 2024 • edited Loading

rburing commented May 27, 2024

SpockBauru commented May 28, 2024

lawnjelly commented May 28, 2024 • edited Loading

passivestar commented May 28, 2024

lawnjelly commented May 28, 2024 • edited Loading

This comment was marked as off-topic.

Calinou commented May 30, 2024 • edited Loading

Is spinning VehicleWheel shrinking a problem at 60 ticks per second?

Are sudden position/rotation changes (e.g. caused by explosions that impact rigid bodies) a problem?

Bouncing cylinders

Boxes explosion

SheepCommander commented May 31, 2024 • edited Loading

SheepCommander commented Jun 2, 2024

SheepCommander commented Jun 2, 2024

matmas Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

AThousandShips Jun 4, 2024

Choose a reason for hiding this comment

lawnjelly Jun 4, 2024

Choose a reason for hiding this comment

matmas Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

AThousandShips left a comment

Choose a reason for hiding this comment

lawnjelly commented Jun 4, 2024

matmas commented Jun 4, 2024 • edited Loading

rburing commented Jul 7, 2024

ansdor commented Aug 15, 2024

Calinou commented Aug 15, 2024 • edited Loading

rburing commented Aug 15, 2024

akien-mga commented Aug 16, 2024

KingKrouch commented Aug 26, 2024

reubenmanning commented Aug 26, 2024

lawnjelly commented Aug 26, 2024

mrjustaguy commented Aug 26, 2024

mrjustaguy commented Aug 28, 2024 • edited Loading

rburing commented Aug 28, 2024

rafa985 commented Sep 13, 2024

Calinou commented Sep 16, 2024 • edited Loading

rafa985 commented Sep 16, 2024 via email

mrjustaguy commented Sep 17, 2024 • edited Loading

Jamsers commented Sep 17, 2024

mrjustaguy commented Sep 17, 2024

mvccogo commented Dec 1, 2024

rburing commented May 26, 2024 •

edited

Loading

Calinou commented May 26, 2024 •

edited

Loading

lawnjelly commented May 28, 2024 •

edited

Loading

lawnjelly commented May 28, 2024 •

edited

Loading

Calinou commented May 30, 2024 •

edited

Loading

SheepCommander commented May 31, 2024 •

edited

Loading

matmas Jun 3, 2024 •

edited

Loading

matmas Jun 5, 2024 •

edited

Loading

matmas commented Jun 4, 2024 •

edited

Loading

Calinou commented Aug 15, 2024 •

edited

Loading

mrjustaguy commented Aug 28, 2024 •

edited

Loading

Calinou commented Sep 16, 2024 •

edited

Loading

mrjustaguy commented Sep 17, 2024 •

edited

Loading