Aim: A calm cylindrical “cup” of water. The “cup” object is created from the outer shell of the “fluid” object and in the same location (walls extended upward a bit and top faces removed)
Fluid object: A closed cylinder. Volume initialization: Volume.
Obstacle object: A hollow cylinder with zero thickness and an open top but closed floor. Volume initialization: Shell.
Both 128-sided cylinders, no subsurface division.
The following image shows the fluid object (orange wireframe), the “cup” obstacle (grey), and the domain (black wireframe). There’s a reason the domain is a little off-centre, and that’s discussed in the notes at the end.
Blender 2.78a on Linux, i7-4770K with 32GB RAM.
Domain object Fluid Physics parameters:
|Final Resolution: 65|
|Preview Resolution (doesn’t affect the bake calculations): 45|
|Render Display: Final|
|Viewport Display: Preview|
|Time Start: 0.000|
|Time End: 2.000*|
|Generate Speed Vectors: Off|
|Reverse Frames: Off|
|Use Scene Gravity**|
|Viscosity presets: Water (Base 1, exponent 6)|
|Real world Size: 0.200m|
|Optimization: Grid levels -1 (auto); Compressibility 0.005 (default)|
|Slip type: Partial Slip; Amount 0.200|
|Surface: Smoothing 1.00; Subdivisions 0|
|Remove air bubbles: On|
|* Have to make sure the difference between start and end times, the number of frames in the animation range, and the framerate set in the Render tab are all consistent to make the Speed setting correct. In these simulations, the step size was set to 24fps.|
|** Can disable this by going in to scene tab and unchecking “Gravity.” Can alter gravity for the whole scene in the scene tab.|
Comparing frame 15 (5/8s) generated by different bake resolutions:
|Baked at resolution 65 but using Preview resolution (45)
The surface kind of squirms in a way that seems intrinsic to Blender’s fluid sim. At this preview resolution, it looks like the fluid is on a grid that’s not centred on the containing object.
|Viewport Display: Final (65)
The same bake but showing the final resolution in the viewport.
Claimed to need 6GB RAM. After a bit at 16.3Gb total RAM usage, KSysGuard showed 20.2GB in use. Over 10 hours to bake 18 frames (0.75 seconds). Getting up to resolution 400, we can see some waves reflecting off the walls. This is neat, even if I was trying to make a calm fluid sitting in a cup. The ripple speed seems pretty hyper to me.
Even at the highest resolution I could achieve, the rounded walls of the fluid show jagged edges. To smooth them it will clearly be better to find a technique other than increasing the bake resolution. I suspect the best will be to add a boolean modifier to the baked fluid, with smooth walls. Note here that I tried this briefly, and it’s important both to triangulate the mesh of the boolean object and to make sure its normals are consistent!
A really key lesson I learned here is to think like an animator or an artist, rather than a physicist, even when running what we call a simulation. If a scale, resolution, or viscosity gives the most pleasing visual result, their closeness to the physical parameters of the supposed physical system is really secondary.
If I wanted to show a calm liquid with a solid object dropping into it, I’d have to find a way to hold it still. I wonder whether the way to do that is to use a control object, but haven’t investigated that. Other possibilities may be to keep the modelled fluid un-animated until the moment the object started to disturb it, or as one blenderartists.org user suggested in 2007(!):
”-Duplicate the Fluid object (that one in the glass)
-Set the fluid to Fluid Init Volume
-Set the copy of the Fluid to Obstacle InitShell
-Use the Ipo Active to deactivate the Obstacle (not the glass but the copy of the fluid in it) when the drop is near to the surface.”
I rendered out a comically-short, low-res clip of the 400-resolution bake:
On the first few tries, I had a highly-subdivided cup object and fluid object, and I was also running the simulation for a lower framerate of 12fps. For whatever reason, at some bake resolutions the fluid would leak out through the sides of the cup in at least one spot. I simplified the fluid and obstacle objects as part of the troubleshooting, and also increased the framerate. When the framerate is low, the fluid calculations have bigger time steps between calculations – and since each step depends on the previous ones, it’s easy to see that this time step size will affect the output of the calculations as well as the time taken to perform them.
When I first tried baking at higher resolutions than 90, the simulation would fail – just stop silently, after finishing 0 to 2 frames. Blender did not crash. The computer was using only a few of its 32GB of RAM. One thing I observed was that CPU usage in KSysGuard showed periodic, large drops in the usage of each core.
After many attempts to tweak things: simplifying object meshes, adjusting frame rate, bevelling the bottom of the fluid and cup, or moving the fluid up a bit to give it something to do at the start, I broke the symmetry of the system by moving the fluid object off-centre a bit. This solved the issue, but of course spilled fluid outside the cup. Next I tried instead moving the domain object just slightly to one side of the cup and fluid objects, which had previously all been concentric. This also worked. When the bake is going to succeed, wild CPU fluctuations are absent. There’s a constant “noise” in the usage level traces on all cores but no periodic drops.