ObiRope 3.2 Crane - Prevent Rope from passing through spool

[tbookout]

In ObiRope 3.2 Crane Example Scene.  If I increase the Load RigidBody Mass from 1 to 10.
Then the rope will eventually clip through pulley, with no user input.

I was unable to prevent this.  Experimenting with generating tethers, and increasing iterations in ObiSolver (Distance, Collision, Tether).

The one solution I could make work, was reload scene then:
- Increase the Load RigidBody Mass from 1 to 10.
- Increase the Crane.Pulley RigidBody Mass from 10 to 30.
- Increase the ObiSolver.Collision.Iterations from 10 to 20.


Is there a better solution?
Is there a ratio that must be maintained between rope loads and other RigidBody masses?

[josemendez]

In ObiRope 3.2 Crane Example Scene.  If I increase the Load RigidBody Mass from 1 to 10.
Then the rope will eventually clip through pulley, with no user input.

I was unable to prevent this.  Experimenting with generating tethers, and increasing iterations in ObiSolver (Distance, Collision, Tether).

The one solution I could make work, was reload scene then:
- Increase the Load RigidBody Mass from 1 to 10.
- Increase the Crane.Pulley RigidBody Mass from 10 to 30.
- Increase the ObiSolver.Collision.Iterations from 10 to 20.


Is there a better solution?
Is there a ratio that must be maintained between rope loads and other RigidBody masses?

Possible solutions:

1.- Increase the amount of distance constraint iterations. These are what keep the rope from stretching under high loads.
2.- Create a rope with higher resolution. This reduces the gaps between particles.
3.- Increase the mass of the rope particles accordingly . This is useful if the mass ratio you're interested in maintaining is "load -vs- some other scene object", instead of "load -vs- rope".

Note that under high enough mass ratios the simulation won't be able to keep up no matter what you do. It will not explode (as Unity's PhysX does), instead will handle the situation as gracefully as possible.

No realtime general physics engine is capable of dealing with arbitrarily high mass ratios. There are particular algorithms that do (such as Featherstone), but they are limited to specific scenarios and have high performance requirements even in simple cases. This problem is usually circumvented in commercial games by establishing a maximum mass ratio between any two objects in the game, and sticking to it.

In engineering environments where you can't fake or cap mass ratios, this issue is dealt with by either increasing the amount of constraint iterations to a point where the simulation is no longer realtime, or a completely different approach is used (such as eulerian discretization instead of lagrangian, and direct solvers instead of iterative ones).

[tbookout]

Possible solutions:

1.- Increase the amount of distance constraint iterations. These are what keep the rope from stretching under high loads.
2.- Create a rope with higher resolution. This reduces the gaps between particles.
3.- Increase the mass of the rope particles accordingly . This is useful if the mass ratio you're interested in maintaining is "load -vs- some other scene object", instead of "load -vs- rope".

Note that under high enough mass ratios the simulation won't be able to keep up no matter what you do. It will not explode (as Unity's PhysX does), instead will handle the situation as gracefully as possible.

No realtime general physics engine is capable of dealing with arbitrarily high mass ratios. There are particular algorithms that do (such as Featherstone), but they are limited to specific scenarios and have high performance requirements even in simple cases. This problem is usually circumvented in commercial games by establishing a maximum mass ratio between any two objects in the game, and sticking to it.

In engineering environments where you can't fake or cap mass ratios, this issue is dealt with by either increasing the amount of constraint iterations to a point where the simulation is no longer realtime, or a completely different approach is used (such as eulerian discretization instead of lagrangian, and direct solvers instead of iterative ones).

I again started with default Crane scene, and increased Load RigidBody Mass from 1 to 10.


Solution 1
Increasingly adjusted ObiSolver distance constraint iterations up to 200.  Did not resolve the issue.
Next I generated tethers.  Set distance constraint iterations = 50, tether constraint iterations = 50.  Did not resolve the issue.


Solution 2
Increase Rope Resolution from .2 to .4
Recreated Fixed and Pinned points
Next generated tethers.   tether constraint iterations = 50.  Did not resolve the issue.
Next increased distance constraint iterations = 100.  Solved the issue.  Lower values would eventually fall through pulley.
Removed tethers, issue was still resolved.


Solution 3
Increase Particle Mass from .1 to .3.  

• Select Fixed
  
• Invert Selection
  
• Increase Mass from .1 to .3.
  

Solved the issue, as long as Pulley does not spin  
Next increased collision constraint iterations from 10 to 60.  Solved the issue.


Solution 2 & 3
Increase Rope Resolution from .2 to .4
Recreated Fixed and Pinned points
Increase Particle Mass from .1 to .3. 
Increase collision constraint iterations from 10 to 30.  
Increase distance constraint iterations from 20 to 30.  
Solved the issue.


