In the past, the fluid's bounding box/AABB determined the number of grid
cells but that has been removed in the current implementation. Its only
really there for testing, or if you intend to use the full extent of the grid.
The grid size is by design dependent on the smoothing radius and simulation
scale, as the grid's main purpose is to accelerate the distance calculation
between SPH particles.
The first cause that comes to mind is the fluid-rigid interaction. The current
method tries to take of advantage of both the fluid's grid as well as the rigid
body broadphase. It first converts the entire rigid body's AABB into grid cells
and then performs a binary search for each of those grid cells to find potentially
colliding particles. Next, if the rigid is compound or concave, each fluid particle
is tested against the rigid's midphase. The issue is that if the rigid body has a
very large AABB relative to the particles, then the algorithm would perform a
very large number of binary searches.
grid.forEachGridCell(rigidMin, rigidMax, particleRigidCollider);
with something like (not sure if the function names are correct, see btFluidSortingGrid.h)
for(int i = 0; i < grid.getNumGridCells(); ++i)
const btFluidGridIterator& FI = grid.getGridCell(i);
particleRigidCollider.processParticles(FI, btVector3(), btVector3());
to skip the grid-AABB test. If there are other, small rigid bodies in the simulation,
it would probably be best to add a branch that checks whether the rigid body has
a relatively large AABB and use the for loop above only for that case.
That may not solve the issue though, as the sphere-trimesh collision algorithm is
slow by nature. How many particles are in the simulation? How many triangles
does the mesh have? Even using, say, 4000 particles, on a simple heightfield mesh
of 300 triangles would be fairly slow.
If the mesh's triangles are directly being used for collisions, it could greatly help
performance to use convex decomposition to approximate the mesh with a group
of convex hulls(see the HACD demo?). With particles that are much smaller than
the mesh, the approximation would not be noticeable.
If you do not mind using an even more unstable codebase, there is also a work in
progress Bullet3 fork(https://github.com/rtrius/bullet3
), which runs entirely on the
GPU, but it is far from complete. For example, it is currently not possible to add or
remove particles while the simulation is running.