MixedRealityToolkit-Unity
MixedRealityToolkit-Unity copied to clipboard
Revised Rigidbody interaction
Overview
Improve physical interaction with Rigidbody in ObjectManipulator:
- apply forces in FixedUpdate() rather than Update() function
- implement physically correct critically dampened spring force, parameterized by
moveReactionTime
(i.e. oscillation period) andmoveDampingRatio
rather than ill-definedmoveLerpTime
- introduce optional
applyTorque
, resulting in a free rotation when switched off (more configurable angular constraints yet to be implemented)
Verification
This should be tried out manually in various contexts. The change is rather fundamental, but the new default behavior should hopefully feel at least as good in all cases and better in many and the configuration options should be more flexible and more intuitive.
As a reviewer, it is possible to check out this change locally by using the following commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch
Thanks so much for this @NorbertNemec, we really appreciate this.
@NorbertNemec , looking forward to getting this in soon! Any chance you could take a peek at Kurtis' notes?
@NorbertNemec , looking forward to getting this in soon! Any chance you could take a peek at Kurtis' notes?
@Zee2 - I just resolved the final command. From my side the change is finished. I did all the testing I could think of. Is anything else missing to get this merged?
@NorbertNemec thanks so much! (and welcome back!) I'll be verifying this myself this week and hopefully I can get it in then.
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
Hey @NorbertNemec , I don't have permissions to push to this branch. Locally, I have a resolution for the merge conflict; I also have a change for ensuring scale smoothing is still applied even in physics mode. In addition, here's some observations:
- The force softness doesn't seem to scale with the mass of the object, so light objects are very jittery and heavy objects can't be moved at all
- While "realistic", it would be nice to scale the force of the interaction with the mass of the object so you get equivalently springed/damped interactions for both light and heavy objects
- Torque doesn't match main spring force softness
- Rotating an object around in my hand always seems damp-ier than the position spring, for any given softness. I see that it uses the rotateLerpTime, but would there be a way to base it on the spring values + the angular momentum/tensor of the object?
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
This is an issue; the inspector says that Smoothing is not used for physics interactions, but it definitely still should be/needs to be. The scale of the object is assigned directly, even in Physics mode, and right now it's completely unsmoothed which feels pretty nasty. Is there a way you can compute the scale of the object in Physics mode that roughly approximates the spring of the position/rotation?
Also, the torque still seems way softer than the main spring to me... It's probably just a subjective thing, but maybe a way to make this designer-tunable would be nice, if this isn't an actual bug. (i.e., this might be mathematically correct, but it doesn't feel design-correct)
https://user-images.githubusercontent.com/5544935/197629585-aff10e71-f403-4642-a104-8a977218709b.mp4
Thanks, @Zee2!
I pushed a commit restoring the classic smoothing for scale changes. I don't quite see how to apply the concept of physical spring forces to the scale factor, so I think that algorithm is as good as anything I could come up with.
The UseForcesForNearInteraction is also gone and I removed the hardcoded choice for referenceFrameTransform
which proved problematic when controlling the MRTK demo scene with the mouse pointer. That last feature is very specific to the use case of a FPS-style character controller which is not part of MRTK, so I'll add that in our own derived class.
The remaining issue is that of Torque vs linear spring:
Watching your video, and reproducing the issue at softness=0.5, I understand your subjective impression. However, looking closely, I believe the difference really originates from the difference in the movement: In the lateral case, the hand is doing a smooth sine-like movement. The rotation, however, is a rather abrupt moment that shows the spring smoothing effect much clearer. I am not sure whether this difference is fundamental for real-world scenarios or only shows up in this very specific test.
Doing abrupt rotation seems somewhat more natural than abrupt side-by-side movement, but I have a hard time understanding how general that is.
In any case: splitting the softness into two parameters was easy and clear enough, so I did that. Feel free to experiment whether that improves the situation. For the current default of 0.1, I don't personally see the difference, so I wouldn't touch that, but I'm open to other opinions.
Wow, this recent iteration feels excellent!
/azp run
Comment was made before the most recent commit for PR 11032 in repo microsoft/MixedRealityToolkit-Unity
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).
/azp run
Azure Pipelines successfully started running 1 pipeline(s).