Obi Official Forum
Bug / Crash Overlapping Obi Colliders too much causes the Compute backend to go mental - Printable Version

+- Obi Official Forum (https://obi.virtualmethodstudio.com/forum)
+-- Forum: Obi Users Category (https://obi.virtualmethodstudio.com/forum/forum-1.html)
+--- Forum: Obi Fluid (https://obi.virtualmethodstudio.com/forum/forum-3.html)
+--- Thread: Bug / Crash Overlapping Obi Colliders too much causes the Compute backend to go mental (/thread-4380.html)

Overlapping Obi Colliders too much causes the Compute backend to go mental - Nyphur - 27-09-2024

OK, I have a truly bizarre one for you. 

If you put enough Obi Colliders overlapping in the same place, even fully static box colliders, the Compute backend goes absolutely mental. It has some kind of overflow and starts adding random updraughts of force to particles in random areas, some near the colliders (but not touching) and some nowhere near it. Burst is unaffected.

I noticed it in a game where I have a level made out of modular parts and each Wall has an obi collider. I added some more colliders to the level and noticed that my fluid started randomly jumping up all over place and wouldn't stop. Even with the most aggressive smoothing, the fluid never reached a rest state and just kept jiggling. A ton of trial and error to find out that it's caused by obi colliders just being in the scene and switched on and not even necessarily near the fluid, and then I managed to recreate it by stacking enough colliders in the same spot.


Replication steps:
  • Create a new blank URP project
  • Install Obi Fluid 7.03
  • Launch Faucet And Bucket test scene and fix the scene materials
  • Set the Solver to Compute back-end and the emitter to speed 6 and lifespan 8
  • Edit the fluid blueprint to expand it to 12,000 particles and re-generate it
  • Create a 3D Cube at coordinates Vector3(0.879999876,1.23000002,-2.41999984). Add an Obi Collider.
  • Launch the Scene. Now duplicate the cube in place using Ctrl-D until you get to 16 cubes.
  • When you get to 16 cubes, you'll see obvious jets shooting out of the fluid below and near the cube, and another jet randomly on the far edge of the fluid.
Experimentation:
  • If you disable the obi colliders on the cubes 1 at a time you can see the effect diminish with each one.
  • If you move any of the cubes so that their colliders are no longer overlapping, they no longer contribute to the effect.
  • If you move the group of cubes around or re-scale them all, it changes the characteristics of the random bits of force causing the jets
  • Change the box collider size's y value on all the cubes slowly. When it hits 3, an entire quadrant of particles randomly jumps up in the air. Increase it further to just over 8.0, the effect disappears and everything goes back to normal. 8 world units tall seems to be a magic number, is that the unit size of the collider grid or something?
Expected Result: Not fluid going mental

Observed Result: Fluid going mental

RE: Overlapping Obi Colliders too much causes the Compute backend to go mental - josemendez - 27-09-2024

Hi!

This isn't a bug per se, but a limitation of the Compute backend that has its roots in GPU's (or more accurately, HLSL's) inability to allocate memory dynamically. This means we must allocate a fixed amount of memory, and drop data when we reach that maximum.

Particles in the compute backend have a hardcoded limit of 32 potential contact pairs each. Once you get past this amount of potential contacts, particles will start to randomly drop contacts every frame. This means they may drop their contact against the floor for a few frames, then get launched upwards next frame when they do keep the floor contacts but decide to drop different contacts. Which contacts are dropped and which ones are kept is decided essentially at random, since it depends on the order in which threads are executed as they find and append potential contacts for further processing.

Note that this limit affects potential contacts (not actual contacts/collisions). This is why particles will act up when they're merely near a crowd of colliders, even if they don't touch them.

You can increase this limit by opening up ColliderGrid.compute, near the top you'll see this define:

Code:
#define MAX_CONTACTS_PER_SIMPLEX 32

You can set it to 128 for instance to increase the amount of potential contacts allowed by each particle, at the cost of more memory. I didn't expose this limit in the solver inspector's Memory Budget section (like I did with other memory limits) because we doubted anyone would hit it, but now I see I was wrong  Ángel.

The Burst backend doesn't have this limitation, as it can dynamically allocate more memory if needed.

kind regards,

RE: Overlapping Obi Colliders too much causes the Compute backend to go mental - Nyphur - 27-09-2024

(Yesterday, 10:58 AM)josemendez Wrote: Particles in the compute backend have a hardcoded limit of 32 potential contact pairs each. Once you get past this amount of potential contacts, particles will start to randomly drop contacts every frame. This means they may drop their contact against the floor for a few frames, then get launched upwards next frame when they do keep the floor contacts but decide to drop different contacts. Which contacts are dropped and which ones are kept is decided essentially at random, since it depends on the order in which threads are executed as they find and append potential contacts for further processing.

Note that this limit affects potential contacts (not actual contacts/collisions). This is why particles will act up when they're merely near a crowd of colliders, even if they don't touch them.

Ah-ha, that makes sense! So it splits the game world up into cells and if there are too many potential contacts in a cell it will start to randomly drop contacts, including existing contacts like the floor. That explains why the problem got gradually worse as I added more colliders, increasing the limit to 64 solved my issue. Reading through the ColliderGrid compute shader now, I have a few more questions if you have time:

  1. What counts as a potential contact? Is it an entire collider, or a collider vertex, or a face? would boxcolliders, for example, use up fewer potential contacts?
  2. How does it determine where the grid starts and the size of the grid cells? Is it centered on the Solver, and so should I aim to put the solver in a central location to my level?
  3. Any idea roughly what the memory impact of increasing the contact limit is? And this may be a stupid question but I just want to make sure I'm not getting it wrong, is it storing the data in VRAM or RAM?
The fact that I've hit this limit probably indicates that I may be taking a less than ideal approach to collisions. In my game I have 1 floor collider that spans the entire map and then the corridors made out of modular walls slotted together, where each wall has an Obi collider, and then there are various objects randomly placed that also have Obi Colliders. They're almost all box colliders, with just a few mesh colliders. Do you have any recommendations for optimal approaches to collision to reduce the number of potential contacts?