Help Mixing Fluids

[josemendez]

got it, one more thing is that the performance is taking a very big hit, I am using the burst renderer as pointed out in the tutorial on youtube and turned vsync of , used late update....

Hi!

Burst is not a renderer, but a compiler used by Unity to turn C# code into extremely performant native code. Obi offers the Burst backend, which is a physics engine backend that uses the Burst compiler. If you're using the Burst backend, make sure you've disabled the debugger as stated in the manual:

http://obi.virtualmethodstudio.com/manua...kends.html

Otherwise performance will be very poor. Disabling VSync or using LateUpdate have nothing to do with Burst.

performance is around 18 FPS on a gtx 1080

Obi runs 100% on the CPU, so which GPU you're using has basically no impact on performance.

[khanx078]

Hi!

Burst is not a renderer, but a compiler used by Unity to turn C# code into extremely performant native code. Obi offers the Burst backend, which is a physics engine backend that uses the Burst compiler. If you're using the Burst backend, make sure you've disabled the debugger as stated in the manual:

http://obi.virtualmethodstudio.com/manua...kends.html

Otherwise performance will be very poor. Disabling VSync or using LateUpdate have nothing to do with Burst.


Obi runs 100% on the CPU, so which GPU you're using has basically no impact on performance.

Hey yeah i followed the manual so the pc my frame rate jumped to around 31 , but on mobile its like 12 fps , was this asset meant to used on mobile devices ? If so what can i do to make it run smoothly on mobile, currently I have a very simple scene with only 2 colors mixing but still 12 fps

[josemendez]

Hey yeah i followed the manual so the pc my frame rate jumped to around 31 , but on mobile its like 12 fps , was this asset meant to used on mobile devices ?

Yes, this is meant to use in mobile devices and has been used in a lot of projects. 31 fps on a desktop computer is terrible performance though, for typical use cases you should be getting around 120-150 fps on a fairly regular CPU (i5 or similar). On a mobile device performance can vary a lot, depending on your specific device. Hitting 60 fps in an iPhone 7-8 should be no problem, for a moderate amount of particles (800-1500).

If so what can i do to make it run smoothly on mobile, currently I have a very simple scene with only 2 colors mixing but still 12 fps

What are your solver settings, fluid blueprint settings, updater settings, fluid rendering settings, etc? The amount of colors has no impact on performance whatsoever.

I'd advise to profile your game. This will tell you exactly what's taking up so much time, so we can decide what should be tweaked. I can help you interpret your profiling data if you need.

kind regards,

[khanx078]

Yes, this is meant to use in mobile devices and has been used in a lot of projects. 31 fps on a desktop computer is terrible performance though, for typical use cases you should be getting around 120-150 fps on a fairly regular CPU (i5 or similar). On a mobile device performance can vary a lot, depending on your specific device. Hitting 60 fps in an iPhone 7-8 should be no problem, for a moderate amount of particles (800-1500).


What are your solver settings, fluid blueprint settings, updater settings, fluid rendering settings, etc? The amount of colors has no impact on performance whatsoever.

I'd advise to profile your game. This will tell you exactly what's taking up so much time, so we can decide what should be tweaked. I can help you interpret your profiling data if you need.

kind regards,

Maybe i am doing something wrong , I will attach the settings here , thanks for your fast responses I appreciate it alot, here are my settings please check the attachments

[josemendez]

Maybe i am doing something wrong , I will attach the settings here , thanks for your fast responses I appreciate it alot, here are my settings please check the attachments

There's nothing wrong with your settings that I can think of.

Some pitfalls I've seen:
- Having a solver added to more than one updater. This will perform the solver simulation twice (well, once per updater) making everything a lot slower.
- If having more than one solver, using a separate updater for each. This will simulate each solver sequentially, wasting a lot of multithreading potential.

Other than that, I think we will need to a take a look at your profiler window to figure out what's going on. Could you share a pic of your profiler in timeline mode?

[khanx078]

There's nothing wrong with your settings that I can think of.

Some pitfalls I've seen:
- Having a solver added to more than one updater. This will perform the solver simulation twice (well, once per updater) making everything a lot slower.
- If having more than one solver, using a separate updater for each. This will simulate each solver sequentially, wasting a lot of multithreading potential.

Other than that, I think we will need to a take a look at your profiler window to figure out what's going on. Could you share a pic of your profiler in timeline mode?

Here is the profiler screenshot,

[josemendez]

Here is the profiler screenshot,

Hi,

There seems to be a disproportionate amount of time being spent in collision detection/resolution. Pretty much all of the frame is spent on either collision detection or particle rendering, simulation isn't even visible.

What does your scene look like? How many colliders are there in it, and what kind of colliders? How many particles are there in your solver? (the solver component has a small info box at the top that will tell you the amount of particles currently being simulated)

