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.

[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.