Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Fluid tunnels through Obi Collider with Compute (GPU) backend, not with Burst (CPU)
#1
In my simple scene of maybe 10 static box colliders with each an associated Obi Collider the fluid correctly reacts to those static colliders, in CPU and GPU backend mode. It also reacts correctly to the one non-static gravity-influences box collider + Obi Collider.

But when switching to Compute (GPU), the non-static object is ignored completely by the fluid. The flow speed isn't really high, maybe 4 m/s and the emitter of 0.4 m^2 is set to speed 1.5 only.

A 2nd missed collision is happening at only one of the static colliders, which isn't obviously different than the others. At least that I could fix by increasing the Obi Collider thickness and is an acceptable workaround for that one.

Only when setting thickness to 2.79 or larger on the non-static collider, it reacts correctly, but that's far too wide as the non-static object is only 1x1x2 m large. Also when adding a completely new simple Cube with RigidBody + Box Collider + Obi Collider, that new object is completely ignored by the fluid.


I suspect some dependency on the surrounding box the non-static object is located inside. Maybe Obi Solver tries to optimized too much, but how to prevent that?

Unity 6.5, Obi Fluid 7.1.1
Currently 100000 fluid particles at 2 res, but same problem with res 0.4 and only 2000.
Reply
#2
When pausing play mode I see 0 contacts in GPU mode and about 2 contacts / simplex in CPU mode (screenshots attached).


Attached Files Thumbnail(s)
       
Reply
#3
(08-08-2026, 05:19 AM)isenberg Wrote: When pausing play mode I see 0 contacts in GPU mode and about 2 contacts / simplex in CPU mode (screenshots attached).

Hi,

This is because im the Compute backend, contacts aren't read back to the CPU unless you explicitly ask for it by subscribing to the solver's OnCollision method, as it has a non-negligible performance impact - so normally, the CPU will report 0 contacts since they're taking place in the GPU. The Burst backend works in the CPU, so there's no need to read back contact information.

(08-08-2026, 05:19 AM)isenberg Wrote: But when switching to Compute (GPU), the non-static object is ignored completely by the fluid. The flow speed isn't really high, maybe 4 m/s and the emitter of 0.4 m^2 is set to speed 1.5 only.

A 2nd missed collision is happening at only one of the static colliders, which isn't obviously different than the others. At least that I could fix by increasing the Obi Collider thickness and is an acceptable workaround for that one.

Only when setting thickness to 2.79 or larger on the non-static collider, it reacts correctly, but that's far too wide as the non-static object is only 1x1x2 m large. Also when adding a completely new simple Cube with RigidBody + Box Collider + Obi Collider, that new object is completely ignored by the fluid.

Would it be possible for you to send a project that reproduces this issue to support(at)virtualmethodstudio.com so we can take a closer look and diagnose the issue?

thanks!
Reply
#4
(10-08-2026, 01:13 PM)josemendez Wrote: Would it be possible for you to send a project that reproduces this issue 
Yes, I'm working this week first on re-creating the problem in a simplified scene, also to exclude that my copy and paste from some public examples introduced some weird hidden setting.  I'll let you know as soon I have something to share.
Reply
#5
I could reduce the problem slightly now: As soon I enable the Obi Collider for any static object, which has a box collider, the collision between fluid and non-static object is not detected any more in GPU mode. That hints to the problem of too many potential contacts. Currently trying to reproduce it in a completely new project. In the first attempt that small new project works fine in GPU.
Reply
#6
(10-08-2026, 01:13 PM)josemendez Wrote: Would it be possible for you to send a project that reproduces this issue 

I could reproduce it now with a simple project using 1 non-static cube, a box made from 5 transformed cubes and a ground plane made from a ProBuilder cube by changing its size. Have sent the 6MB zip to the email address.
Reply
#7
I have drastically simplified the problem reproducer now. Attached as obifluidtest.zip.

The problem: The Obi Fluid dropping from above tunnels through the non-static small Cube and only collides with the larger GroundCube below.

On my plain installation of Unity 6000.5.2f1 (6.5) without any additional components or special GPU tools outside of Unity, it shows the issue on a Macbook Air M1 and a Macbook Pro M2, both with 16 GB RAM when Compute GPU Mode in the Obi Solver is enabled. When switching to Burst CPU mode it works fine.

Inside GPU Mode the trigger for the issue to appear is increasing any side of the GroundCube object above 8. Currently in the the reproducer project it is 8.1x8x8.

From support I received already a reply and they couldn't reproduce it on comparable hardware.


As the attachment failed, here an external share of the same file (will expire after 10 days): https://limewire.com/d/l6Vu6#P3SfpOQggr
Reply
#8
By changing the sizes of Cube and GroundCube various combinations of correct collisions and tunneling can be produced. I tried a few and am currently in contact with Obi support and will for now continue there by email with them. For example with GroundCube={8.1,8,8}, Cube={1,1,1}  fails to collide and Cube={7.9,7.9,7.9} fails to collide, while Cube={8,8,8} (or larger) collide correctly.
Reply
#9
I found an acceptable workaround for my scene now by just increasing the size of all objects 10m into the ground. That's invisible in my scene and works fine. So from my point of view the issue is solved.

While I experimented further earlier, I also saw the problem when making both objects in the small reproducer, Cube and GroundCube, static and removing the (physics) RigidBody. So gravity and movement is not a factor.
Reply