koobas.hobune.stream
Configurable Joints pass through colliders
I am trying to build sword physics for a VR game. I am using a Configurable Joint targeting the player's hand position so that the sword follows the player's hand position/rotation but can be deflected if pressed against a solid object or another sword, similar to what is described in this article: https://evanfletcher42.com/2018/12/29/sword-mechanics-for-vr/. In most cases this works great, but when pressing against a thin collider (such as another sword) at a certain amount of bend the sword's collider will pass through the other object. When moving the target slowly, I can see the collision beginning to fail as the colliders partially clip through each other.
I have been able to cut down the frequency that this happens by adjusting the Slerp Drive settings, but this does not eliminate the issue entirely and also brings in the side-effect of the sword being slower to follow the hand, which I would like to maintain control over. Here are the settings for my Rigidbody and Configurable Joint:
Here is my hierarchy layout, I have tried more complex setups (e.g. making the Joint a child of a kinematic Rigidbody) with no effect:
I suspect that this is a result of Configurable Joint rotation being driven by a Slerp calculation rather than Torque. I tested this theory by applying torque-based rotation (following Map-Builder's answer here: https://answers.unity.com/questions/236144/rotate-using-physics.html?page=1&pageSize=5&sort=votes, combined with another system for following position) and that worked perfectly in terms of the sword never passing through colliders but came with a host of other issues in terms of rotating towards the correct target rotation.
How can I make an object follow another object's rotation (and position) so that it doesn't clip through colliders? And what is going on with Configurable Joints? Are there some settings I missed that will make them work reliably?
Here is an image showing sword colliders clipping into each other, moving the vertical sword's target a little more to the right will cause it to pass through entirely (posted as comment because Unity Forums don't allow more than 2 image attachments).
After further investigation and talking to someone who works for Unity, this seems to be an inherent flaw in Configurable Joints. At their suggestion, I tried using Articulation Bodies (primarily designed for robotics simulations) but these have the opposite problem: they handle physics-based rotation very well, but don't like having their root position moved and will pass through colliders when moved quickly.
I ended up building my own solution and included it as a feature in my much larger open-source project. You can find the code for physics-based following here: https://github.com/Will9371/Playcraft/tree/master/Assets/ZMD/_Core/Physics/Follow%20Other and the full project here: https://github.com/Will9371/Playcraft
Here is an overview of how it works: 1. Continuously apply a force towards the target of direction times distance times an exposed multiplier. 2. Continuously apply a damping force in the opposite direction of the current Rigidbody velocity times an exposed multiplier.
3. Fine-tune the multiplier values and you have translational following. 4. Repeat the same steps with torque for rotation, but with a bit of cross-product math because Quaternions. 5. Run the rotation code on one axis and again on another axis for full alignment. 6. Wrap the above processes in a manager script for convenience.
As an aside, Hurricane VR (on the Asset Store) addresses a similar problem of creating held objects that follow a hand but don't pass through solid objects. On trying it out, it works pretty well--probably good enough--but still fails under heavy stress testing. On analyzing the code, it essentially uses fine-tuned Configurable Joints.
Hi wpetillo, thanks for sharing your solution!
Tried it out and the collision is a lot more stable now :)
But somehow the issue of passing through small colliders still persists, and tweaking the force values and damping values and the physics settings didn't really help with the issue.
After some more debugging, I suspect it could be caused by the weird contact.normal direction (video here: https://youtu.be/n_x8HfqCyAU). When the collision normal is towards the opposite direction, pass through never (or rarely?) happens. But when it is towards the other collider, it seems that the physics engine will apply force to push pass the other collider.
Wondering if you have noticed anything like this in your previous project?
Turns out this is an issue with box collider, changed to capsule collider and the collision works perfect now!!
Thanks for sharing your findings! I hadn't actually noticed that edge case yet so knowing that helps!
Having the same issue here... Did you managed to solve it?
