Kinematic Target is applied one frame delayed

[fredUmlaut]

PxRigidDynamic->setKinematicTarget applies the target transform one frame delayed.

Reproduction:
Create a Kinematic Body at position 0,0,0 and enable visualizations.
Call SetKinematicTarget with position 1,0,0 and run the simulation.
Observe the the debug visualization. It will show that the body for this simulation frame is still at 0,0,0.
Only if you advance the simulation again, the body will move to 1,0,0.

After looking through the source it may happen because of the below reasoning in the comment:
File: ScBodySim.cpp
void BodySim::calculateKinematicVelocity(PxReal oneOverDt) We have to do this like so in a delayed way, because when the user sets the target pos the dt is not yet known.

As a static physics deltatime is used in many games, a solution would be to add a flag
to Kinematic Bodies, which would force the velocity and position update when calling setKinematicTarget()
by using the previous or a given deltatime.

[preist-nvidia]

It sounds like the debug visualization is not updated after the first step, i.e. only at the beginning of the step, maybe?

Kinematic actors are expected to not attain the kinematic target immediately, but only at the end of the next simulation step. So this snippet:

  kinematic->setRigidBodyFlag(PxRigidBodyFlag::eKINEMATIC, true);
  kinematic->setGlobalPose(PxTransform(PxVec3(0.0f, 0.0f, 0.0f)));
  kinematic->setKinematicTarget(PxTransform(PxVec3(1.0f, 0.0f, 0.0f)));
  printf("pos = %f %f %f\n", kinematic->getGlobalPose().p.x, kinematic->getGlobalPose().p.y, kinematic->getGlobalPose().p.z);
  gScene->simulate(1.0f/60.0f);
  gScene->fetchResults(true);
  printf("pos = %f %f %f\n", kinematic->getGlobalPose().p.x, kinematic->getGlobalPose().p.y, kinematic->getGlobalPose().p.z);

will print:

  pos = 0.000000 0.000000 0.000000
  pos = 1.000000 0.000000 0.000000

You can teleport the kinematic any time by calling setGlobalPose. See also the caveat in the docs about kinematics: https://nvidia-omniverse.github.io/PhysX/physx/5.1.0/docs/RigidBodyDynamics.html#kinematic-actors

[fredUmlaut]

First of all, thanks a lot for your reply and for the amazing Physx5 release.

Kinematic actors are expected to not attain the kinematic target immediately, but only at the end of the next simulation step.

Is there a benefit for the user in doing so? It seems for me rather like an oversight, especially when
comparing to "Bullet" and "Jolt Physics" which both apply the Kinematic Target prior to the simulation.

When applying the Kinematic target one frame delayed, then you are no more synced with the games 3d animations that drive
these Kinematic Bodies. Every physics response is one frame delayed and so the animated Kinematic meshes/bodies clip into dynamic bodies that should get pushed away in sync.

You can teleport the kinematic any time by calling setGlobalPose.

This works nicely to remove the one frame delay but breaks collision response because the Linear and Angular Velocity
doesn't get calculated.

If you could supply a setGlobalPose method that allows to specify linear and angular velocity then this would also be a solution to this issue.

[preist-nvidia]

Is there a benefit for the user in doing so?

Yes, we infer the velocity of the kinematic from the current pose and the kinematic target, and use this velocity for interactions with dynamics.

When applying the Kinematic target one frame delayed, then you are no more synced with the games 3d animations that drive these Kinematic Bodies.

Is that not a matter of just delaying the animation too?

If you could supply a setGlobalPose method that allows to specify linear and angular velocity then this would also be a solution to this issue.

Given that we compute the kinematics' velocities from current and target pose, it does not make sense to supply velocities.

[fredUmlaut]

Is there a benefit for the user in doing so?
Yes, we infer the velocity of the kinematic from the current pose and the kinematic target, and use this velocity for interactions with dynamics.

My question was if there is a benefit to do so with one frame delay. You can infer the velocity before doing the simulation
without introducing any unneeded delay.

Is that not a matter of just delaying the animation too?

That's a possible solution to workaround the delay, tho for most games you try hard
to eliminate all causes of unneeded delay (especially VR).

[amoravanszky]

Hey Fred,

these kinds of behavior details are important. Its hard to argue that the current approach is wrong given that as far as I can remember kinematics in PhysX have always worked like this, and its the way all kinematic PhysX in e.g. Unity and Unreal works, so it has been very broadly used and we haven't had any big complaints.

That is not to say that the behavior you ask for is necessarily less valid. I suggest you try to implement this alternate behavior with a flag like you suggest yourself, provide a PR and see if anyone else prefers it -- after all that is what the source is for.

[preist-nvidia]

Converted this to a discussion item.

[fredUmlaut]

Hi Adam,

thanks for your reply. I see of course the need to provide the current delayed behavior as default.

I suggest you try to implement this alternate behavior with a flag like you suggest yourself, provide a PR and see if anyone else prefers it -- after all that is what the source is for.

I tried but failed as I seem to miss more knowledge about the internal locking stages of PHYSX.

From my view this would be the needed changes:

Add scene flag

1. eUPDATE_KINEMATICS_PRIOR_SIM = (1 << 18)
2. If Flag is set then call "mScene.integrateKinematicPose()" from "void Sc::Scene::preIntegrate(PxBaseTask* continuation)"
3. If Flag is set then don't call "mScene.integrateKinematicPose()" from "Sc::Scene::postSolver"

The proposed minimal change will make it much easier to move from 'JOLT' or 'BULLET Physics' to PHYSX.
and will remove unnecessary lag for VR and other games.