Bug / Crash Obi adding huge forces to rigidbodies when you delete ropes... (Repro project)

[josemendez]

The global solver prefab gets instantiated with an identity transformation (pos 0,0,0, rotation 0,0,0,1, scale 1,1,1) and doesn't move, so I dunno if it'd actually show up as an issue. BUT, I could look at modifying the code to work when those assumptions can't be applied.

Also, do you think fixing this issue would also fix some of the side effects of the DontDestroyOnLoad() problem mentioned in the other post?

Been trying to reproduce the DontDestroyOnLoad() issue, but I'm only able to in your project. The "standard" Obi does not exhibit this, so I'm guessing this could be related to the issue.

Are there any other places in the code where a similar issue will take place?

Lots of places in Obi assume actors are children of solvers, since it's designed to work that way. The code does not check for this, since it can't happen by design: if an actor can't find a solver up its hierarchy, it won't be added to any solver. I'm not 100% sure what would happen otherwise.

It appears like some sort of initialization takes place in an unexpected order, judging from the change. I'm not sure what my approach to using ObiSolver would screw up outside of this.

Me neither. It is just not a supported use case. Doesn't mean it is not possible to get it to work in that way, but it's not covered by any of our unit tests and most of the code does not even consider the possibility of an actor not having a solver up its hierarchy.

I was considering having it be the case that all ropes that are meant to be controlled by the global solver are parented to it. However, this approach might not work well since some prefabs will also contain ropes, and reparenting child objects could have problems:

• If a prefab uses GetComponentInChildren to find obi rope references, they'd stop working unexpectedly. Or when writing new behaviours, it might be easy to forget that that rope which was originally in the prefab is no longer there after being instantiated.
  
• If a prefab is destroyed at runtime as a whole, you'd have ropes left-over that don't get destroyed with the rest of the prefab.
  

It's not needed for actors to be immediate children of a solver. They just need to be inside its hierarchy. Typically, you'd have prefabs with ObiRope components in them, at different hierarchy depths. At runtime you instantiate the prefab, place it under a solver, and you're done.

Say you have a character with chains (ropes) parented to and hanging from different parts of his body. The entire character is a prefab, you just instantiate the prefab and then put the entire character under a solver. If the character uses GetComponentInChildren() to get a hold of his chains, it will just work. If the character is destroyed, all chains will be too. No left-over stuff or tedious handling of object references.

This is also how UI in Unity works: Graphics must be under a Canvas for them to be updated and rendered / Actors must be under a Solver for them to be updated and rendered. It's the exact same pattern: you can build entire UI widgets as prefabs, instantiate them inside a canvas and have them working.