Repository: godotengine/godot (language: cpp)

Issue:
Physics interpolation affects particle systems
### Tested versions

v4.4.stable.official [4c311cbee]

### System information

Godot v4.4.stable - Windows 10 (build 19045) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (NVIDIA; 32.0.15.6636) - AMD Ryzen 5 3600 6-Core Processor (12 threads)

### Issue description

Physics interpolation affects gpu particle systems. This seems wrong, as I don't think particle systems are considered physics objects. It's a problem if you ever want to move particle systems before restarting them in the same frame, as the particles will spawn in between where they're coming from and their destination. 
Workarounds easy, just disable physics interpolation on the particle system.

### Steps to reproduce

Enable physics interpolation in project settings and on a burst particle system and have the system move the same frame restart() is called. The particles shouldn't appear at the correct position, instead somewhere in between the position it traveled from and its destination.

### Minimal reproduction project (MRP)

[issue.zip](https://github.com/user-attachments/files/19382421/issue.zip)


Discussion / hints:
Physics interpolation is not specific to physics objects (despite the confusing name), it's named this way because it interpolates visual elements between physics ticks / fixed framerate.

CC @lawnjelly @rburing 
I see, in that case the tooltip for the toggle should be updated as it says it interpolates the transforms of specifically physics objects. 
Akien covers it mostly above, physics interpolation applies to all nodes, and the name is confusing (I would have preferred it to be called FTI ("fixed timestep interpolation") from the get go).

Additionally it may not have been emphasized enough in the release notes (I don't generally get too involved with 4.x), but physics interpolation is both:
* Experimental at this stage, and subject to change (and indeed 3D is likely going to be changed significantly soon with #104269 ). Consider it a "work in progress" as we are reliant on feedback from 4.4 to make changes / fix bugs.
* Not all nodes are guaranteed to work with it, especially GPUParticles in 2D and 3D, if these work at all currently it is more "by accident". CPUParticles are currently more reliable (as they have changes made specifically to support FTI), but I can only speak for the situation in 3.x, as @rburing did the conversion for 4.x, and particles may work slightly differently.

After #104269, for `GPUParticles3D` in your MRP rather than turn off physics interpolation for the whole project, you can turn it off just for the GPUParticles node via `physics_interpolation_mode` (either in script or in the inspector for the node).

Particles in particular often need special treatment because they were (at least in 3.x) defined in an awkward coordinate space for global particles, which doesn't gel well with interpolation, and this needs to be fixed first before they can be interpolated.

> I see, in that case the tooltip for the toggle should be updated as it says it interpolates the transforms of specifically physics objects.

To clarify, which tooltip is this, and what wording in particular is causing confusion?
In Project Settings/General/Physics/Common there's the toggle for Physics Interpolation, where the tooltip that appears on mousing over it says: "If true, the renderer will interpolate the transforms of physics objects between the last two transforms, so that smooth motion is seen even when physics ticks do not coincide with rendered frames."
This does not seem to at all suggest that the interpolation applies to non-physics objects, hence my confusion.
> This does not seem to at all suggest that the interpolation applies to non-physics objects, hence my confusion.

Ah you are absolutely right, this is incorrect, it was introduced in my original PR #52846 (it may have been in response to a request for change by a reviewer), I'll do a PR to fix this tooltip. 👍 

Fix patch:
diff --git a/doc/classes/ProjectSettings.xml b/doc/classes/ProjectSettings.xml
index 232fed5713f5..c1083de9ecc2 100644
--- a/doc/classes/ProjectSettings.xml
+++ b/doc/classes/ProjectSettings.xml
@@ -2383,9 +2383,10 @@
 			[b]Note:[/b] This property is only read when the project starts. To change the maximum number of simulated physics steps per frame at runtime, set [member Engine.max_physics_steps_per_frame] instead.
 		</member>
 		<member name="physics/common/physics_interpolation" type="bool" setter="" getter="" default="false">
-			If [code]true[/code], the renderer will interpolate the transforms of physics objects between the last two transforms, so that smooth motion is seen even when physics ticks do not coincide with rendered frames. See also [member Node.physics_interpolation_mode] and [method Node.reset_physics_interpolation].
-			[b]Note:[/b] If [code]true[/code], the physics jitter fix should be disabled by setting [member physics/common/physics_jitter_fix] to [code]0.0[/code].
+			If [code]true[/code], the renderer will interpolate the transforms of objects (both physics and non-physics) between the last two transforms, so that smooth motion is seen even when physics ticks do not coincide with rendered frames. See also [method Node.reset_physics_interpolation].
+			[b]Note:[/b] Although this is a global setting, finer control of individual branches of the [SceneTree] is possible using [member Node.physics_interpolation_mode].
 			[b]Note:[/b] This property is only read when the project starts. To toggle physics interpolation at runtime, set [member SceneTree.physics_interpolation] instead.
+			[b]Note:[/b] Property [member physics/common/physics_jitter_fix] is automatically disabled if [member physics/common/physics_interpolation] is set to [code]true[/code], as the two methods are incompatible.
 		</member>
 		<member name="physics/common/physics_jitter_fix" type="float" setter="" getter="" default="0.5">
 			Controls how much physics ticks are synchronized with real time. For 0 or less, the ticks are synchronized. Such values are recommended for network games, where clock synchronization matters. Higher values cause higher deviation of in-game clock and real clock, but allows smoothing out framerate jitters. The default value of 0.5 should be good enough for most; values above 2 could cause the game to react to dropped frames with a noticeable delay and are not recommended.
diff --git a/doc/classes/SceneTree.xml b/doc/classes/SceneTree.xml
index 9a31492d2018..5ae21ad138d5 100644
--- a/doc/classes/SceneTree.xml
+++ b/doc/classes/SceneTree.xml
@@ -266,8 +266,9 @@
 			- Depending on each node's [member Node.process_mode], their [method Node._process], [method Node._physics_process] and [method Node._input] callback methods may not called anymore.
 		</member>
 		<member name="physics_interpolation" type="bool" setter="set_physics_interpolation_enabled" getter="is_physics_interpolation_enabled" default="false">
-			If [code]true[/code], the renderer will interpolate the transforms of physics objects between the last two transforms, so that smooth motion is seen even when physics ticks do not coincide with rendered frames.
+			If [code]true[/code], the renderer will interpolate the transforms of objects (both physics and non-physics) between the last two transforms, so that smooth motion is seen even when physics ticks do not coincide with rendered frames.
 			The default value of this property is controlled by [member ProjectSettings.physics/common/physics_interpolation].
+			[b]Note:[/b] Although this is a global setting, finer control of individual branches of the [SceneTree] is possible using [member Node.physics_interpolation_mode].
 		</member>
 		<member name="quit_on_go_back" type="bool" setter="set_quit_on_go_back" getter="is_quit_on_go_back" default="true">
 			If [code]true[/code], the application quits automatically when navigating back (e.g. using the system "Back" button on Android).


Test patch: