Obi 5.0 preview

Unity is undergoing a lot of changes, and at a very fast pace. Entire subsystems are being reworked and/or deprecated, replaced by more modern alternatives. Some of these changes have affected how Obi works, and we don’t want to lag behind. A change introduced in Unity 2019.1 has forced us to rewrite ObiCloth’s animation system from scratch, so we thought: why not seize the circumstances to revamp the entire thing, using the heap of user suggestions we’re sitting on?

Disclaimer: everything in this post is work in progress, slight details might change (for the better, most of the time) in the actual production version.

Blueprints

Obi 5.0 introduces the concept of blueprint: an asset that contains the recipe to generate actors (cloth, ropes, soft bodies…) out of it at runtime. This recipe mainly consists on particle and constraint data arrays. So no, these aren’t blueprints in the Unreal sense of the word ;).

In 4.x, each actor contained a unique copy of the particles/constraints that were used to initialize it. If you had 20 instances of a cloth/rope/softbody, each one would contain a copy of the same particle/constraint data, even if all of them looked exactly the same.

Moreover, in 4.x the inspector mixed initialization-time properties (like rope resolution) and runtime properties, giving rise to all kinds of confusion and misinterpretations. In 5.0, all initialization-time properties appear in the blueprint inspector, and all runtime properties appear in the actor inspector. This feels much more natural and intuitive.

4.x vs 5.0 setup

Let’s recap the steps needed to generate a flag in ObiCloth 4.x:

1. Generate a topology asset out of a mesh.
2. Assign the topology asset to the ObiCloth component.
3. Initialize the ObiCloth component.
4. Tweak particle data in the particle editor.

In 5.0, you’d do this:

1. Generate a blueprint out of a mesh, setting per-particle attributes in the blueprint editor.
2. Assign the blueprint to the ObiCloth component.

That’s 2 steps less. For softbodies, the workflow is exactly the same. In some cases, it’s even simpler. For instance, ObiRope no longer needs any initialization/generation of any kind. The rope blueprint is updated in realtime while you modify the curve path. Rope properties (mass, thickness, color) are stored at each of the curve’s control points and interpolated over particles, enabling non-destructive/non-linear editing. So this:

1. Tweak the ObiCurve component
2. Initialize the rope.
3. Tweak per-particle properties in the particle editor.
4. Realize the rope shape isn’t quite right.
5. Tweak the ObiCurve component again.
6. Re-initialize the rope, losing all per-particle property edits.
7. Re-tweak per-particle properties in the particle editor.
8. Realize the rope mass doesn’t feel right.
9. Rinse and repeat.

Turns into this:

1. Tweak the rope path control points, until both the shape and properties of the rope are just right.
2. Click play. Marvel at how good your rope looks.

The following video will give you a better idea of how simple, quick and easy it is to work with ropes in 5.0:

Particle groups

The blueprint editor also includes tools to define particle groups. 

 

These are lists of particle indices that can be accessed at runtime, and are stored as sub-assets of a blueprint. For instance, you could define a group for all the particles in the head of a soft body character, then use it to modify the mass of the head at runtime. If you’ve ever struggled to figure out the indices of certain particles at runtime, groups are the solution.

Attachments

In Obi 4.x, attaching an actor to a rigid body or transform could be done in at least 3 ways (fixed particles, handles, and pin constraints), each one requiring a completely different workflow. Moreover, all per-particle data including pins, handles, or fixed particles was irretrievably lost when re-initializing an actor.

Obi 5.0 takes advantage of particle groups to unify all kinds of attachments into a single concept: particle attachments. (we really didn’t spend days looking for a name…)

An attachment is a component that takes two inputs: a particle group, and the transform/rigidbody you want to attach all particles in the group to. Then, you can choose whether you want the attachment to be static (one-way) or dynamic (two-way, like good ol’ pin constraints).

Working with attachments is just so much more pleasant, both in the editor and at runtime. In the case of ropes, a particle group is automatically generated for each curve control point. This means attachments no longer get lost at any point during rope editing.

UX Redesign

In Obi 4.x, when adding an actor component to an object, each individual constraint type needed by that actor would automatically be added as a separate component. While following Unity’s component-based paradigm very closely, this resulted in a ton of components in the inspector, poor readability and inconvenient layout.

In Obi 5.0, each actor component shows all constraint parameters within its inspector, grouped by constraint type. This keeps things nice and simple from a UX perspective (only one component per actor), without sacrificing modularity.

Performance

Obi 5.0 is even faster than 4.x. Our underlying physics engine is much smaller, simpler and more streamlined, because we took out all non-performance critical functionality and moved it to C#. We’ve managed to parallelize pretty much 100% of the engine. Even tearable cloth and ropes -whose topology changes dynamically- now exhibit intra-actor parallelization.

 

This is only some of what’s coming next. Also, full 2019.x compatibility for ObiCloth and SRP compatibility for ObiFluid will arrive with 5.0.

We sincerely hope these user-feedback driven changes help us move Obi in the right direction. In our opinion, they address some of the more long-standing workflow, compatibility and performance issues. Thanks everyone for sticking with us so far, the huge amount of feedback given and your patience.