27-08-2023, 10:46 PM
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. 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. I've tried to do all the steps listed in the manual, i.e. enabling Burst compilation and disabling jobs debugger, safety checks and leak detection, but I didn't notice any big change in performance. I'm using 1.8.4 version of Burst package, 1.2.6 version of Mathematics and 2.1.4 version of Collections, on Unity 2022.3.0f1.
Is there a way to employ all the worker threads more, so the calculations in the steps can be done more efficiently, or maybe I've missed some steps in the setup and that causes this issues? I managed to cut some of the calculations, so the simulation runs a little bit faster, but I hope that there is still some room for improvement. I would be really grateful for your help.
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. 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. I've tried to do all the steps listed in the manual, i.e. enabling Burst compilation and disabling jobs debugger, safety checks and leak detection, but I didn't notice any big change in performance. I'm using 1.8.4 version of Burst package, 1.2.6 version of Mathematics and 2.1.4 version of Collections, on Unity 2022.3.0f1.
Is there a way to employ all the worker threads more, so the calculations in the steps can be done more efficiently, or maybe I've missed some steps in the setup and that causes this issues? I managed to cut some of the calculations, so the simulation runs a little bit faster, but I hope that there is still some room for improvement. I would be really grateful for your help.