ObiFluid Tunneling Issue - Collisions - Performance tips - Gaps between particles

[binhong87]

Hello,

I tried your plugin ObiFluid in my project, but encountered these following issues, please provide technical support.

1. I changed collision evaluation method to "sequential", which seems more stable when particle amount increases. Parallel method gets more tunneling issues.
   But the beaker (the mesh collider) still get leaks, when I move the beaker "a little" more heavily. It looks better when moved slowly.
   Can you provide more technical support on addressing this tunneling issue, I saw your documents saying tunneling issue "almost non-existent". :-)

2. The performance gets significantly decreased when particle amount reaches about 2000, only about some 50 fps.
   The CPU usage is about half. Is there any tips on how to optimize the performance?

3. I found that there are many particles stay in the lowest layer, and the others piled up. And there is even a gap between them, when the smoothing is set above 1.0.
   Is it designed this way, or there is some mis-configurations?


Thanks
Bin

[josemendez]

Hello,

I tried your plugin ObiFluid in my project, but encountered these following issues, please provide technical support.

1. I changed collision evaluation method to "sequential", which seems more stable when particle amount increases. Parallel method gets more tunneling issues.
   But the beaker (the mesh collider) still get leaks, when I move the beaker "a little" more heavily. It looks better when moved slowly.
   Can you provide more technical support on addressing this tunneling issue, I saw your documents saying tunneling issue "almost non-existent". :-)

2. The performance gets significantly decreased when particle amount reaches about 2000, only about some 50 fps.
   The CPU usage is about half. Is there any tips on how to optimize the performance?

3. I found that there are many particles stay in the lowest layer, and the others piled up. And there is even a gap between them, when the smoothing is set above 1.0.
   Is it designed this way, or there is some mis-configurations?


Thanks
Bin

Hi Bin,

1.- Moving a MeshCollider by changing its transform is equivalent to teleporting it from frame to frame. No continuous collision detection algorithm exists that can work under these circumstances, since there's no way to predict where the collider is going to move next (it has no velocity). The problem is aggravated by the fact that MeshColliders aren't "solid", but a thin membrane. This means that if a particle gets inside the mesh collider, it cannot be projected outside like it would from a primitive collider (cube, sphere, capsule, etc). 

Continuous collision detection can avoid tunneling in pretty much all cases when: 

- moving particles collide with a non-kinematic rigidbody. Since both the particles and the rigidbody have a velocity vector, Obi can tell where they are going to move in the next frame and act accordingly.

- moving particles collide against a static collider of any kind (including mesh colliders). Most included test scenes take place in an environment made with a MeshCollider, which is paper-thin. However no tunneling issues can be seen there, because the mesh collider doesn't move.

So, general rules for good collisions:

- Dynamic object using a non-kinematic rigidbody: OK
- Dynamic object using transform, has a primitive collider: OK, but no continuous collision detection. Not a problem if the collider is thick enough, since particles inside of it will be projected outside.
- Dynamic object using transform, has a mesh collider: BAD. will miss collisions pretty often, since particles are very small and the collider is a thin membrane.
- Static object of any kind: OK



2.- Try reducing your max physics timestep in Unity. You might be reaching a point where 1 physics step is not enough to simulate each frame, so 2 steps (or more) per frame are being used.


3.- This is completely normal. In particle-based fluids, particles aren't "drops" but small "probes" that carry fluid information (density, vorticity, etc). A single fluid drop can be composed of a single particle or multiple particles, depending on the fluid resolution. They don´t have to touch each other in order to interact. In fact, a larger smoothing radius will cause then to become more separated. Particles tend to accumulate at the bottom to support the weight of the particles on top of them, since more particles = more pressure = it's easier to keep constant density.

If you want your particles to touch each other regardless of their smoothing radius, you can scale the way they are drawn using the "radius scale" property of the ObiParticleRenderer.

I'd recommend taking a look at other particle-based fluid simulations to get a feel of what the concept is. Obi implements PBF (position based fluids), but SPH (smoothed particle hidrodynamics) and MPS (moving particle semi-implicit) are also particle-based and look/behave similarly.

[kisPonyi]

Dear Support,

I'd buy the Fluid asset but I've read about a lot about CPUproblem. is there chance to try the product? I'd save it to WebGL, my fear is that the client's computer cant stand the performance...

Best Regards,
Koppany from Hungary

[popuz]

...
general rules for good collisions:
- Dynamic object using a non-kinematic rigidbody: OK
- ...
- ...

Dear Jose, 

does it mean that it is good to use the FixedJoint for non-kinematic rigidbody drag? I mean, if i take classical included in Unity script "DragRigidbody.cs" and change the Joint to be Fixed instead of Spring Joint. And then I will have closed bottle (with 20 convex mesh-colliders) as non-kinematic rigidbody with obi-fluid inside. Then the fluid will be ok on drag and all water will remain inside bottle? 
I ask it because FixedJoint is also similar to teleport as I can see....

---

Dear Jose,

I want to make simple chemistry game with bulbs, bottles, probes and ect. Which parametres and settings will you advise to me for more stable simulations, supposing all liquids will be just a water. And main mechanics will be the putting water form one bulb to another. I mean settings for Obi Solver, Emiiter and Collision Materials settings.

[josemendez]

Dear Jose, 

does it mean that it is good to use the FixedJoint for non-kinematic rigidbody drag? I mean, if i take classical included in Unity script "DragRigidbody.cs" and change the Joint to be Fixed instead of Spring Joint. And then I will have closed bottle (with 20 convex mesh-colliders) as non-kinematic rigidbody with obi-fluid inside. Then the fluid will be ok on drag and all water will remain inside bottle? 
I ask it because FixedJoint is also similar to teleport as I can see....

