Performance issues

[josemendez]

Unfortunately, the part about constraint enforcement order is simply not true, at least not from my testing. For instance, i have a case where i want a rope to stay tense when attached between a series of points, but despite having the distance constraint solver last, with 15 iterations, and having the slack/stretching scales set to extremes, i still can't get it to tensen. I f i set the SOR factor to 1.5, it gets closer, but the whole cord starts to twitch and spin. Here is a picture of what i mean:



Setting the pin constraint last seems to work for simple two-ended ropes, but if you make something more complex there are no guarantees, especially not when working with VR where very large forces may be applied in order to force the object into your hand.  

My wall setup looks like this:



Basically, it is a rigidbody for each plug, with kinematic ObiRigidbodies and configurable joints with distance limits to tie them together. The top plug is attached into the air with a fixed joint with no target. The wall has an ObiCollider. It starts off all and well, and usually has time to comes to rest, but sooner or later it will cause a crash - often when one of the plugs collide with the wall (for instance if you grab one and drop it like a pendulum). The cord otherwise works fine if you're just holding it in your hand. 

I tried implementing the same cord multiple times with Obi constraints, but it just becomes too springy and never comes fully to rest. There are other somewhat infuriating aspects of working with ObiRopes which makes me want to stick to regular joints, like the fact that ropes inside a prefab will revert all non-applied changes when you press play, and the fact that you have to re-initialize the rope, thus being forced to re-do all the pin constraints, whenever you want to adjust the curve... i've been trying to make this work since September last year and the moment i accepted the compromise of using configurable joints, everything started acting much more like i wanted. Sorry if i come across as rude, i really do think this is a good product (especially for the price), and i appreciate your support, so far i've tried three different physics engines and this is the one which produces the most stable results. Still, it responds very poorly to the way you configure it.

I see some fundamental conceptual voids here: you cannot get a 100% tense chain of constraints in Obi, or in any existing engine for that matter. This is due to the way game physics engines work: given a problem, they try to get closer to the solution with every iteration, but they will never actually converge to the 100% accurate solution. In case of ropes/chains/etc, that means they cannot be completely rigid under any circumstance. You'd have to switch over to a different kind of specialized solver (ABA, eulerian segments, lemke, etc), losing a lot of flexibility/generality and performance in the process.

Try setting Unity's timestep to 0.01 or lower. This will reduce the need for higher iteration counts and make your ropes tenser.

Setting high SOR values is expected to cause instabilities, as it is a non-physical trick to give an extra "oomph" to each iteration at the cost of stability (as stated in the manual).

Constraint enforcement order will not cause the rope to become tenser, or affect its behavior in any way: it will only make sure the constraint that is solved last remains solved at the end of the frame. E.g: if you have both collision and pin constraints active, and you pin a particle to be inside a collider, there's two possible outcomes:

- The collision constraint "wins", and the particle is rendered outside of the collider.  (pin constraints solved first)
- The pin constraint "wins", and the particle is rendered inside of the collider. (pin constraints solved last)

Setting pin constraints to be enforced last will make the pinned particles stay very close to their pin location instead of leaving a gap due to distance/collision constraints fighting them, but that's it. The rope will not become tenser as a result.

The biggest issue I see in your setup now that I understand it a bit better is that imho you're misusing pin constraints. Pin constraints are meant to enable two-way coupling between non-kinematic rigidbodies and rope particles. That is, they cause the rigidbodies to react to the rope and viceversa. If your rigidbodies are completely kinematic, you're wasting away performance and stability by using them since there's no coupling to be done. You will get much better results by simply placing handles along your rope and parent them directly to the rigidbodies. This way the rope will follow them perfectly, as no simulation at all is performed -or needed- to keep the ropes attached to kinematic rigidbodies. This is also more performant than using pin constraints. See:
http://obi.virtualmethodstudio.com/tutor...ments.html