Obi 3.2: What’s new

Obi 3.2 (cloth, rope and fluid) is coming to the store in a couple weeks, and we wanted to give you a heads up. The colliders system has received a massive overhaul, with ease of use and performance as primary goals in mind. Good news: both have been achieved!

Ease of use

 

Prior to 3.2, you had to manually add colliders to a list in the ObiColliderGroup component, then assign this component to a ObiSolver. Only colliders and actors (cloth, ropes, etc) in separate layers generated contacts. This workflow was tedious, awkward and -as pointed out by many users- made it difficult to work with prefabs.

Enter 3.2: Add a ObiCollider component to any object you wish your Obi actors to collide with. Simple as that. So simple in fact that the new collision setup tutorial video is this:

The ObiColliderGroup component has ceased to exist. Instead, each solver has a layer mask property that allows you to filter out which layers will generate collisions:

When instantiating a collider (by duplicating it, or instantiating a prefab) it is automatically picked up by the appropiate solvers, both in the editor and at runtime. Similarly, when instantiating a new solver it automatically picks up the appropriate colliders. No need to manually keep track of the colliders assigned to each solver anymore.

Performance

 

In previous versions, ObiColliderGroup copied all of its colliders’ data and sent it to our C++ lib at the beginning of each frame. While OK for a couple dozen colliders, things got slower when using large amounts of colliders due to the overhead of traversing the C#/C++ barrier and moving things around in memory. Also, memory had to be allocated every frame, causing much dreaded GC spikes.

These limitations forced the user to either keep the amount of colliders relatively low, or add additional custom logic to prune unneeded colliders (e.g. distant ones) at runtime.

In 3.2, each ObiCollider allocates memory upfront when created, and reuses it for the rest of its lifetime. As a result, our new collision system allocates zero bytes/frame, and has a very small memory footprint.

Colliders also monitor its own state to see if the data sent to the C++ lib is up to date, in which case they do nothing at all. No memory allocation, no data juggling. Only colliders/rigidbodies that have moved, changed size, etc. since the last frame consume any resources.

What’s even better: the internal spatial partitioning structure used by Obi speed up contact generation is incrementally updated whenever a collider sends new data, instead of created from scratch every frame. This further increases the performance of collision detection.

All these improvements allow Obi 3.2 to deal with massive scenes, where actors can potentially collide with everything, at virtually zero cost. Here’s a graph comparing memory consumption and performance of 3.1 vs 3.2 for different amounts of static colliders:

 

In this video, 3.000 randomly instantiated colliders interact with a piece of cloth in 3.2:

Icons

 

As a bonus, new icon designs! Clean, flat icons replace the busy and hard-to-see tiny skeuomorphic designs:

Upgrading to 3.2 is completely FREE. (keep in mind that you’ll need to update all of your current collider-related setups if upgrading from a previous version!).

We put a huge amount of effort on improving things that we knew were less than ideal.  Hope you’ll appreciate the result! Shiny new features can wait for another update (they’re coming, though…).

 

The VM Team