21-08-2020, 08:19 AM
(This post was last modified: 21-08-2020, 08:26 AM by josemendez.)
Hi there!
Getting this to run in realtime using a particle-based engine is a challenge to say the least. If I understood correctly, the space around cells (interstitial?) is filled with fluid, but in many cases the gap is so thin you'd need crazy high resolution (very small particles) to accurately model it. Also, the inside of the cell is filled with fluid too, so the entire scene is represented by particles.
Going 3D instead of 2D adds to the challenge, as it is many times more expensive. The cost of the simulation grows proportional to the amount of particles, so if you need -say- 10.000 particles to fill one square unit (100x100), you'd need one million (100x100x100) to fill one cubic unit. That's a lot. Current state of the art in GPU based PBD simulations (Nvidia Flex) can simulate comfortably up to around 65.000 - 80.000 particles, more than that starts to be a problem.
In short, this is a significant amount of work (months, if not years), and completely out of Obi's reach. I'd recommend looking for a customized solution, that can benefit from shortcuts/optimizations specific to your use case. It would also be beneficial to consider alternative, non fully lagrangian (not fully particle-based) simulation methods. I'm talking about MPM/FLIP/PIC. These use a combination of grids/particles, where equations are solved on a grid, and quantities transferred to particles for advection. This allows for less numerical dissipation and way more particles in the simulation, as particles do not directly interact with each other (see this for an example: https://www.youtube.com/watch?v=z2ASmsHRMpc). It also lends itself well to elastic/viscous behavior. It's not unconditionally stable like XPBD (the method used by Obi), but in your case this is not a showstopper as very high velocities or violent motions are not expected.
Doing this kind of simulation on the GPU is not always immediately beneficial. Running anything on the GPU has a high fixed cost. If your simulation is small enough, it will run slower in the GPU, up until you reach a given amount of particles and CPU performance starts to degrade. In addition to this, the GPU is already quite busy with rendering tasks in a typical game. For these reasons, in many games where simulation is not the main feature it's better to use the CPU. Not in your case though, as simulation is the focal point of the project and you can probably get away with very simple rendering, so if possible this should be implemented in the GPU.
The author of the video in the link above, Grant Kot, is an expert in MPM so he might be able to give you advice.
Let me know if I can be of further help,
Getting this to run in realtime using a particle-based engine is a challenge to say the least. If I understood correctly, the space around cells (interstitial?) is filled with fluid, but in many cases the gap is so thin you'd need crazy high resolution (very small particles) to accurately model it. Also, the inside of the cell is filled with fluid too, so the entire scene is represented by particles.
Going 3D instead of 2D adds to the challenge, as it is many times more expensive. The cost of the simulation grows proportional to the amount of particles, so if you need -say- 10.000 particles to fill one square unit (100x100), you'd need one million (100x100x100) to fill one cubic unit. That's a lot. Current state of the art in GPU based PBD simulations (Nvidia Flex) can simulate comfortably up to around 65.000 - 80.000 particles, more than that starts to be a problem.
In short, this is a significant amount of work (months, if not years), and completely out of Obi's reach. I'd recommend looking for a customized solution, that can benefit from shortcuts/optimizations specific to your use case. It would also be beneficial to consider alternative, non fully lagrangian (not fully particle-based) simulation methods. I'm talking about MPM/FLIP/PIC. These use a combination of grids/particles, where equations are solved on a grid, and quantities transferred to particles for advection. This allows for less numerical dissipation and way more particles in the simulation, as particles do not directly interact with each other (see this for an example: https://www.youtube.com/watch?v=z2ASmsHRMpc). It also lends itself well to elastic/viscous behavior. It's not unconditionally stable like XPBD (the method used by Obi), but in your case this is not a showstopper as very high velocities or violent motions are not expected.
Doing this kind of simulation on the GPU is not always immediately beneficial. Running anything on the GPU has a high fixed cost. If your simulation is small enough, it will run slower in the GPU, up until you reach a given amount of particles and CPU performance starts to degrade. In addition to this, the GPU is already quite busy with rendering tasks in a typical game. For these reasons, in many games where simulation is not the main feature it's better to use the CPU. Not in your case though, as simulation is the focal point of the project and you can probably get away with very simple rendering, so if possible this should be implemented in the GPU.
The author of the video in the link above, Grant Kot, is an expert in MPM so he might be able to give you advice.
Let me know if I can be of further help,