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

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

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

(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)

(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?

(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)

(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!

(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

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