Is there a better solution?  

I understand the concept that high mass ratios are a 'bad' thing.  I would not think 10 kg is that absurd.
By default the rope weighs 5kg.

[josemendez]

I again started with default Crane scene, and increased Load RigidBody Mass from 1 to 10.


Solution 1
Increasingly adjusted ObiSolver distance constraint iterations up to 200.  Did not resolve the issue.
Next I generated tethers.  Set distance constraint iterations = 50, tether constraint iterations = 50.  Did not resolve the issue.


Solution 2
Increase Rope Resolution from .2 to .4
Recreated Fixed and Pinned points
Next generated tethers.   tether constraint iterations = 50.  Did not resolve the issue.
Next increased distance constraint iterations = 100.  Solved the issue.  Lower values would eventually fall through pulley.
Removed tethers, issue was still resolved.


Solution 3
Increase Particle Mass from .1 to .3.  

• Select Fixed
  
• Invert Selection
  
• Increase Mass from .1 to .3.
  

Solved the issue, as long as Pulley does not spin  
Next increased collision constraint iterations from 10 to 60.  Solved the issue.


Solution 2 & 3
Increase Rope Resolution from .2 to .4
Recreated Fixed and Pinned points
Increase Particle Mass from .1 to .3. 
Increase collision constraint iterations from 10 to 30.  
Increase distance constraint iterations from 20 to 30.  
Solved the issue.


Is there a better solution?  

I understand the concept that high mass ratios are a 'bad' thing.  I would not think 10 kg is that absurd.
By default the rope weighs 5kg.

Nope, there's no general, better solution for this (not just in Obi, but in the whole realm of iterative solvers, which pretty much encompasses all realtime physics solvers). You have to either increase the amount of solver iterations or cap the mass ratios.

Try an experiment: take two cubes in unity (w/ rigidbody components) and put one on top of the other. The bottom one should weight 1 kg, the top one 100 kg. This is equivalent to having ten 10kg cubes on top of the 1kg one, as 10x10 = 100. This setup will cause both cubes to immediately start jittering and go trough each other, or cause the top cube to jump off the bottom one. The highest ratio that ensures no artifacts and little/no penetration between the cubes 1/10 (a 10kg cube on top of a 1kg cube), using the default amount of iterations used by Unity (which is 6).

The above cube-based setup is also numerically equivalent to having a 10 kg load hanging from a rope made out of ten 0.1kg particles each. You could see the behaviour is roughly the same for both systems, because both PhysX and Obi have iterative solvers at their core. They both behave in similar ways, except for the jittering behavior, to which Obi is virtually immune.

[tbookout]

Nope, there's no general, better solution for this (not just in Obi, but in the whole realm of iterative solvers, which pretty much encompasses all realtime physics solvers). You have to either increase the amount of solver iterations or cap the mass ratios.

Try an experiment: take two cubes in unity (w/ rigidbody components) and put one on top of the other. The bottom one should weight 1 kg, the top one 100 kg. This is equivalent to having ten 10kg cubes on top of the 1kg one, as 10x10 = 100. This setup will cause both cubes to immediately start jittering and go trough each other, or cause the top cube to jump off the bottom one. The highest ratio that ensures no artifacts and little/no penetration between the cubes 1/10 (a 10kg cube on top of a 1kg cube), using the default amount of iterations used by Unity (which is 6).

The above cube-based setup is also numerically equivalent to having a 10 kg load hanging from a rope made out of ten 0.1kg particles each. You could see the behaviour is roughly the same for both systems, because both PhysX and Obi have iterative solvers at their core. They both behave in similar ways, except for the jittering behavior, to which Obi is virtually immune.

Thanks for the information!

I am trying to understand the baseline rules.  In order to design scenes in Unity, that prevent the 'clipping' issue from occurring.  Without having to spend an inordinate time play-testing all the various interactions.

[josemendez]

Thanks for the information!

I am trying to understand the baseline rules.  In order to design scenes in Unity, that prevent the 'clipping' issue from occurring.  Without having to spend an inordinate time play-testing all the various interactions.

You'll develop a keen eye for this over time, but it can be hard to hit the right balance at the beginning since so many things can affect the result. That's why Obi exposes a lot of parameters, while other engines assume you'll never need to touch the defaults (true for simple scenes, not true in the general case). Actually it all boils down to two simple rules:

- The more constraints your simulation has (contacts, inter-particle distance constraints, etc) and the harder they are to satisfy, the larger the amount of iterations you'll need.

- A constraint between particles/rigidbodies with large mass ratios has higher cost than one with a smaller ratio.

So you must always strive to have few constraints and low mass ratios. This will always look better and also be faster than a system with many constraints and large mass ratios.