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

[josemendez]

In your defense, I can understand how most use cases for Obi - e.g. cloth on characters - this would make sense. In these use cases it is a bit like a skinned mesh with fancier math attached. If Obi were more often used in the same way PhysX is, where players can play with it arbitrarily in some cases and very few assumptions about what the players may do can be made, I hope you can see why it wouldn't work. This is why I made the comparison.

I get what you mean. However, the typical use case for Obi is for it to be restricted to a relatively small spatial area: character cloth, a crane, a fluid container, some softbody eye candy, just to name a few. In these cases, it's natural for the solver to be at the root of the prefab (character, crane, container, etc). Information about the "outside world" (Unity colliders and rigidbodies) is converted to the solver's local space, so things can still collide with the environment and/or be attached to it regardless of where the solver resides. Only actor inter-collisions are restricted by this.

In this regard, Obi uses parenting as a merely organizational tool. It does not make sense to parent a rope to another rope, or cloth to a fluid emitter, just like it does not make (much) sense to parent a rigidbody to another rigidbody.

A suggestion I'd put forth is to use parenting by default for the majority of simpler use cases. But in cases where game object parenting relationships are reserved for other purposes, it'd be a good option to allow actors to simply reference which scene they're a part of in a separate field.

That's how Obi v1 and v2 worked: all actors had a "solver" field in the inspector, that got populated by the first solver found in their hierarchy by default. You were able to select a different solver if needed. Simulation could be performed either in the solver's local space (if parented) or world space (if not part of the same hierarchy). However this had a few drawbacks:

- Supporting world space simulation only is not an option, so code paths for world and local space had to coexist, making the code more verbose, less efficient (in world space's case) and harder to maintain.
- A single solver could have some actors in world space, and some actors in local space, which made things confusing. Also, inertial controls in the solver only affected local space actors which made things even more wonky.

I took a look at how Unity solves this relationship between a "manager" object and "managed" objects. In most cases  (UI, Animation, Rigging, etc) this is done by parenting the managed objects to the manager. This approach solves the above issues single-handedly: unified code path for everything, efficient simulation, and consistent behavior in all cases.

Requiring that developers cannot use the built-in Instantiate method provided in Unity for a feature to work correctly can be an issue.

The built-in Instantiate method can take a parent as argument, so you can use  Instantiate(Object original, Transform parent); to set the parent right away. So instead of:

Code:

Instantiate(myPrefab);

you'd do:

Code:

Instantiate(myPrefab, mySolver);

If you had to assign a solver explicitly, you'd need to do something like:

Code:

var instance = Instantiate(myPrefab);
instance.GetComponentInChildren<ObiActor>().solver = mySolver;

I'd argue that this second version is awkward. It would get uglier if you had more than one actor inside your prefab, as you'd have to iterate trough them all.

In the case of third-party assets, it'd at best be annoying to have to modify all of their code for compliance (assuming compatibility), and at worst, it'd be potentially unworkable without serious hack-arounds in case where you do not have source code access. But, as our project grows and other features are added - especially third party features - and they compete for control over how objects are laid out, it could become a headache that doesn't need to happen.

This could be said of virtually any third-party asset/middleware. Only trivial stuff fits right into an existing codebase. Integrating a new physics engine into your game is often a quite painful experience, we've tried to minimize that within reasonable effort.

Our project is early on enough that we could just ban the use of Object.Instantiate outside of our special replacement method that ensures compliance with Obi.

I don't think you need to write a special replacement, the default Instantiate would work fine as long as you set the correct parent.

This all being said, no, not everything in our game is made of ropes, cloth, or fluid. But there will be plenty of objects that do have these things, and they can be spawned in arbitrarily. They'll need to be able to interact, and can move anywhere in the scene.

Will think of a way to reduce setup hassle for something like this. Quite often, less hassle == less flexibility, so this has to be carefully considered.