What's new in Obi 8

Obi 8 is a major rewrite that aims to push performance further while simultaneously improving flexibility and robustness. It's been two years in the making and there's a lot of changes this time. Note that these changes make it incompatible with older versions, so you're updating an existing project from Obi 7.X or 6.X, put aside some time to rebuild your blueprints and adjust your existing code.

Changes affecting all Obi products:

All sample scenes migrated from Built-in render pipeline to URP

Unity officially deprecated the Built-in render pipeline, which has been replaced by URP as the default pipeline. We've updated all sample scenes to use URP instead.

New API to create custom constraints

Obi has always shipped with full source code, however most of it wasn't designed with extensibility in mind: for the most part, you were handed a black box. We've completely rewritten large portions of both the core engine and the user-facing API to make it easier to read, understand and customize. It is now possible to write and register your own custom constraint types complete with UI inspector integration, write custom actor types, and endow particles with custom properties. This comes with extensive documentation to help you navigate your way trough the code.

We're also working on allowing custom collider types in the near future during the 8.X development cycle, we've already paved the way for that.

New particle and constraint allocation strategies

Solvers in Obi 7 allocated individual particles for each actor, which meant particles belonging to the same actor would actually end up scattered across data arrays. This forced each actor to keep a solverIndices array, mapping from particle index in actor to particle index in solver.

Obi 8 uses a more sophisticated particle allocation strategy (block-based, address-sorted coalescing first fit) that ensures particles for an actor are assigned a contiguous memory block. As a result, actor.solverIndices is now a range (start and count). This saves memory, improves cache coherency and performance, and simplifies handling of particle data.

We've also changed the way constraints are allocated, stored and processed. Obi 8 introduces the concept of work item: a small group of 1-8 constraints that share as many particles as possible. Batching work items instead of individual constraints results in fewer batches, and batches can now be expressed as a simple range over an array of work items. This simplifies constraint handling while improving performance.

Tether and Chain constraints removed

Both Tether and Chain constraints were ad-hoc solutions to minimize stretching of large cloth/rope actors. They required manual setup and only worked well in specific situations. Obi 8 introduces a general solution to this problem (geometric multigrid solver, see below) that supersedes Tether and Chain constraints.

Multigrid solver

Obi 8 adds multigrid capabilities to its core solver. By performing simulation at multiple, progressively coarser discretizations, it propagates the effect of constraints faster and minimizes stretching in ropes, rods, regular cloth and skinned cloth. This yields a stable solution at any substep/iteration count (unlike the old Chain constraints), requiring no manual setup and no a-priori knowledge of which particles are going to be attached (unlike the old Tether constraints).

Simultaneous sequential and parallel constraint evaluation

Obi constraints forced you to choose between sequential or parallel evaluation: sequential converges fast but results in uneven constraint force distributions, while parallel converges slowly but distributes forces evenly. In Obi 8, you can independently choose iteration counts for sequential and parallel evaluation, now exposed as "regular" iterations and "smoothing" iterations. Parallel (smoothing) iterations are always applied on top of Sequential (regular) iterations, which means you can reduce error fast using regular iterations and then smooth out the result, getting the best from both evaluation modes.

Additionally, parallel evaluation/smoothing no longer uses averaged Jacobi: we've switched to mass-splitting across the board (which we previously only used for rigidbody coupling), so smoothing now correctly conserves momentum - removing another limitation of parallel evaluation.

Velocity constraints

Obi has traditionally been a position-based engine, with most constraints enforced on positional data and only having a select few affect velocities (most notably aerodynamic constraints). All constraints in Obi 8 can be enforced on positions, velocities, or both. Some of the included constraints use this dual-constraint scheme: distance constraints now have their own velocity damping controls, and contact constraints can affect body velocities after collision (bounciness).

Improved floating point precision

Obi 8 departs from PBD's usual position correction/velocity update scheme: instead of correcting current positions and deriving velocities by subtracting the original (uncorrected) positions, corrections are accumulated on velocities and only applied to positions at the end of each step.

