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:
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 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.
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.
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.
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.
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.
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.
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.
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.
All components/assets related to the proxy system have been removed, replaced by the automatic decimation/skinning system.
Aerodynamic constraints now affect ropes, which enables a variety of effects.
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.
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.
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.
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.
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.
Softbodies now support surface collisions when using surface sampling.