Deactivating the obi solver when not needed ?

[VincentAbert]

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:





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

Thank you so much for taking the time to do all of this, I think I understand what we did differently : You launch the game and then pause the solver, whereas I actually stop it in the start function of a script. (i do get the error in the sample scenes this way)

I should point out that the error goes away once i activate it once, even if I disable it again. So trying disabling it via script in the start(), and you should get the same error with attachments.

The layout thing fixed it yay, thanks.

[josemendez]

Thank you so much for taking the time to do all of this, I think I understand what we did differently : You launch the game and then pause the solver, whereas I actually stop it in the start function of a script. (i do get the error in the sample scenes this way)

Got it. The rope actor is being included in the solver, so the solver constraint network needs to be rebuilt. Since this is a time consuming process, the solver uses a "dirty" flag to signal that constraints should be rebuilt at the start of the next frame. This allows to add many actors at once without having to rebuild everything immediately after adding each one.

So what's happening is that your scripts' Start() function is called right away and disables the solver. This prevents the constraints from being rebuilt. The attachment finds that the actors are loaded in the solver, so it tries to access the constraints (that haven't been built yet, since the solver is disabled). This is what causes the out of bounds.

There's several ways to work around this, the simplest one is waiting for one frame before disabling the solver:

Code:

IEnumerator Start()
{

        yield return 0;
    solver.enabled = false;
}

That should fix it

[VincentAbert]

Got it. The rope actor is being included in the solver, so the solver constraint network needs to be rebuilt. Since this is a time consuming process, the solver uses a "dirty" flag to signal that constraints should be rebuilt at the start of the next frame. This allows to add many actors at once without having to rebuild everything immediately after adding each one.

So what's happening is that your scripts' Start() function is called right away and disables the solver. This prevents the constraints from being rebuilt. The attachment finds that the actors are loaded in the solver, so it tries to access the constraints (that haven't been built yet, since the solver is disabled). This is what causes the out of bounds.

There's several ways to work around this, the simplest one is waiting for one frame before disabling the solver:

Code:

IEnumerator Start()
{

        yield return 0;
    solver.enabled = false;
}

That should fix it

Perfect.

Have a nice day