What's new in Obi 7

Obi 7 is a major revamp that aims to maximize performance, quality and ease of use without compromising versatility. Full GPU simulation, multithreaded rendering, better force zones and high quality mesh-based fluid rendering are some of the new features that we hope will help you add incredible simulations to your next project.

Here's a list of all major changes introduced in Obi 7. If you're updating from Obi 5.X/6.X, keep these in mind while making the transition:

Changes affecting all Obi products:

'Oni' backend has been removed

Oni was a CPU solver backend, written as a native C++ library way before Unity's job system and Burst compiler were a thing. For a long time both the Burst backend and Oni coexisted as Burst slowly matured, however Oni was always had slightly worse performance and limited platform compatibility. In the 6.X cycle we deprecated Oni, in 7.X it has been entirely removed.

If you want simulations to run in the CPU, install the required package dependencies for Burst and use the Burst backend.

'Compute' backend has been added

Compute shaders are a way to use your computer's Graphics Processing Unity (GPU) to perform arbitrary calculations, not just graphics-related stuff. The main new feature of Obi 7 is a Compute backend that leverages the power of compute shaders to allow for much larger and more complex simulations, involving many thousands of particles.

100k rope, cloth, softbody and fluid particles simulated in realtime using a 3070 RTX GPU.

Asynchronous simulation

Traditionally, Obi has performed simulation in lockstep with frame rendering: simulation started at a specific point during the frame, and had to finish before the frame began rendering. This forced the main thread to wait for the simulation to finish before moving on.

In Obi 7 a new asynchronous mode has been added to solvers, that allows simulation and rendering to run concurrently: the current frame is simulated while rendering takes place. The main thread will only wait if the next frame needs to start simulation but the previous frame is still in flight. This introduces a 1 frame delay between physics and rendering, but greatly increases performance in both the Burst and Compute backends. Asynchronous mode is enabled by default.

Traditional synchronous mode. Simulation for the current frame must finish before rendering starts. Each frame takes 11 ms.
Asynchronous mode. Time spent in simulation extends beyond the end of the frame, while rendering is taking place. Each frame takes 7 ms.

ObiUpdaters have been removed

ObiUpdaters allowed for multiple solvers to run in parallel, and control the point at which simulation took place during the frame by choosing different flavors of updaters: run using a fixed timestep at the start of the frame (ObiFixedUpdater/ObiLateFixedUpdater), or run at the end of the frame using a variable timestep (ObiLateUpdater).

In Obi 7 all solvers always run in parallel. Simulation starts in LateUpdate(), while still using a fixed timestep. This combines the best features from all ObiUpdater flavors and simplifies setup, as a result, the ObiUpdater component has been removed.

The updater's substeps parameter has been moved to the ObiSolver component, which allows to use a different amount of substeps for each solver in the scene.

Multithreaded rendering

In Obi 5.X/6.X, only simulation took advantage of multithreading. Updating rendering data such as particle geometries, rope/cloth meshes or skinning softbodies happened in the main thread, becoming the bottleneck in some situations. This is no longer the case in Obi 7, all rendering systems have been moved into the solver backend and take full advantage of multithreading both in the Burst and Compute backends.

In Obi 6, cloth mesh updating happens in a single thread. Total frame time is roughly 4 ms.
In Obi 7, cloth mesh updating is multithreaded using Burst/Compute. Total frame time is 1.4 ms.

Force zones

Force zone support has always been quite limited in Obi, only a couple shapes (sphere, box) were supported and performance was not all that good since they weren't part of the core solver.

Obi 7's force zones are blazing fast since they're implemented natively in both backends: using jobs in the Burst backend, and compute shaders in the Compute backend. Any ObiCollider can be used to define their shape: you can now use spheres, boxes, capsules, 2D polylines, triangle meshes and arbitrary distance field shapes combined with radial, directional and vortical field directions, and wind/force/acceleration modes. You can also control which zones affect which particles, since they have full collision filtering support.

Helix-shaped distance field acting as a radial force zone.

Ambient wind

In addition to gravity, solvers now support an ambient wind direction. This makes it easy to introduce some basic wind in the simulation without the need to add force zones.

Changes affecting Obi Cloth:

Added non-manifold mesh support

In Obi 5.X/6.X, meshes used for generating cloth blueprints had to be 2-manifold: this imposed a few restrictions to the topology of the mesh, such as no zero-length edges or consistent triangle winding / triangle orientation. Obi 7 supports any mesh, regardless of topology.

