Obi Official Forum

Hello,

Let's say I have a level which only features ropes in one or two rooms. Trying to mitigate all my performance overhead, I would like to disable simulation when not needed, what is the best way to do that ?
I tried disabling the updater and solver, and activating them when the player enters a trigger, but it causes a lag spike, probably because of some initialization. What would be the best way to go about this ?

Thank you,

Vincent.

(13-05-2021, 01:07 PM)VincentAbert Wrote: [ -> ]Hello,

Let's say I have a level which only features ropes in one or two rooms. Trying to mitigate all my performance overhead, I would like to disable simulation when not needed, what is the best way to do that ?
I tried disabling the updater and solver, and activating them when the player enters a trigger, but it causes a lag spike, probably because of some initialization. What would be the best way to go about this ?

Thank you,

Vincent.

Hi Vincent,

Disabling the solver would be the best option. This is what the solver does internally when you uncheck "Simulate when invisible": it disables itself when outside of any camera frustum, and re-enables when it is visible.

There should not be much of a spike when disabling/enabling the solver (could not reproduce any spikes in any of our test scenes at least), disabling a solver just stops calling its internal update methods. No initialization or data juggling takes place when enabling/disabling. Could you share a profiler screen capture of said spikes?

Note that if you are using the Burst backend, async JIT compilation is enabled by default in-editor, which means that all jobs will be compiled at runtime when first called. This will result in a large spike when enabling a solver for the first time. You can disable this in Unity's Burst menu. Also, it's disabled in builds.

(13-05-2021, 01:27 PM)josemendez Wrote: [ -> ]Hi Vincent,

Disabling the solver would be the best option. This is what the solver does internally when you uncheck "Simulate when invisible": it disables itself when outside of any camera frustum, and re-enables when it is visible.

There should not be much of a spike when disabling/enabling the solver (could not reproduce any spikes in any of our test scenes at least), disabling a solver just stops calling its internal update methods. No initialization or data juggling takes place when enabling/disabling. Could you share a profiler screen capture of said spikes?

Note that if you are using the Burst backend, async JIT compilation is enabled by default in-editor, which means that all jobs will be compiled at runtime when first called. This will result in a large spike when enabling a solver for the first time. You can disable this in Unity's Burst menu. Also, it's disabled in builds.

Thank you for your answer !

So I just gave it a try, here is the profiler with Burst,



And with Oni (which seems much slower somehow ?)




This is in-editor, I'll update you with a build test. By the way here I am disabling the solver Gameobject (so also the ropes that are its children, as well as obi colliders), I was not sure wether you meant the script or the gameobject.

Thanks you

Hi,

You should only disable the ObiSolver component. This stops the simulation, keeping all data in place.

If you disable the entire gameobject, then all actors will be disabled too, and all their data (particle positions, velocities, etc) will be removed from the solver.
When you re-enable it, all this data has to be copied back and the actors re-added to the solver, which is considerably more costly.

(13-05-2021, 03:03 PM)josemendez Wrote: [ -> ]Hi,

You should only disable the ObiSolver component. This stops the simulation, keeping all data in place.

If you disable the entire gameobject, then all actors will be disabled too, all their data (particle positions, velocities, etc) removed from the solver.
Then, this data has to be copied and the actors re-added when you enable it all again, which is considerably more costly.

Haha you're so fast, I wanted to edit my post because just after sending it I decided to try the component... So it's indeed much better, I do get an error though :

ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <695d1cc93cca45069c528c15c9fdd749>:0)
System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <695d1cc93cca45069c528c15c9fdd749>:0)
Obi.ObiParticleAttachment.BreakDynamicAttachment (System.Single stepTime) (at Assets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:512)
Obi.ObiParticleAttachment.Actor_OnEndStep (Obi.ObiActor act, System.Single stepTime) (at Assets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:217)
Obi.ObiActor.EndStep (System.Single substepTime) (at Assets/Obi/Scripts/Common/Actors/ObiActor.cs:1161)
Obi.ObiSolver.EndStep (System.Single substepTime) (at Assets/Obi/Scripts/Common/Solver/ObiSolver.cs:1592)
Obi.ObiUpdater.EndStep (System.Single substepDeltaTime) (at Assets/Obi/Scripts/Common/Updaters/ObiUpdater.cs:92)
Obi.ObiFixedUpdater.FixedUpdate () (at Assets/Obi/Scripts/Common/Updaters/ObiFixedUpdater.cs:52)

