Obi7 | I made a pool

[spikebor]

Hi!

The issue is not the amount of particles, but the amount of surface chunks you're using. If you need half a gigabyte worth of memory to avoid a swapchain, that means your surface voxel size is tiny. Under the hood this will force every voxel to traverse the entire chunks hash table to find an empty chunk to use, which may take several seconds per frame in some cases leading to a swap chain crash. Your solution of increasing the amount of max surface chunks will make the hash table larger, avoiding excessive waiting time but at the cost of a large amount of memory.

The likely cause is that you've reduced particle resolution a lot to have a large pool, but kept the default small voxel size which would be way too small for meshing a 20x10x3 volume.

The manual suggests using a voxel size that's about the size of your particles. Note this will only land you in the ballpark of a good value, as you may have particles of different sizes in your solver, or you might need more/less surface detail depending on your use case:
http://obi.virtualmethodstudio.com/manua...ering.html


I made a test using a blueprint resolution of 0.02: this is the wireframe view of only 200 particles with a voxel size of 0.08. As you can see the mesh is so dense you can barely tell individual triangles apart:



This is with voxel size set to 0.2 (slightly less than the particle size, which is 0.36). This doesn't require more than the default 32k chunks, for a pool similar to the one in your screenshot:



Note all sizes (particle sizes, voxel size, etc) are expressed in meters, as usual in Unity.


Surface chunk count is not related to the amount of particles at all. It depends on the surface area of the fluid, which in turn depends on the kind of scene you're simulating. If you're making a big sphere of fluid in zero-gravity, the surface area will be small even if you use many particles. If you're making a waterfall with many isolated particles moving around, the surface area will be large even if you use few particles. As such, it's not possible to give an accurate estimate of the amount of surface chunks you should use as the system does not know what kind of scene you're making. It's up to the user to balance memory consumption vs performance, and adjust the amount of memory allocated for chunks as needed.


This would require reading chunks back from the GPU, which is a very expensive operation. We will likely add a debug mode of sorts, that allows to optionally retrieve the amount of chunks used by your particular scene, to give a better idea of utilization percentage.


Using Unity's GPU profiler is always a good idea. However in this particular case, just increasing your voxel size should considerably improve performance as surface meshing is sure to be your bottleneck.


Buoyancy is fully automatic. When you submerge a rigidbody in the fluid, it will sink (or float) based on the mass of the rigidbody vs the density of the fluid. You only need to adjust the fluid blueprint's density and/or your rigidbody mass.

kind regards,

Thanks for the answers!
Yes, the editor only debug mode for chunk used will be helpful!
Also, I suggest draw a small 2x2 grid cube with the size of each cube = the voxel size in scene view when select the Emitter will also visualize it better for user to adjust it.

I adjust the voxel size to 0.2 relation to particle size 0.34, now I can have 16k particles with just 3000 surface chunks (8.5mb)! 
Great save!



The pool now cost only ~2.4ms in build (2.6 because printscreen stutter). Super speedy now!



I know that Buoyancy is automatic, as all particle collisions in Obi world. that's big reason I move all my gameplay code toward Obi solutions.
But still need some custom coding in some area, for example, an airplane will not just sink if it is rotated side way in Tears of the Kingdom, it will rotate about to either face up / face down for the player to have a better area to stand on when player crashed the airplane into water, not realistic physics but a quality of life for the player.
I think that is some adjustment force to try to maintain a target rotation of the object. Or some object material that have more buoyancy force multiplier than others.

Currently my pool with particle size 0.34, with mass =2kg. It cannot add enough buoyancy force to pull the orange plate (20kg) up when it sank. But when it on the surface of water, it does not sink.
I then try with a massive mass=20kg each particle, now I can see the buoyancy force more clearly when I drag it down, it will be violently pulled up and jump up the air. But when I drag it all the way down to the bottom of the pool, it just lay there. Is this the expect behavior?