It is hard to make out what we see in this screenshot. To see the collision field, it must first be created by converting the geometry to VDB or using the SOP Collision Source tool to do so.
My question is this option seems to visualize the "collision result" (field?)
I'd like to visualize the collider itself. I suppose FLIP solver converts the Static Object's mesh to a volume, right? I'd like to visualize that volume, not the result after collision detection or something, just the collider.
On the Static Object DOP, turn off Display Geometry, and in the Collisions tab > RBD Solver > Volume > enable Collision Guide.
What alexwheezy was saying is that you generally want to build the collision volume (in SOPs) yourself, in which case in the Static Object DOP, you would set the Mode to Volume Sample, and under Proxy Volume, point it to your collision VDB, and keep the SOP Path blank (or point it to your collision polygon geo if you want to display the actual geometry rather than the SDF).
eikonoklastes On the Static Object DOP, turn off Display Geometry, and in the Collisions tab > RBD Solver > Volume > enable Collision Guide.
What alexwheezy was saying is that you generally want to build the collision volume (in SOPs) yourself, in which case in the Static Object DOP, you would set the Mode to Volume Sample, and under Proxy Volume, point it to your collision VDB, and keep the SOP Path blank (or point it to your collision polygon geo if you want to display the actual geometry rather than the SDF).
I see... I'm trying this, but I've got another related question about this Proxy Volume.
I've set it like this, where "FLIP_CONTAINER" is a volume (generated by Collision Source SOP's second output).
However, changing "Uniform Divisions" still affects the collision detection significantly. From its description, I thought Uniform Divisions decides the voxel resolution for the mesh to volume conversion. But I'm already using a proxy volume. Why does Uniform Divisions still make a difference?
You need to set the Mode to Volume Sample for it to use the Proxy Volume.
This UI could definitely use some clean-up. It's not exactly intuitive, even after reading docs. It's just something you eventually pick up after seeing other people do it.
I would add - in your screengrab, you're using a 0.001 particle separation, and a grid scale of 1.0, which means your FLIP grid voxel size is also 0.001... then you're overriding the collision field resolution to 0.2 voxel size, so your FLIP collision field will be sampling any collider source into a field that is 200x more coarse than your sim resolution. Your colliders likely won't resolve at all like that. (More accurately 200^3x, so one collision voxel for every 8 million sim voxels)
Don't tick the override, and it'll just auto-match the collision field res to the same res as the rest of the sim fields.
Also, probably don't reduce grid scale to 1.0... the default of 2.0 gives you 8 particles per voxel, which is a pretty well-tested default trade-off of resolution vs. sim performance... 1.0 means you're getting 1 particle per voxel, which is either making your grid solve too dense and slow, or your particle cloud too sparse to get a good mesh at the end.
VortexVFX I would add - in your screengrab, you're using a 0.001 particle separation, and a grid scale of 1.0, which means your FLIP grid voxel size is also 0.001... then you're overriding the collision field resolution to 0.2 voxel size, so your FLIP collision field will be sampling any collider source into a field that is 200x more coarse than your sim resolution. Your colliders likely won't resolve at all like that. (More accurately 200^3x, so one collision voxel for every 8 million sim voxels)
Don't tick the override, and it'll just auto-match the collision field res to the same res as the rest of the sim fields.
Also, probably don't reduce grid scale to 1.0... the default of 2.0 gives you 8 particles per voxel, which is a pretty well-tested default trade-off of resolution vs. sim performance... 1.0 means you're getting 1 particle per voxel, which is either making your grid solve too dense and slow, or your particle cloud too sparse to get a good mesh at the end.
Grid size of 2 makes my fluid just run pass through collider tho. Grid size 0.5 seems to work but it's very slow as you said. (I've turned off collision separation)
Grid size of 0.5:
Some particles still went pass through the collider, but overall looks okay-ish.
Grid size of 2:
I'm not even sure why grid size affects collision detection. I thought collision detection happens on particles and grid is to maintain the volume, but I seem to be wrong.
FLIP fluids have two kinds of collision "detection" - the main one is a collision volume field that directly alters the pressure projection of the sim to correctly flow around objects, so that's acting explicitly on the grid solve part of the sim. Then you've got an entirely optional "particle pushout" step, which is what the FLIP solver's Particle tab collision detection refers to. That's effectively just a fix-step to correct for when the substepping isn't enough to stop particles creeping inside colliders, and shouldn't be the primary means of collision detection, as it doesn't correctly adjust the fluid dynamics.
It's generally best to just leave the grid res at the default of 2x particle separation, and leave the collision field matched to it too... the key is understanding what it's doing, and planning and setting up your colliders accordingly.
Because FLIP collisions are entirely driven by a signed density field, you need to make sure all your collision objects are at least 3 voxels thick (ideally more like 6-8, especially if it's a moving collider), or fluid will indeed leak through. Trying to get fluid to accurately collide with very thin colliders will ultimately just lead to frustration - for example, if you're pouring water into a thin-walled wine-glass, maintain the interior surface, but extrude the exterior surface much thicker.
It also helps to not rely on Houdini's automatic collision volume generation, and to instead use the Volume Source DOP to import your own collision volume/VDB directly from SOPs, where you can take the extra step of making sure you set the same exact voxel size as the sim's grid resolution, otherwise you're effectively resampling one resolution SDF into another, and smearing details in the process.
eikonoklastes One more thing you probably want to do is scale your whole scene up, so you don't have to work with absurdly high values just to get the sim to work.
What's a more "typical" particle size for small scale FLIP simulation? Like pouring water out of a box, not sailing on the ocean.
The FLIP solver works pretty well at any scale. You can fiddle with the Spatial Scale value under the Solver tab to adjust some solver tolerances, but I've rarely found it's necessary unless you're getting down to super-tiny levels. I think one of the tolerances it affects is that particle-pushout-collision I mentioned before, so if you get some odd jumpy behaviour near to colliders, it might be down to the spatial scale setting.
The main thing, again, is to try and get an understanding of what effects your scene scale has on the solver, and plan for it. Small-scale fluids are perfectly viable at a 0.001 particle separation, but you're going to have to accept the need for plenty of substeps, assuming you're applying realistic gravity and want a non-slow-motion result.
I don't personally like relying on CFL conditions, as I find the behaviour of the solve changes too much as it shifts between different step rates (especially the jump between 1 and 2 substeps)... so I like to rough out the calculations myself in advance and lock it down to a fixed rate - FLIP will always work best when particles aren't moving more than 3-4 voxels per substep, ideally with the main bulk staying around 1-2 voxels per substep max, so try to estimate what distance the fastest say-5% of your fluid is going to be moving in a typical frame, and divide it down by 3-4x the voxel size to get a good substep number, and set that as the min and max value. I often find small scale fluids will need at least 8 substeps, and can often benefit from double or quadruple that.
Oceanic-scale sims can almost always get by with a max substeps of 1.
(Edit: Also consider the substepping with regards to the collider thickness I mentioned earlier... if a particle is travelling 5 voxels in a single substep, and your collider is only 3 voxels thick, the particle advection step is clever enough to still attempt to "steer" particles around a collider using its own adaptive advection substepping, but worst-case scenario is that a particle could very well jump from one side of a collider to the other in a single step.)
