Covering the week of March 23rd – 27th, 2020.
Hey, It’s Ryan and this is our 14th weekly development notes for the FLIP Fluids addon for Blender! Last week’s development mostly involved performance optimizations, including a memory optimization/fix that can greatly reduce memory usage in certain situations. During this week, I’ll be finishing some optimization work from last week and work on further development of our force fields feature set.
In this post, I’ll cover an important topic that is the limitations of the FLIP Fluids addon. Simulation systems are full of limitations and workarounds, and I’ve re-arranged some topics on our Documentation/Wiki to create a helpful topic focusing on the limitations of the addon, fluid simulation, and Blender.
Limitations of the FLIP Fluids addon
Is the FLIP Fluids addon right for your project? The FLIP Fluids addon is a liquid simulation tool based on the popular FLIP simulation method which is short for FLuid Implicit Particle. You should always choose the right tool for the job, and like a hammer, this addon might not always be the right tool to use.
There may be limitations in the FLIP Fluids development project, limitations in the FLIP simulation method, or limitations of Blender that may affect success in creating your desired fluid effect. This document will detail common limitations of the FLIP Fluids addon and Blender.
If you want to try out the addon to see if it’s right for you, install our Free FLIP Fluids Demo.
Scale and Time Limitations
Physical scale: The FLIP Fluids simulator is designed for small- to mid-scale fluid effects. It is designed for physical scales ranging from a glass of water to large sections of a beach. The simulator is not designed for micro-scale phenomena such as accurately simulating the interaction between individual droplets of liquid. It is also not designed for larger scale simulations such as river networks, or entire seas and oceans.
Tip: If your effect involves a small area of dynamic liquid within a large ocean, you will likely need to resort to visual effects tricks. Rather than simulating the entire section of ocean, you will want to simulate smaller local fluid simulation effects and composite into larger ocean footage or blend with a larger ocean plane generated with the Blender Ocean Modifier.
Time Scale: The FLIP Fluids simulator is designed for time scale ranging from seconds to a low number of minutes. It is not designed for time scales of days or months.
These scale and time limitations are common to many fluid simulation systems that are used in computer graphics software.
The FLIP Fluids simulator may not be able to perfectly preserve mass and volume liquid over time. This is a limitation of the FLIP simulation method and is one of the downsides of a FLIP-based simulator. The FLIP simulation method has does not really have a concept of volume and tends to have a bias towards volume loss over time. Volume loss is more prevalent in simulations that involve large amounts of motion from obstacles, especially if the fluid is contained inside of a moving object.
- In general, volume loss can be reduced by increasing the number of simulation subteps, which can improve accuracy of fluid-obstacle interaction. See this topic for more information: What are substeps?
- If using a FLIP-based simulator in an effect where volume loss can be noticeable, a workaround can be to continuously emit fluid throughout the animation to hide the fact that the volume is decreasing.
- It is also possible that the volume of fluid can increase over time. Our Particle Sheeting Feature is an artificial simulation technique that helps create large thin splashes by adding more fluid to the simulation.
- If you require volume to be preserved over time, a particle-based simulation method such as SPH (Smoothed Particle Hydrodynamics) may be more suitable. The Blender particle system fluids are based on the SPH method and is able to preserve volume.
In general, the FLIP Fluids simulator and Blender simulation systems should not be used for scientific/engineering purposes where accuracy and validation is important. The simulator and simulation method is designed for use in computer graphics applications where complete accuracy is not needed and the fluid just needs to look plausible. Many shortcuts are taken during simulation in order to reduce processing time which also reduces simulation accuracy.
Some of the features/parameters in the simulator are not physically based, do not correspond to real-world physical values, and are just graphics tricks to help produce visually pleasing results. The simulator will not contain many of the parameters that you would find in a simulator aimed towards producing scientific/engineering simulations.
FLIP Fluids motion blur rendering is not currently supported due to limitations in how addons can interact with the Blender renderers. Blender does not provide a method for a user or an addon/script to specify motion blur vectors on meshes that change topology between frames (such as fluids). We are actively looking for solutions and workarounds and hope to be able to support this as a feature in the future. More information can be found on this page: Motion Blur Support.
Since motion blur rendering is not possible, a popular workaround is to add motion blur as a post-processing effect using software such as Adobe After Effects, DaVinci Resolve, and ReelSmart Motion Blur.
At the moment, the FLIP Fluids simulator does not support interaction with Blender forces or force fields. Force field support is currently the most popular feature request. This is a large feature set that is being actively developed and is planned for release in July 2020. Follow our weekly development notes for progress on development: http://flipfluids.com/blog/
At the moment, there is no support for multiple fluid simulation and mixing fluid materials in the FLIP Fluids simulator. The simulator is limited to a single fluid (and single viscosity/surface-tension) throughout the domain. Support for multiple fluid interaction is one of the most popular requests. We hope that we can add this in the future, but is not being actively worked on at the moment. This is a complex subject in fluid simulation and may require a significant amount of time for research and development, and some aspects of this feature may be outside of the scope of the FLIP Fluids project.
At the moment, there is no support for generating UV Maps or applying textures to fluids created with the FLIP Fluids simulator. Support for UV mapping and applying textures to fluids and fluid parameters is a popular request and we hope to add this in the future, but is not actively being worked on at the moment. This is a complex subject in fluid simulation and may require a significant amount of time for research and development, and some aspects of this feature may be outside of the scope of the FLIP Fluids project.
Depending on the simulation effect, a workaround may be to use Blender’s existing procedural texture features. In future development, support for mixing fluids and materials may be added which can expand how procedural textures can be used to render fluids.
Interaction between FLIP Fluids simulator and Blender’s rigid body simulator is limited. Rigid body objects can push around the fluid, but the fluid is not able to push around the rigid body objects. This is because simulation systems in Blender are run separately and do not communicate with each other. This limitation also includes interaction with Blender’s cloth and softbody simulation.
However, there are some convincing tricks that you can use to create the illusion of buoyancy where objects are floating around on your liquid surface. See this episode of our tutorial series for a detailed guide and example animations: Episode Seven: Buoyancy Tricks.
Distributing computation over multiple systems and CPUs is not supported in the FLIP Fluids simulator. The simulator is multi-threaded, but the FLIP simulation is not highly parallelizable and is often not able to benefit from distributed computation. There are methods to allow for distributed computing using the FLIP method (See SideFX Houdini distributed fluid simulations), but have limited use and is outside of the scope of the FLIP Fluids project. Simulations large enough to benefit from distributed computing are likely too large to be displayed and rendered in Blender.
Bug Fix: Inflow Memory Optimization
Since very early development of the FLIP Fluids project there has been a design flaw in the simulation engine where Inflow objects use more memory than they need. I had always meant to get around to re-working this area of the engine and last week I had finally got around to looking into this. And it was WAY worse than I had thought – inflow objects are reserving so much unnecessary. This was caused by a design flaw in combination with a bug that has been in the simulator for years.
In early stages of development, the simulator was only capable of running tiny simulations around 32 resolution. Running a 64 resolution simulation would take hours due to design issues and lack of optimization.
Many of the simulation calculations are stored on 3D grids. A cube domain at 32 resolution contains 32x32x32 = 32768 voxels, and to store a 32-bit number into each voxel requires about 131 kB of memory. In early development, memory usage wasn’t a concern due to the small grid size.
Now that the FLIP Fluids project has grown and become more optimized, it’s now common to run much larger simulations containing millions of voxels. A cube grid at 300 resolution contains 27 million voxels, requiring 108 MB of memory to store a single grid. And there are now many more grids to store in the simulator. Memory became much more of a concern during development and required optimizations to reduce memory usage.
While optimizing the simulator for memory usage, one area was overlooked, and that is what caused high memory usage for inflows. Inflows were still reserving a full resolution grid for its calculations which is excessive, and on top of that, a bug was causing it to reserve more grids that it did not need. If there are many inflows in the simulation setup, this could result in a huge memory requirement.
This design flaw and bug has been fixed last week and will be included in the next version update. Here is a comparison on memory usage before and after the fix on a 300 resolution domain (27 Million voxels):
|Number of Inflows||Memory Usage |
|Memory Usage |
|1||5.1 GB||4.1 GB|
|10||13.3 GB||4.2 GB|
|20||22.7 GB||4.3 GB|
|40||Out of Memory||4.4 GB|
|80||Out of Memory||4.6 GB|
|320||Out of Memory||4.7 GB|
|640||Out of Memory||4.8 GB|