Sorry about that faffing, I fixed the wheels to wraparound to prevent float error, and had to make some adjustments for the resets to work correctly.

Although the changes are pretty small to put in local space:

void VehicleBody::_update_process_mode() {
	set_process_internal(is_physics_interpolated_and_enabled());
}

void VehicleBody::_notification(int p_what) {

			Transform xform;
			Transform inv_vehicle_xform = get_global_transform_interpolated().affine_inverse();

			for (int i = 0; i < wheels.size(); i++) {
				VehicleWheel &w = *wheels[i];
				w.fti_data.update_world_xform(xform, f);
				w.set_transform(inv_vehicle_xform * xform);
			}

I'm still not absolutely convinced we should change this. The other approach is faster, and I am wondering if we should change if there is evidence that it causes a problem for a user (we are trying to future proof and predict ahead of time user problems, although I do take your point that it is in a sense compat breaking, even there is no standard yet for wheels with FTI).

It's also just as possible for the user to get local space by doing this calculation themselves (multiplying by inverse parent global xform) if they really needed it.

On the other hand if we do change it now, then it makes it more difficult to warrant taking it out at a later stage. 🤔

Let me know what you think, I can easily change it back.

While it's not the most common thing to access a wheel's local transform, I could imagine e.g. someone using position.z to distinguish wheels, which would quietly break if position was suddenly the global position.

Perhaps in the future wheels could be top-level by default and it could be documented that they only work as top-level. The middle ground of setting top-level dynamically would be annoying to document and understand, though the code would be more efficient.

I'll update the 4.x PR with the changes.

BTW for future reference there are several implications to local space versus global space here:

• Extra calculation when sending to server.
• Extra calculation in the scene traversal code (the scene traversal code recognises top_level)
• Could end up in a different position if a node was moved above the vehicle in the scene tree on the frame (this might be better, but is a difference)

More generally physics objects update their transforms via the global xform afaik, so to some extent multiplying by inverse parent xform is "pretending" that they are in local space, but maybe that makes it easier for users to understand. It also has implications for their interpolation "track", as interpolation takes place in local space.

Thanks!