Performance?

[lacasrac]

Well, that's the thing with debug builds: they insert extra debug code and measurements in your build, making them *extra* slow (specially if they have support for deep profiling enabled). This is completely normal and to be expected. Any code you build in debug mode using any existing compiler will be considerably slower than the release version.

Don't measure absolute performance in a debug build, ever. They are only useful for relative performance (comparing two different builds, identifying bottlenecks, etc.) and debugging. This applies to anything done in Unity or other engines.

Also in-editor, if you're using the Burst backend: make sure that you don't have the jobs debugger and safety checks enabled. This will considerably degrade in-editor performance. Again this applies to any Burst code in Unity, not just Obi. See the manual for details:

http://obi.virtualmethodstudio.com/manua...kends.html


Performance does not depend on the number of ropes at all. You could have a slow simulation with just 5 ropes, or a lightning fast one with 100 ropes. At runtime, Obi does not really know -or care- what a "rope" is: it just puts all particles from all your ropes into an array and simulates them all using multiple threads. Remember that Obi is a particle-based engine.

So performance depends on the amount of particles in your scene, your rendering settings, and your simulation settings (specially, substeps and iterations). The manual contains a pretty in-depth explanation about how the engine works internally, and how substeps/iterations affect the results:
http://obi.virtualmethodstudio.com/manua...gence.html

let me know if I can be of further help

Thank you very much! Great support.