kind regards,

[khanx078]

Hi,

There seems to be a disproportionate amount of time being spent in collision detection/resolution. Pretty much all of the frame is spent on either collision detection or particle rendering, simulation isn't even visible.

What does your scene look like? How many colliders are there in it, and what kind of colliders? How many particles are there in your solver? (the solver component has a small info box at the top that will tell you the amount of particles currently being simulated)

kind regards,

I have a total of 2 colliders in the scene ( both mesh colliders with obi colliders) and an obi rigid body, the number of particles is 3000 in total, currently the scene is a simple bucket in which 2 colors are poured( 2 emitters) then with the help of a mixer ( which has a collider) I mix those colors to get a new one

[josemendez]

I have a total of 2 colliders in the scene ( both mesh colliders with obi colliders) and an obi rigid body, the number of particles is 3000 in total, currently the scene is a simple bucket in which 2 colors are poured( 2 emitters) then with the help of a mixer ( which has a collider) I mix those colors to get a new one

MeshColliders are by far the most expensive type of collider. They get more expensive the more triangles they have, and the smaller the triangles are in comparison to the objects colliding against it. They get even more expensive if they're dynamic, and even more if they're concave.

To understand why this is the case: somehow, each object in the scene (in Obi's case, the fluid particles) must collide against all triangles in each MeshCollider. In your screenshot with only the bucket visible, Unity reports +60000 triangles being rendered. A brute force approach (test all particles against all triangles) against 60000 triangles would result in 60000x3000 = 180 million particle/triangle intersection tests per simulation step, and there's usually more than 1 simulation step per frame. This is intractable even for simple scenes.

So usually, the brute force approach is not used: a spatial subdivision approach is used to quickly prune triangles and cut down the amount of tests. Obi uses a BIH (bounding interval hierarchy) for this. At startup, all triangles in each MeshCollider is inserted into this structure, at runtime particles traverse it to cut down the number of tests to only the triangles that are close enough to each particle. However the smaller the triangles are, the more triangles each particle needs to test regardless. In a detailed MeshCollider, this can mean 10-20 tests per particle, which is still an awful amount of work for such a complex collider.

The takeaway message is that MeshColliders should only be used for low-poly objects, and even then they should be used sparingly. This applies not just to Obi, but to games in general, and those made with Unity in particular: https://docs.unity3d.com/Manual/class-MeshCollider.html

The benefit [of MeshColliders] is that you can make the shape of the Collider exactly the same as the shape of the visible Mesh for the GameObject, which creates more precise and authentic collisions. However, this precision comes with a higher processing overhead than collisions involving primitive colliders (such as Sphere, Box, and Capsule), so it is best to use Mesh Colliders sparingly.

Obi offers a much faster alternative to MeshColliders: signed distance fields. The cost of colliding against SDFs is comparable to a primitive collider (box, sphere or capsule).

My advice would be to replace both your MeshColliders with distance fields, or with compound colliders made of primitives (boxes/capsules).

[khanx078]

MeshColliders are by far the most expensive type of collider. They get more expensive the more triangles they have, and the smaller the triangles are in comparison to the objects colliding against it. They get even more expensive if they're dynamic, and even more if they're concave.

To understand why this is the case: somehow, each object in the scene (in Obi's case, the fluid particles) must collide against all triangles in each MeshCollider. In your screenshot with only the bucket visible, Unity reports +60000 triangles being rendered. A brute force approach (test all particles against all triangles) against 60000 triangles would result in 60000x3000 = 180 million particle/triangle intersection tests per simulation step, and there's usually more than 1 simulation step per frame. This is intractable even for simple scenes.

So usually, the brute force approach is not used: a spatial subdivision approach is used to quickly prune triangles and cut down the amount of tests. Obi uses a BIH (bounding interval hierarchy) for this. At startup, all triangles in each MeshCollider is inserted into this structure, at runtime particles traverse it to cut down the number of tests to only the triangles that are close enough to each particle. However the smaller the triangles are, the more triangles each particle needs to test regardless. In a detailed MeshCollider, this can mean 10-20 tests per particle, which is still an awful amount of work for such a complex collider.

The takeaway message is that MeshColliders should only be used for low-poly objects, and even then they should be used sparingly. This applies not just to Obi, but to games in general, and those made with Unity in particular: https://docs.unity3d.com/Manual/class-MeshCollider.html


Obi offers a much faster alternative to MeshColliders: signed distance fields. The cost of colliding against SDFs is comparable to a primitive collider (box, sphere or capsule).

My advice would be to replace both your MeshColliders with distance fields, or with compound colliders made of primitives (boxes/capsules).

So i created the distance fields and the frame rate was hardly improved its went from 30 to around 37 but drops down abruptly to 27  I have attached the profiler