Backends

A backend is the actual physics engine used by a solver to step the simulation forward. Different backends might have different platform compatibility, performance, and capabilities. While you can select a different backend for each individual solver in your scene, most of the time you will want all solvers to use the same backend. To select a different backend for a solver, use the "Backend" dropdown in the solver inspector:

Obi ships with two backends to choose from: Burst (CPU) and Compute (GPU).

Burst (CPU)

Burst is the default backend since Obi 5.6. It is fully written in high-performance C#, making use of Unity's Burst compiler and job system. It supports all platforms that can run jobs and that the Burst compiler can compile for. It is fully CPU-based, and makes heavy use of multithreading and SIMD (thanks to the job system and Burst compiler, respectively).

The full source code for the Burst backend is included in your Obi installation, it can be found at /Obi/Scripts/Common/Backends/Burst/.

Installation

Using the Burst backend requires having the following Unity packages installed:

Burst 1.3.3 or newer
Collections 0.8.0-preview 5 or newer
Mathematics 1.0.1 or newer
Jobs 0.2.9-preview.15 or newer

If you don't have these installed the ObiSolver component will show an error (see below) in its inspector window, and the simulation won't run:

Keep in mind that preview packages (Collections and Jobs) will not appear in Unity's Package Manager unless you explicitly enable them (see Unity's manual). In recent Unity versions (2021 and later), you may need to manually locate the packages by URL. This can be done clicking on the plus (+) sign at the corner of the Package Manager, and selecting "Add packages by git URL":

Then you can write the package URL in the pop-up field that appears, for instance: com.unity.collections, or com.unity.jobs

Performance

Please note that for normal performance when using the Burst backend in-editor, you must enable Burst compilation and disable the jobs debugger, safety checks and leak detection.

Also, keep in mind that Burst uses asynchronous compilation in the editor by default. This means that the first few frames of simulation will be noticeably slower, as Burst is still compiling jobs while the scene runs. You can enable synchronous compilation in the Jobs->Burst menu, this will force Burst to compile all jobs before entering play mode.

When profiling a simulation backed by Burst, you can use Unity's built-in profiler. In timeline mode, you will see all worker threads busy during the physics update call:

Note that deep-profiling has a noticeable impact on performance.

Compute (GPU)

Compute is an GPU based backend added in Obi 7.0. It is fully written using compute shaders, that will run the simulation on your GPU. For this reason, it is best suited for very large simulations.

The full source code for the Burst backend is included in your Obi installation, it can be found at /Obi/Scripts/Common/Backends/Compute/. The compute shaders used by the backend can be found at /Obi/Resources/Compute/.

Installation

There's nothing to install in order to use the Compute backend, as long as your device supports compute shaders it will run out of the box.

Performance

There's a few pitfalls to be aware of when using the Compute backend. A common misconception is that the GPU is always faster than the CPU, however the minimum cost of a simulation tends to be higher in the Compute backend. Small simulations (that is, few actors/particles/constraints) are a better fit for the CPU. Here's a graph depicting how the cost of a simulation increases as its size grows, for both a CPU and a GPU:

As you can see, for most problems there's a minimum size below which a CPU will perform better than a GPU. This is because each individual core in a GPU is less powerful than a CPU core, despite the GPU having many more cores.

Another consequence of how GPUs are designed is that they're only faster than a CPU if the task at hand can be divided into many smaller independent sub-tasks to be performed simultaneously. Some tasks performed by Obi do not lend themselves well to parallelization, so they might run slower on the GPU than they do in the CPU. Some examples are:

Rendering long ropes

Extruding a shape along a curve is an inherently sequential algoritm, so generating the mesh for a single rope cannot be divided into smaller tasks. If you have many ropes to render however, the GPU will excel at this. So if you're dealing with a few very long extruded ropes, use the Burst (CPU) backend. If you're dealing with many short ropes, use the Compute backend.

Volume constraints

Cloth volume constraints require very large summation operations that -while performed using parallel reduction- can be very taxing on the GPU. The Burst (CPU) backend will perform better for a few large cloth balloons than the Compute (GPU) backend.

Conversely, there's also tasks that the GPU excels at, and that will always run faster when using the Compute (GPU) backend:

Many cloth/rope/softbody actors

Individual actors are completely independent from each other. This guarantees efficient parallelization, and using the Compute (GPU) backend will yield much better performance.

Fluid simulation

Each individual particle in a fluid simulation can be processed independently from all others. This is very GPU-friendly, so large amounts of fluid or granulars will perform better on the Compute (GPU) backend.