28-03-2019, 06:53 PM
(This post was last modified: 28-03-2019, 06:58 PM by josemendez.)
(28-03-2019, 06:02 PM)Laura Wrote: Hello,
I have in one scene a gameobject with an obi rope. That object has a hole in the center and I grab it with the motion controller.
The idea is the rope goes through the hole and slips through it. But when I move the rope goes through the object and is released.
The object has an obi collider component and the particles of the rope are together and there are no gaps.
I attach you an image:
What should I do to keep the rope inside the hole and not get out?
I hope you can help me.
Thank you.
Laura.
Hi Laura,
There's no way to guarantee 100% the rope won't slip outside that hole under any circumstance, so keep that in mind if this is a game-critical feature. This is because time is a discrete quantity in simulations, and (given high enough velocities/tensions) particles might be inside the hole one frame, but outside of it the next frame, without having ever collided with the colliders in either frame. This is exacerbated by the fact that VR controllers aren't part of the physical simulation (they do not have linear/angular velocities). Instead they are "teleported" from frame to frame, by directly altering their transform. So, by moving the controller fast enough you can simply teleport the hole to a new position, far away from the rope, and the rope will never know that you did.
This issue is commonly called "tunneling" and is very common in all game engines.
There's two possible ways to alleviate it: add the ObiKinematicVelocities component to your controller, this will tell Obi to calculate approximate velocities for the controller so that CCD (continuous collision detection) can kick in. Another way to prevent tunneling is to advance the simulation using smaller time steps. This can be accomplished by increasing the amount of solver substeps, or by decreasing Unity's fixed timestep. Still, both approaches will only make tunneling less likely, as it cannot be completely eliminated. You should also consider limiting the effective speed at which the user can move the controller, so that you can have a upper bound on the controller velocity.
See:
http://obi.virtualmethodstudio.com/tutor...olver.html