Liquid sim: phantom velocities

[tysonibele]

In my production scene, increasing the substeps actually makes the problem worse (instead of little pockets of phantom velocities, I get giant bubbling/exploding areas)....and changing the scene scale "works" until you re-adjust gravity to match and then the problem is identical to before. So as far as my own scenes go, there isn't a workaround. I guess we will keep waiting

Edit: actually I take that back, while double-checking the increase substep workaround, it seems the extra velocities I was experiencing are caused by liquid consumption (wetting) in my particular scene. When I disable that, the sim is relatively stable. So I guess there is a workaround for the time being. Thanks!

[Svetlin.Nikolov]

Huh, this sounds like something else that has higher chance of getting fixed - is it possible to get only the simulation-specific part of that scene here or at support at chaosgroup dot com?

Indeed, scene scale and gravity are pretty much the same thing - it's just about the relative velocity that gravity introduces at each simulation step, and the incorrect compensation for it..

[tysonibele]

I'm not sure if this particular instance is a bug, tbh...looking closer at it, it seems like more steps = more consumed liquid = the liquid on top falls further = more velocity is introduced into the sim. So in this particular scene at 1 substep I was getting a nice little pond with some bubbling on the surface, and at 10 substeps it turns into a giant frothing whirlpool, but if I run the sim long enough it seems the frothing is just a result of all the extra liquid draining out and causing things to stir around.

[tysonibele]

Checking in again: ran the sim on my production scene without wetting consumption on and substeps at 10, and while it was stable for a while, it still bubbles later on. Not as badly as it does with substeps at 1, but badly enough that the renders will require a fair amount of paint-outs in comp.

It's a sim that runs at about 2 mins per frame and I'm simming 500 frames so that's why it took a while to notice the bubbling again (it didn't start until about frame 150 with 10 substeps, whereas it started almost immediately when substeps are at 1). So the substeps workaround doesn't prevent it, just keeps things smooth for a bit longer.

One thing that might be nice, that could potentially be simpler than you modifying your core FLIP algorithm: allow users to adjust FLIP particle velocities in your Phx script API, the same way we can modify cell velocities. That way I could just clamp positive z-axis velocity values of FLIP particles to prevent the fast upward moving velocities that are causing the bubbling (and it would be nice to have particle exposure in the script API regardless).

[Svetlin.Nikolov]

Hmm, could a Particle Tuner have the same effect? You could use the velocity along Z as a condition and then reduce it, possibly with some buildup time. You could also plug the distance to the geometry containing the fluid in the condition and suppress only velocities which are close to it?

[tysonibele]

Oh cool, didn't know about the Particle Tuner. I'm still using 3.x as my main...maybe it's time to go full 4

[Svetlin.Nikolov]

Please ping me if you've got any issues. It would be great to revisit the script at some point as well - a human being hasn't set foot in that code for a good 5-6 years...

[tysonibele]

So Particle Tuner is a no-go. If I clamp upward velocities, the pressure solver pushes things horizontally, so instead of bubbling I get weird rings of foam/velocity appearing where the bubbling used to. If I clamp all velocities, the sim runs like molasses. If I clamp upward/all velocities only near the collider object (using the 'and' condition in the tuner to clamp velocities only within surface proximity), I get get even worse explosions of foam and velocity for some unknown reason (literally giant bubbling masses 10x the size of previous bubbles that appear from nowhere, starting just beyond the perimeter of cells that I clamp with the tuner). So the pressure solver really doesn't seem to like artificial overrides.

The "A_Freeze" command in the script operator has no effect on a liquid sim, so I can't manually freeze the cells I want (I figured if the pressure issue is related to partially-covered cells, I could simply freeze the entirety of the cells to fix it).

Then I had the idea of using tyFlow to generate voxel particles inside of my collider, at the exact size and location of each Phoenix grid cell (so that no "partial cell coverage" occurs)....converting them to mesh, deleting the interior faces, and then welding all of the external faces...so I have a contiguous collider object whose mesh has full coverage over the cells I want with no overlap....using that as my collider literally explodes the whole sim. Like, after a few frames the entire thing turns into a giant churning whirlpool.

So something in the pressure solver is fundamentally broken.

It would be really nice if there were just a simple way to point to a cell and turn it solid. The jammed bounds of the Phoenix container do not generate these phantom velocities so clearly there is a way for the sim to recognize and properly-assess a cell boundary...but as it stands, the current mesh collision system is not working.

Here is a vid of my results using the exact-cell-size geometry collider mentioned above. Notice the calm pool of fluid resting on the container bounds, compared to the frothing rapids resting on the static collider with random foam particles literally being launched into the air for no reason.

http://www.tysonibele.com/Junk/badwater_01.mp4

Anyways, I guess at this point I'm just ranting

[Svetlin.Nikolov]

Oh wow, yes, poking the solver can escalate since it's far from clean and modular yet. I stuck with my initial decision that I would not scrap the thing and rewrite it from scratch, but we will gradually substitute it while it's working up to its abilities. The good thing about it is that its abilities slowly increase while bad ideas dissipate and old code goes away, but doing it in parallel with integration and bugfixes means that it takes so much longer that I often question if it would have been a bad idea saying "we are not going to add or fix anything for the next 3-4 months" while we build a new modular FLIP solver. I hope to be able to spend more time on the solver at some point soon, depending on whether outside factors allow me to...

[olika]

any development news to this issue?

it seems all threads i can find with boiling, calm surface and so on,
just end without a proper fix to this issue.

I'm fighting with it again right now, started a thread yesterday:
https://forums.chaos.com/forum/phoen...latest-nightly