Obi Backends (Burst)

In Obi 5.0 we took special care of separating engine code from the data it operates on. Now we’ve started to reap the benefits, in this post we’ll tell you about it.

Everything described in this post is WIP, details are subject to change in the future.

Backends

Very much like a renderer can be backed up by different graphics APIs (OpenGL, DirectX, Metal, Vulkan…), we aim to give solvers the ability to switch between multiple simulation backends. A simulation backend is the actual engine used to perform the simulation.

Until now, all the math-heavy physics code in Obi was deferred to a custom C++ engine known as Oni. This engine implemented a job system backed by a work-stealing thread pool, operating under the SoA paradigm (struct of arrays), and making extensive use of SIMD (single instruction-multiple data). This guarantees the absolute best performance possible -maximum CPU utilization, minimum cache misses- . Unsurprisingly, this is basically what Unity’s DOTS is all about.

Note: DOTS stands for Data Oriented Technology Stack. It is a new programming paradigm that Unity is heavily investing in. But you already knew this, right? 🙂

So we’ve embarked on the task of porting all of Oni to Jobs + Burst, exposing it as a second simulation backend. We’re not using the ECS part of DOTS because all our data is already laid out in a very similar -optimal- way. So now you can choose between two backends: Oni or Burst.

Here’s an early video:

Why does this matter?

You might be thinking:

Ok, so this Burst thingy looks exactly the same, and performs as fast as Oni does. So apparently nothing has changed. Why is this worth the fuss? why should I care?

Well, because of two reasons:

• The full backend code will be included in Obi. You will have access to the entire engine, and will be able to modify any part of it. No code will be hidden inside a library.
• The Burst backend will support all platforms that the Burst compiler does. This means console support, and eventually all platforms supported by Unity.

There’s a third reason, mostly appealing to us as developers. Being able to write and profile code directly in Unity allows for faster iteration times (no need to compile the C++ library for each specific platform, then test cloth, ropes, soft bodies and fluid in each one…that’s a huge time sink). This way we can spend more time developing, writing documentation, and doing other important stuff.

Will I need to modify my code or my scenes to use Burst?

Nope. Simply select “Burst” instead of “Oni” in the solver backend dropdown. That’s it. The C# API is exactly the same for all backends, and the blueprints (that contain all data) do not need any kind of updating/conversion.

Why not get rid of Oni then?

Because we feel it still holds some value, at least in the foreseeable future. First of all, it’s battle tested. It’s also a good benchmark to compare other backends against. Some users with access to the C++ source have modified versions of the engine deployed in production, so they will need long term support for Oni. For quite a while, both backends (Oni and Burst) will coexist.

Will it ever be deprecated, eventually removed? It depends. If the day arrives where pretty much no one is using Oni, then we will say goodbye to it.

When will the Burst backend be available?

So far we’ve implemented most constraint types and particle-particle collisions. We are currently working on collider/rigidbody coupling. I’d say we are 40% done, 4-6 months away from release. Obi 5.3 will probably be the first version to have Burst available as a new backend.

Are you planning on adding other backends?

Yes, we are! A compute-shader based backend would be nice, so it is in our long-term plans. It would likely have some limitations compared to CPU-based backends (probably in the rigidbody interaction department), but it would still be very useful.

Let us know your thoughts. We have an exciting 2020 ahead!