(13-05-2021, 03:07 PM)VincentAbert Wrote: [ -> ]Haha you're so fast, I wanted to edit my post because just after sending it I decided to try the component... So it's indeed much better, I do get an error though :

ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <695d1cc93cca45069c528c15c9fdd749>:0)
System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <695d1cc93cca45069c528c15c9fdd749>:0)
Obi.ObiParticleAttachment.BreakDynamicAttachment (System.Single stepTime) (at Assets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:512)
Obi.ObiParticleAttachment.Actor_OnEndStep (Obi.ObiActor act, System.Single stepTime) (at Assets/Obi/Scripts/Common/Utils/ObiParticleAttachment.cs:217)
Obi.ObiActor.EndStep (System.Single substepTime) (at Assets/Obi/Scripts/Common/Actors/ObiActor.cs:1161)
Obi.ObiSolver.EndStep (System.Single substepTime) (at Assets/Obi/Scripts/Common/Solver/ObiSolver.cs:1592)
Obi.ObiUpdater.EndStep (System.Single substepDeltaTime) (at Assets/Obi/Scripts/Common/Updaters/ObiUpdater.cs:92)
Obi.ObiFixedUpdater.FixedUpdate () (at Assets/Obi/Scripts/Common/Updaters/ObiFixedUpdater.cs:52)

Hi Vincent,

Can’t reproduce this, but fixed a similar bug a few versions back. What Obi version are you using?

(13-05-2021, 03:17 PM)josemendez Wrote: [ -> ]Hi Vincent,

Can’t reproduce this, but fixed a similar bug a few versions back. What Obi version are you using?

6.0.1 (as far as I can tell, that's the latest version that's in the changelog file in the obi folder)

(13-05-2021, 03:19 PM)VincentAbert Wrote: [ -> ]6.0.1 (as far as I can tell, that's the latest version that's in the changelog file in the obi folder)

That's the the latest one indeed. However I'm unable to reproduce this by deactivating the solver. Doing so changes nothing regarding data layout, it literally just stops calling the update method. So in theory there's no reason for it to fail.

Been testing in the freight lift sample scene, the crane scene, and a custom scene with many dynamic attachments to no avail. If you could share a scene/project that reproduces this, I'd be glad to take a look. If possible, send it to support(at)virtualmethodstudio.com.

thanks!

(14-05-2021, 08:03 AM)josemendez Wrote: [ -> ]That's the the latest one indeed. However I'm unable to reproduce this by deactivating the solver. Doing so changes nothing regarding data layout, it literally just stops calling the update method. So in theory there's no reason for it to fail.

Been testing in the freight lift sample scene, the crane scene, and a custom scene with many dynamic attachments to no avail. If you could share a scene/project that reproduces this, I'd be glad to take a look. If possible, send it to support(at)virtualmethodstudio.com.

thanks!

Hi,

I took the time to do some testing, and I think I found the culprit : it's the attachement. I have a dynamic one at each end of my rope, and if I remove them, no error. So you should be able to repro that, and hopefully fix it

Just noticed something else though : I can't edit the ropes in editor anymore, when I click edit the main rope movement gizmo disappears, but the usual rope editing UI doesn't show up... I'm using 2020.3.6, and I'm updating right to 2020.3.8 now to see if it's a unity bug that's been fixed.

Have a nice day.

(14-05-2021, 11:02 AM)VincentAbert Wrote: [ -> ]Hi,

I took the time to do some testing, and I think I found the culprit : it's the attachement. I have a dynamic one at each end of my rope, and if I remove them, no error. So you should be able to repro that, and hopefully fix it

Nope, can't reproduce :/. The Crane sample scene also has one dynamic attachment, and the FrightLift scene has 4, neither of them trigger this error. Also tried other scenes done specifically for this, but no luck. As I mentioned, disabling the solver simply stops updating the simulation, but the data layout is untouched. An out of bounds exception in this case doesn't make any sense to me, there must be something else going on that's triggering this. Here's a video of me testing it:

(14-05-2021, 11:02 AM)VincentAbert Wrote: [ -> ]Just noticed something else though : I can't edit the ropes in editor anymore, when I click edit the main rope movement gizmo disappears, but the usual rope editing UI doesn't show up... I'm using 2020.3.6, and I'm updating right to 2020.3.8 now to see if it's a unity bug that's been fixed.

Make sure there's no inspectors in debug mode. In debug mode, Unity won't draw scene view windows (such as, but not limited to, the rope path editor). Easiest way to ensure this is to revert to the default layout (Window->Layouts->Revert factory settings).