Dynamic attached to kinematic with FixedJoint trails a frame behind when using TGS solver

[mfilkry]

Hello! If you attach a dynamic to a kinematic with a FixedJoint, and move the kinematic with setKinematicTarget before running the simulation, the dynamic will lag behind the expected position. This only occurs with the TGS solver - if using the older solver the dynamic ends up where expected after simulation.

This is an edit of the SnippetJoint sample that minimally reproduces the issue: https://gist.github.com/mfilkry/f9d0b85dce4442e4ae20686636050b9d

I am not 100% certain this is a bug, since as far as I can tell:

1. it's expected that the inertial frames for kinematics are initialized in DynamicsTGSContext::createSolverConstraints based on the kinematics' current (not target) location
2. kinematics have their velocity set to 0 before integration (keeping only "originalVelocity")
3. kinematics aren't actually updated to their KinematicTarget value until after the solver finishes running

All of which seems to imply the library would run a kinematic<->dynamic joint from the previous frame's world transform.

On the other hand, the documentation states "if you want a very stiff controller that moves the object to specific position each frame, consider jointing the object to a kinematic actor and use the setKinematicTarget function to move the actor."

If anyone could help me understand if this is a bug, if I'm doing something wrong, or if it's working as intended, I'd greatly appreciate it. Thank you.

[jcarius-nv]

Hi @mfilkry ,
thank you for reporting the issue and providing a snipped for reproduction.

The use of a kinematic + fixed joint is definitely valid and a sensible choice in your scenario. I checked in a unit tests and setting the kinematic target, even before the first call to the solver is working as expected, there is no frame delay.

I also ran your modified snippet and I think the effect you're seeing is only due to friction/damping, constraint linearization, and potentially some numerical inaccuracies, but not a frame delay. Take the following printout sequence:

kinematic tgt: 0.945065, 1.000000, -9.465534
expecteddyn: 1.917598, 0.500000, -9.698301
actualdyn: 1.922390, 0.500119, -9.676890
=======================
kinematic tgt: 0.922461, 1.000000, -9.551493
expecteddyn: 1.883691, 0.500000, -9.827239
actualdyn: 1.889430, 0.500119, -9.806063
=======================
kinematic tgt: 0.896060, 1.000000, -9.636362
expecteddyn: 1.844090, 0.500000, -9.954543
actualdyn: 1.850764, 0.500119, -9.9336429

The actualdyn of a frame is way ahead of the expectedyn of the previous frame, which implies it's not a frame-delay issue.

Looking even closer, I think you're hitting an issue related to constraint linearization, in particular the fact that angular velocity is solved only in the tangent space and your bodies are rotating quite quickly. If I change the following part of your snippet to only use linear velocity (abusing variable names a bit)

  //PxTransform rotation(PxVec3(0.0f),
  //                     PxQuat(totaltime * vel, PxVec3(0.0f, 1.0f, 0.0f)));
  PxTransform rotation(PxVec3(vel * totaltime, 0.0f, 0.0f));

the expected and actual positions actually match as desired:

kinematic tgt: 7.000015, 1.000000, -7.000000
expecteddyn: 7.000015, 0.500000, -6.000000
actualdyn: 7.000016, 0.500000, -6.000000
=======================
kinematic tgt: 7.044459, 1.000000, -7.000000
expecteddyn: 7.044459, 0.500000, -6.000000
actualdyn: 7.044459, 0.500000, -6.000000
=======================
kinematic tgt: 7.088903, 1.000000, -7.000000
expecteddyn: 7.088903, 0.500000, -6.000000
actualdyn: 7.088904, 0.500000, -6.000000

=> If you can, decrease the time step so your linearization error is smaller, but otherwise you just have to accept that the solve is not 100% accurate.

[mfilkry]

Thank you for taking the time to run the snippet and provide a detailed answer.

As a further test, I set friction and damping both to 0 on the dynamic body and did not observe a change in behaviour, but it was a good thing to eliminate.

I'm a little confused by your statement that actualdyn is ahead of the expecteddyn of the previous frame - I've updated the snippet to also show "startdyn", the position of the dynamic before simulation, which will hopefully help illustrate the trailing effect:

startdyn: 1.283238, 0.500119, -7.054398 // position of the dynamic before simulation
expecteddyn: 1.381028, 0.500000, -7.174978 // expected position of the dynamic after simulation
actualdyn: 1.367426, 0.500119, -7.157763 // position of the dynamic after simulation

The actualdyn post-simulation is trailing behind the expecteddyn (x was expected to increase, z was expected to decrease, both did so less than expected). Is that in line with what you were saying?

Also, do you have any sense of why the effect would be so much less pronounced when using the PGS solver? I must admit I have no working knowledge of the methodology of the two solvers.

Here's a similar output from PGS with the same snippet:

startdyn: 1.749042, 0.500000, -10.203617
expecteddyn: 1.691953, 0.500000, -10.324156
actualdyn: 1.692851, 0.500000, -10.324565

I also noted that when I used only linear velocity I didn't seem to notice the same effect - sorry for not including that in the original question. It does seem to support your theory. If it does come down to linearization, it seems substepping may be the answer.

Thanks again for taking the time.

[jcarius-nv]

The actualdyn post-simulation is trailing behind the expecteddyn (x was expected to increase, z was expected to decrease, both did so less than expected). Is that in line with what you were saying?

Yes, exactly. The point was that if there were a frame delay, the dynamic body would see the target (expected pose) of the previous frame. However, it exceeds that previous target by a lot, meaning it must already have knowledge about the current target, it just doesn't converge very well to it.

As to why the effect is worse for TGS than PGS -- I honestly don't really know. Probably it comes down to (one or more) relaxation factors, causing successively larger errors in the TGS iterations ("chasing a moving target") whereas PGS would use the iterations to decrease the error successively as it sees the full velocity/displacement of the kinematic from iteration 1. The linearization problem should be equal for both.

So yes, either try substepping yourself or consider replacing the fixed joint with switching the dynamic to kinematic and back once you want to release the joint.