ObiColliders and Procedural Load

[josemendez]

Hello,

Like a lot of people who need an asset as sophisticated as Obi, my world loads procedurally and every instance of every object has to be created by code not exist in a pre-fabricated scene as a prop.

I've run into kind of a major hangup with getting Obi Rope to work in that environment. From the introduction(?) on the tutorials page: "Add a ObiCollider component to any collider in your scene to make it work with Obi."

I have no idea what colliders in my scene need to interact with the rope, how would I? Once loaded my scene has around 3,000 active colliders at a time (out of millions total). Adding another component to all of them during runtime especially when it searches the hierarchy for a rigidbody that will never exist seems like an impossible amount of overhead. A rope will only be active in my scene about 0.1% of the time.

So the only solution I can think of is to basically spherecast from the position of every particle, every frame, whenever a rope is active, and for each hit test if it already has the component, then find the rigidbody and assign the ObiRigidbody manually because I need a reference, then assign the ObiCollider because I need a reference to that as well, then test each reference each frame and remove it if it is out of range of the rope, and remove all those components if the rope becomes inactive. That would be, again, probably more overhead than the rope itself creates - and really I think an unfair amount of code that I would have to write to get this rope to be a rope.

So my question is what is the correct solution to this problem?

What I'm trying to do is really pretty straightforward; just have a rope that behaves like you'd expect a rope to behave, not passing through other physical objects.

Side note, creating a rope by code is something that seems to come up fairly often in this fourm and looking at the commonly referenced ObiRopeHelper.cs is still requiring me to make some fairly large logical leaps to get anything but runtime errors that leave me wondering if I'm using the product wrong, creating wasteful code or at least wasting a lot of time. An example that actually shows how to create an example rope by code would be extremely helpful. You can't just do new ObiRopeHelper() because that script assumes it's already set up in the hierarchy with references to unspecified objects.

Thanks,

Jon

Hi Jon,

Obi does not use Unity's built-in physics engine (as it is way too unstable to create any useful rope, as you might have discovered). Instead we use our own position-based physics engine, and interface with Unity's colliders and rigidbodies via impulses. Since Unity does not give access at runtime to their collider broad phase and their raw data, we must use a wrapper over the regular "Collider" components that convert the Unity definition of a collider to our own engine's representation, and pass that information to our C++ engine for simulation.

Note that once the ObiCollider component is added, you no longer need to take care of it. It will make Obi aware of that collider automatically, and will behave just like a regular Unity collider. You don't need to remove the ObiCollider components once you've added them either. If a collider is not moving or rotating, the ObiCollider component does absolutely nothing. Only when any property of the transform or the collider changes, it updates Obi's representation of that collider. This update is also very quick, since it updates transform and collider properties separately.

This is pretty much what every other custom physics engine in the store does (AgXDynamics and CaronteFX come to mind), and it's the best way to do it.

Usually this is not a problem, since most games use prefabs for their objects (ObiColliders and ObiRigidbodies are created in the editor and saved with the prefab, then just instantiated at runtime: so zero overhead).

Even if all your colliders are generated at runtime, adding an additional ObiCollider component is not a big deal. It's just one more component per object, and it only looks for a rigidbody component in the same object or up its hierarchy upon re-parenting (not every frame). Unless your objects are extremely deep compound collider hierarchies (with a rigidbody component way up the hierarchy for every leaf object) and you're instantiating millions of them per frame, you will notice no impact at all. This is a small constant-time operation per collider, done only once when you create it. Doing a sphere cast every frame for every particle will be much, much worse performance wise.

We've done tests with hundreds of thousands of procedurally generated colliders in the past and this was no problem at all. See:
http://blog.virtualmethodstudio.com/2017...whats-new/