shrinking / growing / crashing fluid
Opened this issue · 23 comments
hey there, saw the #bcon17 talk and had to try the new fluid for liquid simulation.
I use the Windows 64bit version from graphicall, October 24th, 2017 by LazyDodo. Is there another source for uptodate builds?
These are the first issues I noticed, when I tried a simulation where a object dives up from under the water:
- If using a collision object, the fluid disappears.
- If using a guide object, the fluid grows.
- If using a more complex object (don't know the exact reason) it crahses
all scenes are in the blendfile: link
In generel I saw the problem, that the collision object doesn't lift the water... instead it creates a hole at the surface... which just doesn't look good. Or is there another way, I don't see.
Hey!
Thanks for the detailed bug report! And, yes the build you're using is up-to-date.
I was able to reproduce all the issues - not sure what's exactly causing this though ... I'll be back once I have found something.
just wanted to add that:
The liquid does not have a constant volume with the Adaptiv Stepping. And also it is behaving completely different with and without Adaptiv Stepping.
(Just use the cube, quick liquid, Adaptiv Stepping and resolution >=64)
On a side note, two small questions:
- Does the fluid has any idea what kind of size it has to represent? (like ocean or water bottle)
- Do the sec particles know how old they are? (like frames/seconds in existentes)
I assume that with "constant volume" you mean that the initial amount of fluid (from cube) does not match the final amount (as seen in your screenshot)?
If so, then you're right. The liquid does not explicitly know what volume it represents. With the fields for "Minimum" and "Maximum" number of FLIP particles per cell we can, however, control how many particles may be in the simulation at any time step.
That is, if you set a lower maximum value you should be able to match initial and final amount of liquid.
And yes, I have included a life attribute in the secondary particle code. So particles know how old they are. It's just not accessible from the UI yet.
I assume that with "constant volume" you mean that the initial amount of fluid (from cube) does not match the final amount (as seen in your screenshot)?
Yes. But shouldn't one of the fundamental law of a fluid sim be, that it always has the same volume? regardless of the settings. I can't think of any situation were I want my fluid to in- or decrease.
Also I thought "min" and "max" are some kind of fine control for the NB-FLIP. Not the two "most" important settings for a realistic simulation.
Hello Namnak, yes - conservation of mass is a fundamental law for physics (in addition to conservation of energy and momentum for many systems), but it's tricky to guarantee in practice. Especially for large time-steps, grid-based methods can show errors there, leading to volume changes. But it should get better for smaller time steps, and the "liquid deletion" in noemis second example is more likely a problem with the boundary conditions.
Here is another example where this is a problem: There is no splash when this animated object hits the surface of the water - it seems like the liquid just gets removed:
Just to make sure: The object has the fluid modifier enabled and is of type effector->collision? Or is it a rigid body?
I tried to reproduce the issue but didn't succeed - can you post a link to the .blend file?
Here is the file: https://www.dropbox.com/s/rsu3b8bna6zrleo/cup.coffee.classy.01.blend?dl=1
The cube is animated and a has a fluid modifier of type effector -> ocllision.
Did you succeed in getting a splash from a falling object into liquid?
Thanks for the file - I was able to reproduce the scene! I am not sure though if the splash just gets "visually lost in the movement" or if it's really a bug.
The thing is, the obstacle (9x7x11 in manta grid) is relatively small with respect to the domain (101x101x128 grid). Also, the liquid is already moving in that scene which might cancel out the already small-size splash to some extent.
I tried the same scene but this time kept the liquid static. So yes, in this case I get a small splash with the falling object:
One more thing on liquid disappearing:
I found that this issue (seen in both noemis84 scenes and the coffee cup example) is likely because of an option called "deleteInObstacle" that I am using. I was expecting this to be more of a sanity check - but it looks like it's more problematic..
Here is a comparison with elbeem, I set the domain size to 5 meters:
Hi GottfriedHofmann
I´ve been testing your scene and after some investigation I think the main problem is in the scene scale.
IMHO the elbeem result is not too realistic, bear in mind that real scale models are important for this kind of simulations, so if you want to liquid to behave as a cup of coffe, it should have the same measurements as a real cup of coffe (more or less).
What I did is to scale your scene with a 0.1 factor and then I get a proper splash, it is small, but the object is small, the slow motion could be achieved by using the time scale I think, but the splash won´t be so big unless you force it in some other way.
I also tuned up some more settings, I finished your sugar cube animation a bit in the low part of the cup so the acceleration does not end suddenly, and I increased the amount of particles, I´m resimulating right now, so I can´t see the value name, but it´s default value is 2 and I increased to 3, and the result I get is similar to the one Sebbas showed earlier, but in this case the liquid was in the same movement as yours.
This is the result at the same resolution as your scene, 128, but with a 0.1 factor in scale (I applied scale before simulating it of course):
Right now I´m resimulating it at 200 of resolution and with 4 in the particle count value, I´ll post the results tomorros.
Cheers!
Hi everyone, @sebbas - I think your simulation doesnt look too bad. The cube actually has some impact on the liquid... @GottfriedHofmann - your elbeem simulation seems to have a much lower gravity, leading to the huge splash. We could compare falling speeds of a liquid without any obstacles to match the "large scale behavior" of both solvers.
Gottfried, regarding your other thread: it's correct that scene scale does not have an influence on the simulations. mantaflow (and also elbeem) always simulate in an own "solver space", into which the blender geometries are mapped. That being said, mantaflow always aims for the most turbulent simulation it can produce (lowest viscosity). You can only get it more turbulent by increasing the simulation resolutoin. We could add potentially an option for adding additional viscosity, to make the fluid thicker (i.e., more viscous).
@thunil thank you for the information. Would it be possible to get something similar in Mantaflow like in Elbeem where the user can set both the size of the simulation and the viscosity? That would be very artist-friendly.
Here is another test at resolution 256 and time scale 0.2 - I would have expected a bigger splash a smaller time scale since the falling speed of the cube is the same as in previous simulations:
And here the file: https://www.dropbox.com/s/0oyuu8tnn4f4b19/cup.coffee.classy.02.blend?dl=1
But thunil , if scale is always the same, why is the result from the cup of tea scene different if you scale it wiht a factor of 0.1?
GottfriedHofmann try animating the block until the bottom of the cup and check if you get a bigger splash
@thunil here is a comparison in a scene without cup, manta and elbeem at same resolution and with scene gravity. The time scale for both simulations is also identical (though not the viscosity). Manta left, Elbeem right. I suggest further tests once we can match the viscosity?
Here is the file: https://www.dropbox.com/s/58exvk26v42rzr1/comparison.blend?dl=1
@thunil and here a comparison of the speed the drops are falling at in the scene, I cannot explain the difference because the speed of the simulation should be the same:
Here is the file: https://www.dropbox.com/s/6fwlo0dg9gibtnd/comparison.drops.blend?dl=1
Request: On the first frame, the domain has not yet become fluid on the mantaflow side - can that be changed so that the domain always becomes fluid on the first frame of the simulation?
@GottfriedHofmann thanks for the comparisons! Very interesting. Esp. the second one shows that the gravity settings are pretty close. The different splash in the first one indicates there must be other differences. Thinking about it, mantaflow actually simulates "free-slip" boundaries by default, while elbeem had "no-slip" if I remember correctly. From my experience, free-slip is usually preferrable.
You're right that the first frame should be liquid directly, not the container. That should be relatively easy.
@GottfriedHofmann Yes, the "first frame" for liquids has been on my bucket list for quite some time. The difficult part was just figuring out how to wrap the caching around that. Got it done over the weekend and its now up :) (at least starting from 22e5ed2)
Great to see that this mantafluid implementation goes on and meanwhile I saw many very promising fluid sim renderings.
After testing the latest release (blender-2.79a-908dbed-win64 - 3rd March) I still can reproduce, that an collision object causes the fluid volume to grow or shrink, dependent if moves from bottom or top... here another simple test:
What now works (since my first entry here) is that the fluid surface is going up together with the collsion object.