Obi roadmap

[josemendez]

- Is this only going to improve performance for simulations with tens of thousands of particles, or is there also a benefit to use the compute backend for relatively low particle count and high quality simulations with high solver substeps / low fixed timestep?

Depends on your GPU, but for particle counts below 1500-2000 the CPU ias usually faster.

- How much is it going to restrict scripting with particles? Can you still do things like selectively modifying particles touching a trigger collider or is that out of the question?

Will restrict things a bit, but hopefully not too much.

I'm reading some data back to the CPU asynchronously: kick an async readback at the end of each frame, and at the start of the next physics step we wait for the data. Currently only particle velocities and positions are read back, this yields good performance and allows for basic things like attachments and spatial queries to happen on the CPU.

My initial idea was to read back contacts too. This would allow for contact callbacks, the problem is that this places the burden on the user: "here's an array with +200.000 contacts, now iterate trough them to find the ones you're interested in."

To only option I can think of to alleviate this is to expose the contacts in a ComputeBuffer directly. Then, hope the user is comfortable enough with compute shaders to process contact data without it ever leaving the GPU. Out of the box I also want to offer basic stuff implemented on top of this (triggers that kill particles, for instance).

As a side note: all rendering/mesh updating is now done differently for each backend. The Compute backend does it using compute shaders, the Burst backend does it using Jobs which results in a very nice performance boost (very noticeable for cloth and ropes, not so much for fluids and softbodies).