07-05-2024, 07:36 AM
(This post was last modified: 07-05-2024, 08:05 AM by josemendez.)
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 crash, 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 as the system detects the GPU has been working on a task for too long. 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:
![[Image: Opsltpw.png]](https://imgur.com/Opsltpw.png)
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:
![[Image: DBRKtQS.png]](https://imgur.com/DBRKtQS.png)
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 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.
The default values for every setting (max chunks, voxel size, blueprint resolution) work well with each other, even if you modify them a bit. However modifying one of them by order of magnitude or more -as in your use case- will require adjusting the others.
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 asynchronously retrieve the amount of chunks used by your particular scene, to give a better idea of utilization percentage even if it's not entirely accurate.
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,
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 crash, 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 as the system detects the GPU has been working on a task for too long. 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
Quote:A good starting value for the voxel size is the size of your fluid particles. You can check the size of a particle in the info bubble that appears at the bottom of your fluid blueprint's inspector.
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.
(07-05-2024, 06:10 AM)spikebor Wrote: This is a very important part that will crash Unity if not properly set, so I suggest: when the Emitter detect user give it a very big particle count blueprint, can show a big red warning box telling user must scale the max Surface Chunks accordingly, or even better, suggest a value to set.
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 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.
The default values for every setting (max chunks, voxel size, blueprint resolution) work well with each other, even if you modify them a bit. However modifying one of them by order of magnitude or more -as in your use case- will require adjusting the others.
(07-05-2024, 06:10 AM)spikebor Wrote: Also, in PlayMode the Solver only show Chunks and memory we set, not the Chunks and memory we used up.
Suggest adding to the display used up Chunks / set Chunks .
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 asynchronously retrieve the amount of chunks used by your particular scene, to give a better idea of utilization percentage even if it's not entirely accurate.
(07-05-2024, 06:10 AM)spikebor Wrote: Window Build test: 20ms for this pool, optimization tips please?
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.
(07-05-2024, 06:10 AM)spikebor Wrote: Btw, the pool is there, I'll move next to scripting buoyancy, if you please can give some demo code about adding force based on character volume displacement inside the Fluid that would be big help!
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,