---

Dear Jose,

I want to make simple chemistry game with bulbs, bottles, probes and ect. Which parametres and settings will you advise to me for more stable simulations, supposing all liquids will be just a water. And main mechanics will be the putting water form one bulb to another. I mean settings for Obi Solver, Emiiter and Collision Materials settings.

Hi! 

I believe I answered this in a PM, but will post my answer here in case it can help someone else out:

The issue you refer to is quite a common one, that happens in all physics engines. It is known as "tunneling", and is usually dealt with by using "continuous collision detection", or CCD. Obi implements CCD by default, however all CCD algorithms need the velocity of all objects involved in a collision in order to be effective. In your case, changing the container position around is basically the same as teleporting it. It has zero velocity, thus CCD cannot kick in.


There's a sample scene included in Obi called "FaucetAndBucket". There you can see that fluid does not escape the bucket even though you can drag the bucket around quite fast.


This is done by adding a rigidbody to the bucket, and setting its velocity accordingly when dragging it (see the included ObjectDragger.cs script). This way continuous collision detection has a velocity value to work with, and as a result collision detection is much more precise and tunneling happens less often.

Still, at *very* high speeds collisions can be missed. For this reason you should limit the maximum speed at which users are allowed to drag the containers.

[popuz]

...
There's a sample scene included in Obi called "FaucetAndBucket". There you can see that fluid does not escape the bucket even though you can drag the bucket around quite fast.
This is done by adding a rigidbody to the bucket, and setting its velocity accordingly when dragging it (see the included ObjectDragger.cs script). This way continuous collision detection has a velocity value to work with, and as a result collision detection is much more precise and tunneling happens less often.
...

Thanks, Jose. 
Now it became a little bit clearer and you answer will help. However, I have two more qestions:
1) Could I clamp position of the particles in some range? In general, have I some control on their positions?
2) You say: "Dynamic object using a non-kinematic rigidbody: OK". However, colliders are limited to be ONE convex mesh. The limitation is that only ONE mesh collider. I mean, that I can't make complex collision shape by arranging a bunch of simpler convex colliders (which is a classic approach for complex geometry rigidbodies). As example I tried to make a box with open upper part, but water go through (see the picture).... Is it possible to fix?

[josemendez]

Thanks, Jose. 
Now it became a little bit clearer and you answer will help. However, I have two more qestions:
1) Could I clamp position of the particles in some range? In general, have I some control on their positions?
2) You say: "Dynamic object using a non-kinematic rigidbody: OK". However, colliders are limited to be ONE convex mesh. The limitation is that only ONE mesh collider. I mean, that I can't make complex collision shape by arranging a bunch of simpler convex colliders (which is a classic approach for complex geometry rigidbodies). As example I tried to make a box with open upper part, but water go through (see the picture).... Is it possible to fix?

1). Yes, you can modify just about any property of the particles. See:
http://obi.virtualmethodstudio.com/tutor...icles.html

2) Regardless of which type of collider you use, you can always make a compound collider by parenting multiple simpler meshes under one object (unless your use case makes this difficult for some reason). This works nicely (see for instance the FluidMill sample scene, where the mill is modelled as a compound collider)


Regarding the box, did you try to increase its ObiCollider thickness parameter slightly? (0.05, for instance)

[popuz]

1). Yes, you can modify just about any property of the particles. See:
http://obi.virtualmethodstudio.com/tutor...icles.html

2) Regardless of which type of collider you use, you can always make a compound collider by parenting multiple simpler meshes under one object (unless your use case makes this difficult for some reason). This works nicely (see for instance the FluidMill sample scene, where the mill is modelled as a compound collider)


Regarding the box, did you try to increase its ObiCollider thickness parameter slightly? (0.05, for instance)

Thanks Jose! 

I understand why it was wrong with my cube-example - Mass in Rigidbody was too small (as by default equal to 1), and in your  FluidMill example it is 100... So now I will try to understand about my SpringJoint. By the way, what is the mass of one fluid "particle" in Obi (with respect to default 1 in rigidbody)?

Have a nice weekend

[josemendez]

Thanks Jose! 

I understand why it was wrong with my cube-example - Mass in Rigidbody was too small (as by default equal to 1), and in your  FluidMill example it is 100... So now I will try to understand about my SpringJoint. By the way, what is the mass of one fluid "particle" in Obi (with respect to default 1 in rigidbody)?

Have a nice weekend

In general when working with fluids, you don't think in terms of mass, but in terms of density. (mass per volume unit)

The mass of the particles depends on your material rest density, and your material resolution. It is automatically calculated and displayed in the fluid material inspector, both for 3D and 2D fluids.

Fluid density is given in Kg/m3 (kilograms per cubic meter). So, if your material density is 1000 kg/m3 (that of water) and your resolution is 1 (1000 particles per cubic meter), then each particle weights exactly 1 kg in 3D, and 10 Kg in 2D.

If you increase the resolution while keeping density constant, then each particle weights less (since the same mass is now distributed in more particles). Decreasing the resolution makes particles heavier, since they must accumulate more mass to keep the density constant.

let me know if you need further info!

[IgorKovalev]

Hello!

I need to instantiate fluid emitters in runtime but can't do this. After I have instantiated emitter I place it's renderer to Camera's ObiFluidRenderer renderers list but it does not draws anything. Is it possible to instantiate emitters in runtime and what is the right way to do that?

Thank you!