Performance issues

[josemendez]

[*]Pin constraints are rarely properly resolved and almost always leaves a gap between the pinned body and the rope.

Change constraint enforcement order, so that pin constraints are resolved last. See the last bit of:
http://obi.virtualmethodstudio.com/tutor...olver.html

Distance constraints are not really properly enforced either unless you set the iteration count to something ridiculously high. I want the cord to behave less like a rubber band and more like a proper cord.

You can reduce the timestep in Unity's time settings. This will cause the simulation to take smaller temporal steps, and will be much more effective than increasing iteration count.

We are using NewtonVR to handle interactions, which works through applying physical forces to objects to keep them near the hand. To prevent ObiRope from pulling the plugs out of their position in your hand, we'd set the ObiRigidbody to kinematic whenever it was held, but this also creates issues since it's often unclear when an object should stop being kinematic - for instance, i noticed that objects behave much better when hung on the wall (with a fixed joint) if it is set to kinematicForParticles, because otherwise you'd get the gap between the cord an the object as a result of pin constraints not converging. Generally, everything just started acting much better when we just set all the ObiRigidbodies to kinematic.

As pointed out the gap is not a result of convergence issues, but constraint application order. By default pin constraints are applied before distance constraints, which makes the latter prevalent in the final result. Reversing the order gives priority to pin constraints and closes the gap since pin constraints are applied last and their actions are not "undone" by distance constraints.

The resolution of the rope actually affects how much it bends (ugh), and having too low resolution will result in the cords passing through tables and other flat surfaces. The poor convergence of the distance constraint also means that the distance between the particles easily grows when you are holding one end.

This cannot be worked around as it is a result of how iterative physics solvers work: more resolution->more constraints->slower convergence->less bending resistance. You can increase the amount of bending constraints to compensate the higher resolution, though.

Objects that are marked as kinematicForParticles will cause the rope to be unable to perform two-way interaction with them, effectively making ropes "passive", which is something I don't think you want.

I will take a deeper look at the crash, but a first quick look suggests a energy feedback loop somewhere. This would cause a rigidbody to store up energy and "launch" itself incredibly far and fast. This is typical of local-space simulations being performed on the local space of a rigidbody that is in turn affected by the simulation, as this causes the reference frame for the sim to change as a result of the simulation itself. Having a deeper understanding of your hanging wall rope setup would help a lot though, as this can be very hard to reproduce.

Also, i ran some deep profiling, and apparently the mesh updating stands for almost all of it, and takes 40-50 ms.

Keep in mind that every vertex in every rope is being recalculated from scratch every frame, plus normals, tangents and uvs, after being smoothed out using bezier splines. Depending on your rope "smoothness" parameter this can be a lot of work. Try switching to line rendering mode and see if that helps, that will reduce the poly count a lot. You can still use normal maps to make a line-rendered rope look 3D.

Here's a manual page on particle scripting:
http://obi.virtualmethodstudio.com/tutor...icles.html

Another one on collision callbacks in case you need them:
http://obi.virtualmethodstudio.com/tutor...sions.html