Help Dynamic collisions (AR mesh colliders)

[Adrien]

Hello,

We are currently working on a demo to showcase the new Apple augmented reality Lidar feature and we would like to use obifluid in order to make a cool fluid simulation effect.

Our current challenge is that meshing reconstruction of the environment is done in realtime and can change anytime at runtime. Whereas physics in obifluid is initialized at start and mesh collider is not intended to change during the simulation.

We know that dynamic mesh collider is not the best use case for physics engines and fluid simulation (tunneling issue and expensive computation).
For now our workaround is to update the mesh collider at runtime (as already discussed here) every X seconds. But this method causes some lag during this reinitialization.

We'd like to get your input in order to use obi fluid as best as we can.
We also had some ideas to explore but wanted to get your opinion on them first:

• We have access to a depth map that gives us an estimation of the surrounding topology to extract the collisions infos; Is it possible to easily bind the depth values to the distance field approach of obifluid and is the initialization not to expensive?
  
• Maybe create an initialization process that involves multiple frames to avoid spikes of lag. For example by using coroutines and by waiting the end of the process before relaunching the simulation.
  

Thanks,

[josemendez]

We have access to a depth map that gives us an estimation of the surrounding topology to extract the collisions infos; Is it possible to easily bind the depth values to the distance field approach of obifluid and is the initialization not to expensive?

Unfortunately not. Distance fields can't be incrementally built, unless you tolerate some error. Every time you make a modification to the source mesh, the entire thing must be re-built from scratch. The reason for this is inherent to the very definition of distance field: a DF is a structure that stores the minimum distance from every point in space to the surface of an object.

You can't guarantee that any modification to the surface of the object will have only local impact on the distance field. Imagine your distance field is initially a plane: if you drew isolines to represent the distance field, the isolines would all be parallel to the plane. Now add a tiny little sphere floating above the plane: suddenly, most isolines become curved since for many points in space, the sphere is now closer than the plane.

So even a tiny change to the distance field shape forces you to recompute it entirely, which is a really slow process.

Code:

Maybe create an initialization process that involves multiple frames to avoid spikes of lag. For example by using coroutines and by waiting the end of the process before relaunching the simulation.

Depending on the size of the distance field (or mesh collider, for that matter), it can take several minutes to generate it, even more if you use coroutines as
the process is spread over multiple frames. Not a good idea imho unless you can tolerate such huge delay.


My take on this would be to partition your input data into "chunks" using a regular grid, octree, or similar structure. Then, you can generate a tiny mesh collider for each individual chunk. This has two advantages:

- Adding/modifiying a chunk only requires to generate that particular chunk, not the entire mesh. This would get rid of your current "lag".
- Faster collision detection since particles can discard entire chunks in the collision broad phase, as opposed to having to traverse a progressively larger BVH as you build a single, large collision mesh.