2D physics objects have delay to their positions

[lawnjelly]

Godot version:
probably existed since 3.1
3.2.4 beta 2

OS/device including version:
All

Issue description:
This is somewhat a sister issue to #28492.
See also the discussion in #43554.

There seems to be a frame delay between a 2d physics object position being updated, and the child objects in the scene tree being updated with this position. This problem seems to be made more obvious by using the snap_transforms option.

When 2d physics object is moved by e.g. move_and_slide the physics does not update the position of the client object straight away (understandably) but updates it later, possibly in RigidBody2D::_direct_state_changed?

This updates the position of e.g. a player, but maybe not any nodes that are dependent in the scene tree, which possibly are not updated until the next tick.

This all has the effect that a player node may be moved by the physics a frame in advance of a camera which is hanging off the player, leading to a jitter caused by this one frame delay.

This jitter can be removed by manually updating a camera that is not a child of the player.. perhaps because of the order of processing. This works but can be confusing for users who want a camera to follow an object.

I can't give a full explanation of how / why it is happening as I'm not very familiar with the physics / object update order, but it is clearly problematic.

The mechanism and problems resulting are analogous to the situation when moving a node manually, rather than with physics, and are described in #28492. Note that using the workaround for force_scroll_update for the Camera does NOT cure the problem if it is a child directly of the physics object, only if it is on a separate scene tree branch.

Steps to reproduce:
Move a 2D physics object with a Camera2D as a child.

Minimal reproduction project:
(This project is an extended version of one by @CritCorsac from #43554)
Jittering Camera Physics Bug.zip

Press 'enter' to toggle the camera between one that is a child of Player, and one that is manually updated.

[Calinou]

Duplicate of godotengine/godot-proposals#1828 ?

[lawnjelly]

Duplicate of godotengine/godot-proposals#1828 ?

Related but not exactly the same I think as the key problem seems to be the ability to sync the camera with the player using force_scroll_update. In a sense a 1 frame delay wouldn't be such a problem if it were possible to sync camera and player.

I'll see if I can capture a gif to illustrate.

[lawnjelly]

Ah this may be due to the camera not being transform snapped. Will test this.

Forcing a floor to the camera in the engine does help get closer to the desired behaviour but there is still some out of sync behaviour going on between the physics and rendered result resulting in glitches.

There was some question of whether we could tie in camera snapping with the transform snapping but although it seems almost right, there is some sync problems going on. Perhaps due to the physics running in a separate thread? Or maybe a physics tick / frame sync problem.

For reference here it where the camera can be floored .. line 206 camera_2d.cpp, Camera2D::get_camera_transform():

	xform.scale_basis(zoom);
//	xform.set_origin(screen_rect.position /*.floor()*/);
	xform.set_origin(screen_rect.position.floor());

[akien-mga]

Partly fixed by #43813 according to the PR - what part is still reproducible?

[lawnjelly]

This still needs fixing, it is a general problem with camera 2ds. #43813 has some effects to decrease the problems but it is pretty much accidental, it doesn't fix the core problem.

Core problem is that currently a camera hanging off a moving node will often not have its scroll updated until the frame after the move. This causes jitter ranging from subtle, to jarring when used in combination with snapping. I'll be doing a PR in a sec to properly fix this.

[akien-mga]

Fixed by #46697.