Hi!
We are developing the Boxing simulator and in some situations there is an explosion of the character.
In additional file we have a video with this error and a track from PhysX Visual Debugger showing the problem.
Please, pay attention at video from 47 sec and the relevant part of debugger track from 2572 to 2661 frames.
Also there are model, skeleton and physical asset.
[debugger track + model][1]
[full video][2]
[short video preview (at youtube)][4]
the video is 17 seconds long, but you tell to look at 47th second
You can get full video by link above image
Looking at the values coming into the solver, the problem looks like it might be caused by a sudden jump in the animation source data. It looks like possibly an error in the target quaternions for the kinematic body that the arm follows.
In frame 2580, the target pose is as follows: <0.3461 -0.6371 0.2457 0.6434> <125.4 -164.6 218.4>
In frame 2581, the target pose is : <0.5718 -0.453 0.4791 0.4882> <134 -160.5 217.2>
In frame 2582, the target pose is: <0.332 -0.6372 0.2423 0.6519> <125.6 -164 218.2>
In frame 2583, the target pose is <0.3177 -0.6368 0.2391 0.6606> <125.9 -163.2 218>
As you can see, the target provided in frame 2581 is not consistent with the other poses and this leads to a massive velocity being introduced into the system which causes the arm to pull itself apart and take a few frames to recover. The reason is that the kinematic hand has a target velocity of over 48 rads/s and a target linear velocity of over 600 units/s, while the velocities in all other frames are significantly smaller.
These kinds of discontinuities are difficult for rigid body solvers to solve. The newer TGS solver in PhysX 4.x should be a lot more robust to these kinds of large angular velocities/discontinuities, but the solver that is in PhysX 3.4 uses linear approximations to solve joints that don’t work perfectly when there are large angular velocities or large time-steps involved.
For this particular case, there’s a good chance that you will be able to resolve the issue by identifying and removing the one-frame outlying target pose in the animation.
You may also find that you get better results by simulating the physics at smaller time-steps, using fewer solver iterations and avoid using variable time-stepping, which is the default in UE4.
You are currently using 255 position and 255 velocity iterations, simulated at variable time-steps that seem to vary between 1/60 and 1/30s. You may find that something like 16 positional iterations + 1 velocity iteration at either 120 or 240hz may produce more robust results for you. In this case, you would potentially simulate multiple physics steps for each rendered step but, as each step uses fewer iterations, the performance cost of simulating multiple steps per frame should hopefully not damage frame rates.
At the very least, you should consider using fixed physics time-steps rather than variable time-steps because this should give you much more reliable and reproducible simulation behaviour.
