Performance?

[lacasrac]

My game fps was ~120
I just added a rope, fps is ~90-95
Added a chain the same scene, fps now is ~55-60 fps

In debug build. Is it normal? 30 fps drop on a rope?

[lacasrac]

Sorry it looks like I get 120 fps in release build. 

What is the performance BTW if I put 50 or 100 rope in a scene? In release mode? Is there any limit? 

Thanks

[josemendez]

In debug build. Is it normal? 30 fps drop on a rope?

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

What is the performance BTW if I put 50 or 100 rope in a scene? In release mode? Is there any limit? 

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

[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.