(12-05-2021, 07:50 AM)josemendez Wrote: With no solvers/updaters in the scene ObiRigidbody.UpdateVelocities shouldn't even be called, so in theory there's no way the rigidbody velocities can be modified by Obi.
I know, that's what makes it so weird. Nonetheless, removing the ObiRigidbody components prevents the issue and the values originate from Obi classes. Weird huh?
I'll try to isolate the cause to as much as possible before sending a repro project. It seems to be triggered by specific conditions on another rigidbody, but when it occurs, ALL ObiRigidbody instances are affected and given values like (0.0, 0.0, NaN) for linearDelta and (1006847000000000.0, 0.0, 0.0) for angularDelta.
In the mean time, I'll also try to narrow down the source of the scrambled values coming in. I'm guessing it is interpreting junk data stored in a static class that isn't cleared between sessions, somehow. It doesn't make sense to me either.
I think I might have narrowed down the issue somewhat.
In my case, I am creating a "global" solver, accessible through a static class, which all rope instances assign themselves to. This is to ensure that all actors can mutually collide.
When it is needed (I modified the code to check if a given actor has a solver parent, and if not, uses the global solver), a check occurs to see if a global solver exists already. If not, it will instantiate a solver prefab from the resources folder. The solver's game object is marked as "DontSave" and "DontDestroyOnLoad", as to prevent it from needlessly regenerating on scene switches. However, if my understanding is correct, it should destroy itself between play sessions, as it only gets created during play sessions.
It looks like after a session in which a rope is instantiated (and thus, the global solver is created), the first global solver and its updater stick around between play sessions. It seems to remember which ObiRigidbodies it had previously encountered (which would be all of them that existed at the time, I presume) and even retains their associated native arrays for velocities and such. But now, they're pointing to repurposed locations in memory that are now filled with data that gets misinterpreted as insane float values. So the next time this ghost solver re-awakens and encounters rigidbodies it saw before, it'll apply this junk data to them immediately.
This could be an issue with Unity's DontDestroyOnLoad or my interpretation of how it works. Nevertheless, it is strange that so much of its state persists between play sessions if it is erroneously kept alive between play sessions, despite the assemblies being reloaded when the play button is depressed, as documented here: https://docs.unity3d.com/ScriptReference...eload.html
Another thing to note is that, if it is surviving between play sessions, the object is not showing in the hierarchy after exiting a play session. (It is not marked as "Hide".)
While this may be a very specific set of circumstances, it might be worth investigating why these native arrays persist and let you read from - or even worse, write to - these bad memory addresses.
I'll investigate this further tomorrow and get a demo project ready to send.
P.S.: Apologies for my harsh initial statement, it was not meant to imply that ObiRope is virtually unusuable outright, just under the circumstances I was presented with. It was a bit of a shock to see such a critical problem occur so consistently immediately after upgrading though, and having a shared global solver seemed like an innocent design choice.