FLIP Fluids Addon: A liquid fluid simulation tool for Blender

This could be added as an optimization. We have an optimization that skips calculations if the time between frames is 0.0s (freeze-frame), so it shouldn’t be too difficult to add this when there is no fluid in the domain as well.

For now, if there is no fluid until frame 120, I would suggest setting the baking frame range (Under the More Bake Settings section) to start at 120 so that the previous frames do not need to be calculated:


1 Like

Ah hah, thanks. Wish I’d thought of that before I started it. Next time! Thanks.

Thanks heaps for your reply, I have another question. I’ve ticked the basic whitewater settings, and after applying the materials provided with FF, my Foam/bubbles etc are all quite large (https://i.imgur.com/sMR00uG.png) Is there anyway i can adjust this post-bake?

yes you can its under “Flip Fluid Display Settings” in the domain object. its called Particle scale or scale depending on whether beginner mode is enabled.

1 Like

Awesome, thanks!

What’s this white cube in the 3D Viewport when the viewport shading is set to Material Shading (the one between Rendered and Solid; what I think of as EEVEE)? It seems to only be there because in the shader for whitewater_bubble (or _foam, or _spray) I have an Emission shader connected to the Material Output node’s Volume input; the Surface input is connected to the output of a Principled BSDF Shader. It’s a hack I hit upon to solve the problem of the bubbles, foam, or spray being too dark. It doesn’t show up when I do an F12 EEVEE render.

Hey, that looks like it might be the particle instancing object. The whitewater meshes are vertex-only meshes with no face geometry where each vertex represents the position of a particle. Since these meshes have no triangles/faces, they will not show up in the renderers. So the addon generates a particle object for geometry and duplicates the object over all of the vertices by instancing. The addon stores the particle object at the corner of the domain. During render, Blender hides the original instance object.

Good news: it looks like we can now hide this object in the viewport in Blender 2.8x! In Blender 2.79 this is not possible as far as I know.

Great, thanks.

Why is the “Updating Objects Flags” taking so long on my renders. It’s spending about 99.999% of its time there. I’m guessing that it’s from the bubbles.

Not sure what would be the cause of this, I am not too familiar with the internals of how the renderers work. It doesn’t look like there are an unreasonable amount of whitewater particles from the cache size. We regularly render 6 - 8 million particles in a frame with about 1m30s for render set up on the largest simulations. But most of the time is for building the BVH and Updating Object Flags doesn’t seem to account for much of the time.

In a past test I have found the ‘Updating Object Flags’ stage can take a long time if the shader uses volumetrics on the material.

It looks like others have this question, but none contained a solution/explanation:

It may be a questions to ask on https://devtalk.blender.org/. Maybe a developer could shine some light on this.

Hi, not sure if this helps, but about one year ago one of the FLIP users has reported this issue about long export times with whitewater and BlendLuxCore: https://github.com/LuxCoreRender/BlendLuxCore/issues/231#issuecomment-449644219

I have outlined there why it is a bad idea to create hundreds of thousands of instances of a very simple mesh and how that leads to long export times with our renderer (a single mesh with hundreds of thousands of triangles would be much better). Maybe this is causing similar issues when rendering with Cycles.

I don’t know though if you changed the whitewater code since this was reported, maybe it’s already done differently now.

Ok, thanks. I am using an Emission shader into the Material Volume.

Thanks for the link, that’s interesting to know!

This shouldn’t be a problem for Cycles. As mentioned in the other post, rendering with millions of instances has not been a problem.

We have actually tried using a full triangle mesh rather than instancing but ran into performance problems. It may work alright with a low number of particles in the 100K range, but often for detailed effects millions of particles are needed and a scene could contain 150+ million triangles.

Baking this geometry directly into the cache would be a problem as it could require well over a GB of data per frame to store, and taking a very long time to load this into Blender. The alternative is to dynamically generate the mesh using the Blender Python API, but performance for this was not very good often taking 10+ minutes to load a frame.

At the moment, the FLIP Fluids addon only officially supports Octane as a third-party renderer which has some features for efficiently exporting many instances of simple geometry.

When I check the box for Update Settings on Resume it’s not saved when I click the Save Settings button for Default Settings. Is that intentional?

Thanks for letting me know! Looks like I forgot to add this functionality for the entire ‘More Bake Settings’ subsection. Just fixed this.

Great, thanks.

RLGuy, back in January I asked about GPU acceleration, and you had said it had been removed. Is there nothing on RTX GPUs (especially multiple RTX) that could accelerate FF?

And to my fellow hardware geeks, since FF may be in my near future: I have an i7-5820k and 32GB quad-channel RAM. For the most part, I’m able to work pretty comfortably, since I have three GPUs (1x 2070 Super + 2x 980Ti - for now - will be 3x 2070 Super soon) and whether in Blender, Resolve/Fusion, AE, Painter, etc, my workstation never feels sluggish… But after discovering yesterday that used i7-5960X CPUs can now be had on ebay for about $250 (huge drop from the last time I looked), I am seriously considering upgrading. I spend a lot more of my time thinking about GPUs, and don’t research CPUs stuff that much, since rendering is my bread-and-butter. So would I see a truly significant difference in FLIP FLuids solving with a 5960X over a 5820K, and thus would be a no-brainer to upgrade?.. I know that I would gain 12 lanes, more cores, more cache, etc, and that is obviously desirable and nice and all, but I’m talking specifically about performance in fluid solving… Anyone have any good guidance on this?

The FLIP simulation method is not very suitable for running on GPUs dues to the nature of the types of calculations that the simulator runs. It would be more beneficial in terms of performance improvement to focus development time on optimizing the simulator further using CPU methods.

From our FAQ: Is the FLIP Fluids simulator GPU accelerated?

The FLIP Fluids simulator is not GPU accelerated. As of addon version 1.0.4, GPU acceleration features using OpenCL have been removed and all GPU methods have been entirely replaced with higher performance CPU methods.

The FLIP ( FL uid I mplicit P article) simulation method is not very suitable for GPU processing. This is due to the nature of the types of calculations that the simulator runs. Many calculations require traversing large amounts of memory which is slow for GPU processing and some calculations are not parallelizable enough to benefit from running on a GPU.

GPU acceleration features may be added in future development if there are methods found that show large benefits in performance.

Is there a way to use the addon to render sand, as in this example:


No, the addon only simulates liquid fluid flows. I have seen sand simulations using the Blender Molecular addon, so maybe this could be used for that type of effect.