flip collisions & substepping

[meeotch]

The attached file demonstrates the following problem:  there's a translating static object, emitting flip particles from the object & also colliding with it.  Run the file up to about frame 20, and you see that there's a gap in the direction of the translation, even though the collision field is correct.  (Note that the gap is wide in the direction of travel, but nonexistent on the sides of the object.)

Increasing substeps reduces the problem.  (But is also heavier, and changes the look of the sim significantly.)  Which, o.k., that makes sense - the object is moving some amount of distance between substeps...  But why are all the particles clustered in a shell that seems to be halfway between frames?  In fact, if you set "max substeps" on the flip solver to 1, the problem remains, and the particle shell seems to be one frame *ahead*.  Huh?  

Interestingly, changing the collision mode to "Surface Collisions" on the static object produces "correct" results - though again, the look of the sim is different.  Digging through the guts of the flip solver, it seems to be all volume-based collisions - so I'm surprised this works at all.

Assuming that I've got a sim that I'm already happy with, and I just want to force the timestep that the "shell" forms around to be the integer frame rather than the 0.5 frame, is there a fix?  Timeshifting by half a frame after the fact seems to break the collisions altogether.

collisiontest_v001.hip

Edited January 11, 2019 by meeotch

[Atom]

I think that might be a limit of FLIP. There is some invisible boundary. You can get the particles a little bit closer to the collision surface by breaking the reference link on the translate and slightly shrinking the particle emitter.

ap_collisiontest_v001.hiplc

Edited January 11, 2019 by Atom

[Skybar]

It looks like your collision velocities are the problem. New particles in the front immediately collides and gets pushed forward with that velocity. You can test this by setting Volume Motion -> Velocity Scale to zero and it should only collide and flow along, ignoring the collision velocity.

[Atom]

Even if I set Force Scale (I could not locate Velocity Scale) to zero, the particles still refuse to rest on the surface.

[meeotch]

I'm away from my workstation, but I feel like I tried changing the collision velocity scale, as you suggested.  I believe the results were that the particles just ended up going through the geometry, but I'd have to confirm.

My instinct says that it's not a "birth frame" problem, though - all of the particles seem to collect in a shell at the same distance from the collision field.  If it were a problem affecting only just-born particles, I'd think you'd see a mix of particles between the "shell" (just born) and the proper collision (older particles).

[Atom]

I think I might have got it working. I renabled the popkill to keep from generating particles inside the collision sphere and added velocity to the scatter points with a trail.
I reset Force Scale and Velocity scale to their defaults of 1.0.

ap_collisiontest_v001.hiplc

Edited January 12, 2019 by Atom

[anim]

it's mainly because your particles have large f@pscale and the particle collision detection is set to Particle, so they collide as spheres, therefore you see the gap

1. change the Particle Motion/Collision Detection to Move Outside Collision or None to get tighter collisions

2. also you may want to smooth a bit the velocity or switch to Swirly kernel to avoid occasional splashes

here is original file just with those 2 changes, but obviously you can further experiment with adding particle source velocities and other above mentioned things

you can also decrease pscale and still use Particle collision detection, but since pscale is used to compute other things, like for CFL condition, I wouldn't recommend changing them globally, maybe just before collision and change back after (inside of the solver)

collisiontest_v001_fix.hip