Suggestion / Idea Problem with the Obi Solver Structure

[Bill Sansky]

Yes. If you unparent it, it removes the actor from the solver. If you reparent it to a new solver, then it adds it to the new solver. All this happens internally and you don't need to know about it.

Got it, that makes sense. So then I think in my example on OnEnable I would need to reparent my rope under my solver object. It does makes things a bit more tricky for my pooling system, but I think I can agree that it's simple and clear.

If the solver lives outside your prefab (in the scene, or an unrelated prefab), then at runtime you will have to either find all ropes in your prefab and set their references to the solver, or simply reparent the whole thing under a solver. If you have multiple ropes per prefab the former is a bit of a chore, the latter is much simpler.

I'm working on a game that involves a lot of cables with quite some systems of connection on the top, and because of the number of cables in the game I have a respawn pool that handles the pooling of cables in runtime. So it relied on the fact that the ObiRope actor inside my "cable" prefab does not need to be reparented. 

I work with a system of referencing through scriptable object like described in that talk:


This way, I have a reference to my unique Obisolver through a scriptable object reference value, and I was just assigning it on enable. But if I just need to reparent my rope, I could reparent it on enable, and when the cable is pooled just reparent my Obirope under my pooled object. It's less clear but it will do. I did not get the fact that simply reparenting the object would be enough to set the solver.

 If it would make things easier, I can create a second attachment "flavor", that would be added to the target transform and have a reference to the actor (instead of having a reference to the target, and being added to the actor). That way you could have the attachments in the objects the actor is attached to, and have them reference the actor that lives anywhere else.

That would be awesome

Not really. This would require the actor to keep track of all attachments referencing it, which makes me feel a bit dirty from an architectural point of view. Ideally the actor should not know anything about attachments. Just like a rigidbody knows nothing about the joints affecting it.

I was more thinking of an editor only property, without any serialization involved, but your solution would solve the issue anyway.

As mentioned earlier, there is a crash in 2019.3 that prevents having the actor not parented under a solver (100% repro, at least when using the "disable domain and scene reload" option), but I will investigate that a bit more