This results in much improved floating point precision (specially noticeable when away from the solver's origin) and more accurate friction calculations since we no longer need to reconstruct velocities by subtracting absolute positions at any point during simulation. It also freeds us from the need to explicitly store the previous' step positions/orientations (solver.prevPositions/prevOrientations) so in addition to being more accurate, it also consumes less memory.

Significantly more robust collision detection and pin constraints/attachments

Previous Obi versions gathered contact information once per timestep, and reused it for all substeps. Obi 8 only gathers contact pairs once per timestep, and recalculates all local contact information at the start of every substep: contact point, normal, tangent, etc. This yields more accurate collisions in the presence of complex, curved collider surfaces while still amortizing the expensive pair detection mechanism over multiple substeps. This allows Obi 8 to properly handle locally curved contact manifolds (specially beneficial for concave SDFs) and complex attachment point trajectories under very fast motion.

Reformulated attachment orientation

We've reformulated orientation handling for attachments: it no longer confuses orientations 180º degrees apart from each other, so no object flipping should take place even with a single attachment.

Faster, more accurate surface collisions with simpler setup

We've ditched the Frank-Wolfe and Golden Search algorithms used for local contact optimization (aka surface collisions) in previous versions: Frank Wolfe tends to zig-zag around the contact point taking too long to converge, and Golden Search only works for 2D simplices. A barycentric variant of Barzilai-Borwein gradient descent replaces both, yielding better surface collisions at slightly less cost. The "surface collisions tolerance" parameter has also been removed, as it's been rendered obsolete by the new approach.

No limit to the amount of overlapping colliders (Compute backend)

The compute backend had a hard limit of 64 candidate colliders per simplex on previous versions, which caused dense scenes with many overlapping colliders to silently miss collisions. This limit has been lifted, replaced by a limit of 32 potential contacts per simplex-collider pair which is less restrictive in practice.

Restitution (bounciness)

Collisions in older Obi versions were completely inelastic. Obi 8 adds restitution support, which means particles can optionally bounce off colliders and each other. Collision materials now have a new "bounciness" attribute ranging from 0 to 1 that allows you to control the amount of bouncing. (Note that bouncing off dynamic rigidbodies is NOT supported).

Per-particle collision materials

In older Obi versions, each particle held a pointer to a collision material struct. We've simplified and compressed collision material data, allowing each particle to carry its own instance of a collision material. For a moderate memory cost, every individual particle can now have different friction, stickyness and bounciness values.

Faster constraint coloring/batching

Constraint batching in Obi has traditionally been quite slow: when done offline (during blueprint generation) it took multiple seconds. When done at runtime (for collision constraints), it took a sizable chunk of the frame. Obi 8 greatly improves upon this by using parallel incremental greedy coloring. Offline batching now takes milliseconds instead of seconds, and the cost of realtime contact coloring is neglibible as it is amortized over multiple frames.

Constraint batch visualization in blueprint editor

Blueprint editors now allow you to see how your constraints have been grouped into batches for parallelization. Less batches = better performance, so this gives you an idea of how expensive to simulate your geometry is.

Blueprints can now optionally only re-generate constraints

Instead of regenerating the entire blueprint from scratch, blueprints now allow for partial regeneration of constraints only, leaving particle data intact.

High performance debug mode

We've added a new runtime debug component that allows you to visualize a variety of particle properties as well as information regarding contact points (both particle and collider contacts). Works both in-editor and builds.

Memory profiler

We've added a new memory profiler that allows you to visualize memory managed by each ObiSolver component in the scene. You get a visual preview of how memory is assigned to particles and constraints, as well as details (active/inactive entries, free and reserved blocks, usage %, etc)

Changes affecting Obi Rope:

Faster tearing and resizing

Tearing and resizing now directly deal with solver data, they do not require a local instance of the blueprint that gets modified and triggers constraint re-loading.

Multigrid solver replaces Chain constraints

Chain constraints implemented a direct solver for chains of distance constraints, used to minimize stretching in rods. They offered limited parallelism and traded convergence speed for stability, often caused pretty wild jitter when applied to rods in difficult configurations (under forced stretching, or bent in impossible shapes).

Obi 8 adds multigrid capabilities to its core solver. This minimizes stretching for both rods and ropes, even with a single substep, without any manual setup, and yields correct behavior in the presence of collisions and/or dynamic attachments.

Mesh deformer API

You can now write custom code to deform extruded ropes, lines and meshes every frame, after simulation has taken place.

Changes affecting Obi Cloth:

Faster tearing

Tearing now directly deals with solver data, it does not require a local instance of the blueprint that gets modified and triggers constraint re-loading.

Directable tearing

It's now possible to define individual groups of triangles (patches) that the cloth should break into during tearing. This allows you to determine the exact way cloth should tear. (Note that tearing can only happen along existing edges as in previous versions, no remeshing takes place).

Multigrid solver replaces Tether constraints

Tethers were a form of long range attachments (LRAs), used to minimize stretching in attached cloths. They required manual setup and a-priori knowledge of which particles were going to be attached at runtime, and results did not work well together with collisions or dynamic attachments.

Obi 8 adds multigrid capabilities to its core solver. This minimizes stretching even with a single substep, without any manual setup, and yields correct behavior in the presence of collisions and/or dynamic attachments.

Better mesh decimation

Obi 8's new decimator better preserves symmetry (both axial and radial), yields higher quality triangulations (less sliver, thin triangles) and it's faster.

Mesh deformer API

You can now write custom code to deform cloth meshes every frame, after simulation has taken place.

Changes affecting Obi Fluid:

More accurate fluid refraction

Refraction now considers two interfacial ray transitions: air/fluid (upon entering the fluid volume) and fluid/air (upon exiting it), while it previously only considered one. In practice this means fluid drops will correctly show an inverted image of what's behind, for example.

Changes affecting Obi Softbody:

Compliance-based shape matching constraints

Shape matching constraints replace their "deformation resistance" with a physically-based compliance parameter, like most other constraints in Obi.

Mesh deformer API

You can now write custom code to deform softbody meshes every frame, after simulation has taken place.