(13-11-2018, 10:28 PM)innovine Wrote: I would just like a quick confirmation before I buy, since I didn't see this answered anywhere...  Obi Rope will work with zero-g environments, right?  Currently I am disabling the Gravity option on individual Rigidbodies, but if necessary I can also do Physics.gravity = Vector3.zero;

(16-11-2018, 11:00 AM)innovine Wrote: I have two small mass (1kg) rigidbodies, one on each end of the rope (particle mass 0.05. It seems to always come to a rest with the rope being straight, but with some angular velocity remaining. Why is the rope straight? The masses do not have any drag set on their Rigidbodies. I expect the system to bounce and twist indefinitely. Damping in the solver is set to 0. Is there some kind of internal elasticity in the rope causing it to straighten out?

If i increase the mass of the particles, the rope spawns in knots and looks very agitated, spiraling like crazy. Why is this?

(16-11-2018, 12:13 PM)josemendez Wrote: Unity recommends keeping the mass ratio under 1/10 at all times. 

(16-11-2018, 12:25 PM)innovine Wrote: Ahh, removing the bend constraints is a lot nicer now, thanks.


And where do they recommend that?

(16-11-2018, 12:32 PM)josemendez Wrote: In the official docs:

https://forum.unity.com/threads/rigidbody-mass.343761/

https://docs.unity3d.com/ScriptReference/Rigidbody-mass.html

Initially they mentioned that "You should strive to keep mass close to 0.1 and never more than 10. Large masses make physics simulation unstable.". Later they replaced it with the more correct "Different Rigidbodies with large differences in mass can make the physics simulation unstable.", as it is the mass ratio, not the mass itself what you need to keep an eye on. the mass of objects can be any value you want, as long as the ratio between two connected objects is not larger than 10: 100 and 1000, 1 and 10, 1000 and 10000, etc.

By the way this holds true for all iterative solvers (PhysX, Havok, ODE, pretty much all game physics engines in existence). It's a basic consequence of how solvers work, which is turn a consequence of how time is represented in computers (in a discrete -non continuous- way).

(16-11-2018, 12:42 PM)innovine Wrote: Isn't 0.1 - 10 a ratio of 100 though, not 10 as you keep saying? Where did you get 10 from? 
How is one supposed to implement any realistic looking physics if the masses are all wrong? Say I have a 1000kg car and it crashes into a table of small objects of 1kg. What is recommended, make apples 100kg, or make my car 10kg?

Quote:The solver can have difficulty converging well when a light object is constrained between two heavy objects. Mass ratios of higher than 10 are best avoided in such scenarios.

Quote:How is one supposed to implement any realistic looking physics if the masses are all wrong? Say I have a 1000kg car and it crashes into a table of small objects of 1kg. What is recommended, make apples 100kg, or make my car 10kg?

Fun experiment you can do in Unity: place a 100 kg box on top of a 1 kg box, then watch them dance . The heavier the top box, the wilder the result.

(16-11-2018, 01:13 PM)josemendez Wrote: This is a widely known limitation of realtime physics in general.

Yes, 0.1 - 10 is a ratio of 100, however things begin to break sooner if you have multiple bodies (and not just 2).

Excerpt from the official PhysX (UNity's physics engine) docs:
https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Joints.html



Short answer: you don't. Just set their masses closer together and/or decrease the fixed timestep to increase solver accuracy (this allows you to use larger mass ratios). Depending on what you're after that means making the car lighter or the apple heavier. Some engines give you the option of scaling the masses upon contact, so that the mass ratio is kept in a sane range. The resulting behavior is obviously non-physical, but at least it does not explode -as often-. Either way, it is not generally possible to simulate very heavy and very light objects together in realtime.

Solutions to this: use a direct solver (which are much more expensive than iterative ones both financially and performance-wise, so realtime applications avoid them), or use all kind of hacks like the above mentioned.

Fun experiment you can do in Unity: place a 100 kg box on top of a 1 kg box, then watch them dance . The heavier the top box, the wilder the result.