Help Mixing Fluids

[josemendez]

So do i need to remove the mesh colliders

Distance fields are only used to collide against particles. For all other regular objects in the scene, the MeshCollider will still be used. So the MeshCollider still needs to be present. Quoting the manual:

Distance fields will only generate collisions against Obi particles. They will not collide with other objects, for this you need to use Unity's own colliders.

and there is no option to enable the distance field collision like mentioned in the documents, there I created the distance fields and attached them in the distance field area , but as soon as I hit the play button the mesh colliders gets attached automatically.....

In recent versions, the distance field is used automatically as long as there's a distance field assigned to the ObiCollider. Will correct the manual to reflect this.

Note that DistanceFields can be used for any object, regardless of the type of collider you're using for rigidbody physics. You could approximate your bucket with a capsule collider so that other objects in the scene can collide with it, and still have a distance field for collisions against fluid particles.

[khanx078]

Distance fields are only used to collide against particles. For all other regular objects in the scene, the MeshCollider will still be used. So the MeshCollider still needs to be present. Quoting the manual:



In recent versions, the distance field is used automatically as long as there's a distance field assigned to the ObiCollider. Will correct the manual to reflect this.

Note that DistanceFields can be used for any object, regardless of the type of collider you're using for rigidbody physics. You could approximate your bucket with a capsule collider so that other objects in the scene can collide with it, and still have a distance field for collisions against fluid particles.

It made a difference my frame rate is around 36 now but it suddenly drops down to 27 then jump backs up,   I have attached the profiler ,

[josemendez]

It made a difference my frame rate is around 36 now but it suddenly drops down to 27 then jump backs up,   I have attached the profiler ,

Yes, as you can see in the profiler the time spent in collision detection been reduced from 5ms down to 2.4ms, and collision resolution from 4.38ms to 1.15ms. That's "only" 2.7 times faster

The frame rate spikes could be due to physics being updated more than once during certain frames. Check how many times is FixedUpdate being called during these spikes, if it's more than once, lower your maximum fixed timestep or slightly increase your fixed timestep (both found in Unity's Time settings)

The next bottleneck in your frame is particle mesh generation which takes around 10 ms, or 60% of the frame time. This should usually be much faster, I've tested 3000 particles in a dual core i5 and it takes roughly 3 ms to generate them. What cpu do you have?

Keep in mind that Obi runs in the CPU though. 3000 particles is too much for most mobile devices. Total count should be around 1000-1500 particles for a mid-tier mobile cpu.

[khanx078]

Yes, as you can see in the profiler the time spent in collision detection been reduced from 5ms down to 2.4ms, and collision resolution from 4.38ms to 1.15ms. That's "only" 2.7 times faster

The frame rate spikes could be due to physics being updated more than once during certain frames. Check how many times is FixedUpdate being called during these spikes, if it's more than once, lower your maximum fixed timestep or slightly increase your fixed timestep (both found in Unity's Time settings)

The next bottleneck in your frame is particle mesh generation which takes around 10 ms, or 60% of the frame time. This should usually be much faster, I've tested 3000 particles in a dual core i5 and it takes roughly 3 ms to generate them. What cpu do you have?

Keep in mind that Obi runs in the CPU though. 3000 particles is too much for most mobile devices. Total count should be around 1000-1500 particles for a mid-tier mobile cpu.

can i share the project with you. and What i am trying to create is a mobile game in which there is a paint bucket , we pour colors into it and mix them, then paint different stuff with it 3D. Would this asset be something I can use. let me share some screenshots to get your feedback on it, because I do not want to start if its not possible with the asset , as I am facing alot of performance issues in such a simple scene

[josemendez]

can i share the project with you. and What i am trying to create is a mobile game in which there is a paint bucket , we pour colors into it and mix them, then paint different stuff with it 3D. Would this asset be something I can use. let me share some screenshots to get your feedback on it, because I do not want to start if its not possible with the asset , as I am facing alot of performance issues in such a simple scene

I wouldn't use Obi for this use case at all.

First: using a particle-based simulation of any kind for this is *absolute overkill*. You're only interested in showing how the colors get mixed in the bucket, there's no need whatsoever to have volumetric fluid dynamics simulation: you don't care about pressure, vorticity, surface tension, friction, free-surface interfaces, collision with the bucket walls, etc... so these are just burning a lot of performance for no good reason.

Second: paint mixing does not behave the same way as digital color mixing. When you mix yellow and blue paint in the real world you get green, when you mix yellow and blue colors in RGB you get gray: (1,1,0 + 0,0,1) * 0.5 = 0.5,0.5,0.5. This is how color behaves in most software, including Unity and by extension, Obi.

To accurately approximate paint mixing in a digital setting you must use a more advanced color representation, such as the Kubelka-Munk model or some approximation of it. The Mixbox model is a relatively cheap way of doing this: https://scrtwpns.com/mixbox.pdf

Leaving the color mixing issue aside, if you want to show the swirly motion on the surface of the bucket as the paint gets mixed a grid-based fluid simulator can do it for a fraction of the cost. Our asset FluXY is a good example of this kind of system, though there's many others in the Asset Store that do a similar thing: https://assetstore.unity.com/packages/to...tor-203795

Note that even if you use a fluid simulator of this kind, accurate paint mixing (if desired) is still something that you must implement yourself.

Let me know if you wish for a refund for Obi Fluid, in that case please let send your Invoice Number to support(at)virtualmethodstudio.com so that I can identify your purchase.

[khanx078]

I wouldn't use Obi for this use case at all.

First: using a particle-based simulation of any kind for this is *absolute overkill*. You're only interested in showing how the colors get mixed in the bucket, there's no need whatsoever to have volumetric fluid dynamics simulation: you don't care about pressure, vorticity, surface tension, friction, free-surface interfaces, collision with the bucket walls, etc... so these are just burning a lot of performance for no good reason.

Second: paint mixing does not behave the same way as digital color mixing. When you mix yellow and blue paint in the real world you get green, when you mix yellow and blue colors in RGB you get gray: (1,1,0 + 0,0,1) * 0.5 = 0.5,0.5,0.5. This is how color behaves in most software, including Unity and by extension, Obi.

To accurately approximate paint mixing in a digital setting you must use a more advanced color representation, such as the Kubelka-Munk model or some approximation of it. The Mixbox model is a relatively cheap way of doing this: https://scrtwpns.com/mixbox.pdf

Leaving the color mixing issue aside, if you want to show the swirly motion on the surface of the bucket as the paint gets mixed a grid-based fluid simulator can do it for a fraction of the cost. Our asset FluXY is a good example of this kind of system, though there's many others in the Asset Store that do a similar thing: https://assetstore.unity.com/packages/to...tor-203795

Note that even if you use a fluid simulator of this kind, accurate paint mixing (if desired) is still something that you must implement yourself.

Let me know if you wish for a refund for Obi Fluid, in that case please let send your Invoice Number to support(at)virtualmethodstudio.com so that I can identify your purchase.

Thank you for the help man , No need for  a refund I will put obi to use in some other project , let me have a look at the other assets which you suggested, thanks again

[josemendez]

Thank you for the help man , No need for  a refund I will put obi to use in some other project , let me have a look at the other assets which you suggested, thanks again

You're welcome! Let me know if I can be of further help.