Automatic cloth decimation and skinning

In Obi 5.X/6.X, using a different mesh for simulation and rendering involved manually retopologizing your mesh to have 2 different versions of it, then manually binding the high-resolution visual mesh to the low-resolution simulation mesh using proxies.

Obi 7 allows you to automatically simplify your mesh during cloth blueprint generation, by specifying a distance below which connected vertices will be merged. It also automatically binds the original mesh to the resulting simulation geometry. This greatly simplifies and speeds up the process of generating cloth simulations of highly detailed meshes.

Input mesh.
Resulting cloth particles/constraints with no decimation.
Resulting cloth particles/constraints decimated to minimum distance of 0.1 units between particles.

Proxies have been removed

All components/assets related to the proxy system have been removed, replaced by the automatic decimation/skinning system.

Changes affecting Obi Rope:

Added aerodynamic constraint support

Aerodynamic constraints now affect ropes, which enables a variety of effects.

100 ropes being blown upwards by a fan.

GPU instanced chain rendering

Chain rendering in Obi has been traditionally quite slow, since each chain link was a full-fledged GameObject. Obi 7 uses GPU instancing to draw chains, which is orders of magnitude faster.

Changes affecting Obi Fluid:

Isosurface mesh extraction

Building a fluid surface mesh from a particle-based simulation is very costly. Traditionally, Obi has used a cheaper technique known as screen-space ellipsoid splatting to render fluids. This technique draws fluid particles on offscreen textures, and calculates lighting using a custom deferred lighting pipeline. This is cheap but has many limitations, such as no proper VR/AR support, difficult custom shader authoring, poor integration with SRPs and difficult integration with custom rendering effects like SSAO or SSR.

The faster multithreaded rendering system in Obi 7 allows it to render fluids as actual meshes. This enables support for VR/AR, easier shader authoring using Shader Graph, and integration with custom rendering effects, as well as higher quality visuals.

Obi 6 ellipsoid splatting. Notice bumpy artifacts in surface lighting at grazing angles, and weird clot-like formations that reveal the particle based nature of the simulation.
Obi 7 isosurface meshing. No lighting artifacts at grazing angles, much smoother fluid surface.

Better Viscosity and Vorticity

Up to Obi 7 viscosity in Obi had been implemented using XSPH, which smoothes particle velocities by driving them towards the average velocity of their neighborhood. This is simple and fast, however it dampens out rotational motion in the fluid in an unphysical way. To compensate for the rapid loss of rotational motion, traditional vorticity confinement was used.

Obi 7 unifies viscosity and vorticity using a method that tracks local fluid deformation around each particle using affine matrices. This allows for corotational viscosity and more effective vorticity confinement. Using this combined method, simulation is faster, fluid vortices stay around longer and new phenomena such as coiling and buckling can be simulated.

Highly viscous fluid exhibits buckling.

Polarity replaces Surface Tension

Traditional surface tension in Obi had several problems: performance costly, large values resulted in overly strong sheet/filament formation instead of round droplets, unable to control whether different fluids should attract each other.

Obi 7 takes a physically inspired approach to surface tension using polarity: highly polar particles attract each other - the higher their polarity, the stronger the attraction. Substances of similar polarity are miscible, substances of different polarity are not (their particles aren't attracted to each other).

This way, surface tension emerges automatically from the interplay of forces at the surface of the fluid and always leads to round droplets. You can also explicitly control whether fluids are meant to mix with each other or not by giving them different polarity values, allowing for a broader palette of effects.

Fluids of similar polarity mix with each other, as their particles are mutually attracted.
Fluids of different polarity do not mix, as their particles repel each other.

Improved particle advection

Prior to Obi 7, particle advection would drive Unity's built-in particle systems using a fluid simulation. This had serious performance limitations, since the API exposed by Unity's particle system is not well suited to multithreading and runs fully in the CPU.

Obi 7 includes an custom integrated particle system for foam and other advected particles. This system is implemented using Burst/Jobs in the Burst backend and using compute shaders in the Compute backend, which yields maximum performance and allows to simulate tens of thousands of advected particles in the CPU, and hundreds of thousands in the GPU (up to 750k in our tests, using a 3070 RTX GPU). It is also possible to interface with the advected particle system from raw C#, Jobs or compute shaders, which opens up a wide range of possibilities.

40k fluid particles and 500k advected foam particles being simulated by a 3070 RTX GPU.

Changes affecting Obi Softbody:

Added surface collisions support

Softbodies now support surface collisions when using surface sampling.