Border colissions ignored?
Closed this issue · 22 comments
Open the file from here: https://blenderartists.org/forum/showthread.php?373547-Lets-talk-about-Mantaflow&p=3215074&viewfull=1#post3215074
It has front, back, left and right unchecked, yet still the fluid starts filling the domain.
Oh and another thing I just noticed - when you change the resolution in that file to 128 it goes completely nuts...
Oh yes, I see. Particles seem to hit domain borders that should not exist (i.e. open border).
I just looked at the scene in Mantaflow and found a small issue: setObstacleFlags() from Mantaflow currently sets cells at the domain border (those ones used for fractions) to type "Fluid" instead of "Outflow".
8379725 and 3ee4f50 fix this issue. setOpenBound() now also accepts phiOut as an additional (but optional) argument.
with the latest fixes the file acts weird both with 64 and with 128 resolution (top: 64, bottom: 128):
Looks like too many drop particles. My first impression: Liquid leaves the simulation at the domain sides correctly now and so no volume of liquid builds up.
This also means that there is one "kill" condition less for drop particles (delete inside liquid). And so they just accumulate.
Solution should be to resetOutflow() for drop particles similarly to FLIP particles. That's currently not happening.
Btw: this is how the file simulates now without drop particles enabled - the inflow seems to be way stronger now:
Resolution 64 - https://www.dropbox.com/s/hhcbf6hfvp710cd/64.avi?dl=0
Resolution 128 - https://www.dropbox.com/s/3yn6aiil9dfkc55/128.avi?dl=0
I reduced the size of the emitter (at res 128) and the result is still extreme - it does not look accurate - it rather seems like the particles get multiplied and accelerated when hitting an obstacle...
Interesting comment on BlenderArtists about the settings in the file https://blenderartists.org/forum/showthread.php?373547-Lets-talk-about-Mantaflow&p=3216759&viewfull=1#post3216759
Blend file uses two settings that are always giving me unstable and unpredictable results.
Adaptative stepping : it avoïd particles death and always fills the domain for me.
A radius value different than 1 : Particles may die without logic and have an erratic movement.
After the comment I tried without adaptive stepping, which really helped the result:
And then with particle radius of 1.0, which made things slightly worse again:
It seems like adaptive stepping makes problems :(
Here the result without adaptive stepping and radius 1.0 and a time scale of 0.2:
Yes, since adaptive time stepping just steps "more" for each frame it's like multiplier to this issue. I found that the root cause is probably because of different walls representations. On one hand the "Flag" grid now correctly sets outflow cells, on the other hand there is still the obstacle levelset representation which does not account for that. Going to try to "sync" them now .
The inflow object probably uses an inflow velocity, right?
No that box is unchecked. It is a basic inflow object.
After some experimentation, I am now boiling it down to the following: As long as all domain walls are closed the simulation runs fine for me. Once at least one wall is open, things get out of order.
So ideally, Nils, it would be helpful to have a Mantaflow liquid scene with fraction and additionally open domain support. That is, for example, an adapted version of flip06_obstacle.py where one can set arbitrary open borders.
That would be helpful. Here is also the Mantaflow script from that Blender file (at frame 30):
https://www.dropbox.com/s/29egm9kx6mo9mgy/manta_scene_github_issue_%237.py?dl=0
Btw: this is what I get when I set all borders to collide (with 0.2 time stepping, no adaptive step and 1.0 radius)
Hi,
More testing after commit https://developer.blender.org/rBfeda06e184ff0ebcddf6587a5ddcfba6a78bb78c
Video:
https://youtu.be/bk_sq1myXmM
Best,
Guilliam
Hey @guilliamPL can you run the tests with 128 res as well? Because that was the resolution I ran all my tests in (it seemed like a higher resolution made things worse).
@GottfriedHofmann No problem. Please just send me your .blend file.
@guilliamPL it is the same one as you used with res 128 :)
Regarding the liquid becoming "too fast" issue (as seen in Gottfrieds screenshot #7 (comment)):
The problem might be related to the primary velocity advection: What if, for instance, the domain is declared as open (no walls at all) but instead you manually set six walls with obstacle objects? Advection would then, due to the domain seemingly being open, try extrapolate velocities into outflow cells. However, in reality they don't exist since we placed obstacles at all borders.
I tested the outcome of this scenario with the same "waterfall scene" but changed the following: All walls are declared open and six obstacle objects now surround the domain.
Test 1: Domain open flag (from primary velocity advection) is kept as is. Since walls are open it's automatically set to "True":
Problematic region in red. The liquid looks like it's "flying" away.
Test 2: Domain open flag manually set to "False" (in code). Because of the obstacle objects, we know that the domain should be closed:
Test 2 looks more realistic to me. This open domain flag clearly makes a difference.
@GottfriedHofmann I think #7 (comment) is at least not related to velocities.
Because of the small timestep and the closed domain, there are lots of particles in a small space. They splash against the wall, spread and the resulting mesh therefore looks really awkward.
Adding min / max particle fields (i.e. how many particles per cell allowed) to control the amount of particles might be the solution to this problem.