Help Concerns about performance

[josemendez]

Hi!

I've successfully used Obi Rope in my project, and I am very satisfied with how it works. However, I'm still a little concerned about the performance, and I hope that it can be somehow improved.

For context, my project has an ObiFixedUpdater with 3 substeps and 3 attached solvers. Each solver has 8 ObiRods, they're 0.6m long with resolution of 0.2 and have two static and two dynamic attachments. All the collisions are disabled, the only constrains enabled in solvers are pin, stretch&shear and bend&twist with sequential evaluation and 1 iteration. The rods use ObiRopeExtrudedRenderer with ObiPathSmoother with smoothing set to 1.

What worries me are the long durations of BeginStep in FixedUpdate and Interpolate in Update.

Hi!

BeginStep() performs basic solver bookkeeping such as keeping collider data up to date and Interpolate() performs rope mesh generation by extruding a section along the rope's path. Neither process can be parallelized since:

A) Most bookkeeping must be done on the main thread, due to Unity's API calls that can't be called from any other thread.

B) ObiRopeExtrudedRenderer uses parallel transport to propagate a frame along the rope's path. Despite its name, this is an inherently sequential algorithm, since each step's input is the output of the previous step. In your case, you might benefit from using either a simpler ObiRopeSection asset (with fewer segments) or a ObiRopeLineRenderer to cut on the amount of geometry dealt with during mesh generation. See the "RopeNet" sample scene for an example of using ObiRopeLineRenderer together with a normal map to draw many ropes efficiently.

Also, I'm wondering if it should work that way, that the Substep worker threads are barely used in parallel, and are idle most of the time. The most interesting part is that in build the durations of this processes under same conditions can get even 2 times longer.

Substeps perform the actual physics simulation. In your case though, since there's no collision detection, ropes are very low resolution and there's only 1 constraint iteration, there's barely any work to do for the worker threads and most of the time is spent scheduling jobs.

Is there a way to employ all the worker threads more, so the calculations in the steps can be done more efficiently

No, to employ worker threads you need tasks that can be done in parallel. Except for bend/twist and stretch/shear constraints (of which there's few since your ropes are low-resolution), there's no parallel work to do in your case.

Your main bottleneck right now is mesh generation in Interpolate(). You can speed this up by using a simpler rendering method, as suggested above.

kind regards,