FLIP Fluids Addon: A liquid fluid simulation tool for Blender

Hi, at the moment all liquid colors will have the same “strength” of pigment, so there will be no priority for which color is dominant within a mix.

But I think the main issue for this situation is that this is a limitation of surface attributes. Attributes and colors are only stored on the surface of the fluid mesh. The renderer will only know about the color on the surface and there is no volumetric data for coloring the interior of the fluid. So if a clear fluid is poured on top of another liquid, the result will look like the other liquid is quickly absorbed.

1 Like

Have been following along with all the tips here, awesome resource thank you.
Any ideas why the whole width of the sim is rising up near the bow of my sim? Its making it difficult to blend into an ocean surface.
Im guessing that it is because the domain isn’t wide/deep enough so the hull is blocking the flow too much.

I’ve run into the same thing many times even with a significantly larger domain, deep and shallow fluids, accuracy settings, fluid settings, etc. I’d love to know how to avoid it too.

Making the domain deeper/wider can give extra space for the liquid to move around the ship and reduce fluid build-up at the front, but may not completely eliminate the problem.

From feedback of other artists, the better way to simulate this situation is to have a static body of water with a ship animated to move through the water. But depending on the distance the ship needs to travel, this can lead to unreasonably large domains/resolutions and long simulation times.

A trick that I have seen used for blending the simulation into an ocean surface or for compositing is to use a Lattice Modifier to gradually flatten the surface mesh at the domain edges. I suppose a geometry node group could be an alternative method for this trick.

Thank you both for the feedback/help
I’m trying a wider/deeper sim so will see how that goes. Im following Francis Jasmin’s method so already using a lattice but there isn’t enough space to blend it out gradually at the moment.
Otherwise will switch to the ship moving through the domain, would be cool to be able to have a dynamic domain to overcome the size issues, my ship is 100 metres long so the domain is going to be fairly massive.

Firefox will not let me view the https://flipfluids.com/2022/ because the security certificate flipfluids.com expired on 2022-11-04. I will likely be buying a licence for Christmas. Will a licence purchased now include include access to the new simulation engine that is being worked on?

Hi, we’re aware of the certificate issue and are working on getting that updated.

Until this issue is fixed, links to supported marketplaces can be found on this wiki page: https://github.com/rlguy/Blender-FLIP-Fluids/wiki/Official-Marketplaces-of-the-FLIP-Fluids-Addon

All future updates to the FLIP Fluids addon are provided at no extra cost and this includes the new simulation engine that is in development.

Tip: The Blender Market always has a “Black Friday/Cyber Monday” sale beginning November 25th 2022, so that will be the best price between now and Christmas.

Let us know if you have any questions.

2 Likes

I’m getting a weird error when baking:

Python: Traceback (most recent call last):
File “C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\flip_fluids_addon\operators\bake_operators.py”, line 266, in modal
self._update_status(context)
File “C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\flip_fluids_addon\operators\bake_operators.py”, line 212, in _update_status
self._update_stats(context)
File “C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\flip_fluids_addon\operators\bake_operators.py”, line 192, in _update_stats
update_stats(context)
File “C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.3\scripts\addons\flip_fluids_addon\operators\bake_operators.py”, line 78, in update_stats
stat_files = glob.glob(os.path.join(temp_dir, match_str))
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py", line 24, in glob
return list(iglob(pathname, root_dir=root_dir, dir_fd=dir_fd, recursive=recursive))
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py”, line 85, in _iglob
for dirname in dirs:
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py", line 85, in _iglob
for dirname in dirs:
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py”, line 85, in _iglob
for dirname in dirs:
[Previous line repeated 1 more time]
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py", line 86, in _iglob
for name in glob_in_dir(_join(root_dir, dirname), basename, dir_fd, dironly):
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\glob.py”, line 97, in _glob1
return fnmatch.filter(names, pattern)
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\fnmatch.py", line 58, in filter
match = _compile_pattern(pat)
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\fnmatch.py”, line 52, in _compile_pattern
return re.compile(res).match
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\re.py", line 251, in compile
return _compile(pattern, flags)
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\re.py”, line 303, in _compile
p = sre_compile.compile(pattern, flags)
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_compile.py", line 764, in compile
p = sre_parse.parse(p, flags)
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_parse.py”, line 948, in parse
p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_parse.py", line 443, in _parse_sub
itemsappend(_parse(source, state, verbose, nested + 1,
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_parse.py”, line 834, in _parse
p = _parse_sub(source, state, sub_verbose, nested + 1)
File “\\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_parse.py", line 443, in _parse_sub
itemsappend(_parse(source, state, verbose, nested + 1,
File "\
\user\home\USER\Desktop\blender-3.3.1-windows-x64\3.3\python\lib\sre_parse.py”, line 598, in _parse
raise source.error(msg, len(this) + 1 + len(that))
re.error: bad character range t-1 at position 6

This is just with a simple “turn the default cube into a domain, add a uvsphere make that into a fluid” and bake example. All the bundles examples from the preset scenes (29_sep_2022) seem to work fine…

Hi, this is an error that we have seen before and was caused by files in the FLIP Fluids addon cache that had become corrupted. The corrupted files are preventing the addon from processing the data contained within the files and triggering this error.

Specifically, the the corrupt files affected contain information about the simulation stats.

There are two solutions to this issue:

  1. Manually delete the cache directory or switch to a new cache directory and re-bake the simulation (Cache Documentation). This is a quick and easy solution.
  2. Delete the following file and folder if they exist:
  • cache_directory/flipstats.data file
  • cache_directory/temp folder
  • Use this solution if you do not want to restart baking and want to continue from the last computed frame.

Hope this info helps! Let me know if the issue still persists.


Edit/Update:

After testing, we have found that this error can also occur if the cache directory filepath contains square bracket characters ([ ]). This error can also be generated if any parent directory of the cache directory contains square brackets.

For example, a Blend file named blend_file_with_[brackets].blend will generate a cache folder named blend_file_with_[brackets]_flip_fluid_cache by default.

I suspect the cause of this issue is because square brackets are considered special characters in the addon scripting language (Python). We will try to fix this error for the next version of the FLIP Fluids addon.

Workaround: Until this is fixed, remove the square brackets from the cache filepath.

Note: If you are using the latest version of the FLIP Fluids addon (v1.5.0), this error should not appear and the issue will just cause the Domain > FLIP Fluids Stats not to display any data. In earlier versions of the FLIP Fluids addon, this error would halt the baking process.

2 Likes

Solution to recent FLIP Fluids addon crashes related to NVIDIA GeForce RTX drivers

This post is to update you with a solution to a recent issue that has been causing frequent Blender crashes when running simulations with the FLIP Fluids Addon. This issue is relevant to artists that run systems containing NVIDIA GeForce RTX series video cards. In this post we will detail the issue and the current solution to this problem.

The fix for this issue is to update your NVIDIA GeForce RTX drivers to the “Studio Driver” version: https://www.nvidia.com/en-us/geforce/drivers/

Issue Symptoms and Patterns

  • Frequent baking crashes closing Blender, typically within a few frames of beginning or resuming a simulation.
  • Issue began appearing in October or early November.
  • System containing a NVIDIA GeForce RTX series video card.
  • Issue occurs on all versions of Blender and the FLIP Fluids addon.
  • Issue occurs in all Blend files: older files, newly created files, example files.

Issue Summary

Beginning in early November, we were made aware of an issue where baking a simulation using the FLIP Fluids addon was resulting in frequent Blender crashes. Over the past few days we had received a large number of reports of this issue. While troubleshooting the problem and gathering feedback, it was found that this issue was not related to updating to a newer version of the addon or Blender, but was being caused by a change external to Blender. This change suddenly began causing crashes across all version of Blender and the FLIP Fluids addon.

After troubleshooting, it has been found that this issue was being caused by a recent NVIDIA GeForce RTX driver update. Specifically, the “Game Ready Driver” version was determined to be the cause of the issue. This issue was causing an interaction between the addon and the Blender UI/Viewport that would trigger a crash - typically within a few frames after beginning a simulation.

Issue Solution

The current solution to this issue is to update your NVIDIA GeForce RTX drivers to the “Studio Driver” version which is typically more stable for content creation software. You will be able to download the latest NVIDIA drivers and specify the “Studio Driver” download type in the manual driver search here: https://www.nvidia.com/en-us/geforce/drivers/

Issue Workaround

If you are unable to update to the NVIDIA Studio Drivers, a workaround is to bake the simulation from the command line. The FLIP Fluids addon contains tool to automatically launch a command line baking process in the FLIP Fluids sidebar menu (See Documentation).


If you are affected by this issue and this solution does not fix the problem, or if you have any questions at all, please reach out to us here, by sending us an email at [email protected], or by discussing on the GitHub Issue Thread #599.

We apologize for the inconvenience that this issue has caused. Thank you for your patience and for supporting our FLIP Fluids addon.

- The FLIP Fluids Addon Development Team

3 Likes

Aha, that’ll be it - unfortunately our naming convention where I work puts the Jira ticket job in square brackets as part of the parent project folder.

Can confirm it’s not halting the baking process, but once it happens I can’t stop the bake - if I click the blue stop/pause button it turns grey but keeps on pumping out .bobj files into the bakefiles directory.

Hopefully it’s something that’s easy to fix, but for now I’ll have to work around it.

Ended up being a simple fix. This will be included in the next version, FLIP Fluids 1.6.0 to be released on November 24 2022 or earlier.

3 Likes

FLIP Fluids 1.6.0 is now available!

FLIP Fluids 1.6.0 is a maintenance update that adds smaller bug fixes and improvements, and integrates the preset scenes package into the Blender asset browser.

There were some new features that we were excited about related to variable viscosity improvements and fluid particle rendering for this version, but sadly these will need to wait for another time. An unexpected NVIDIA Driver Issue had set our development schedule back by a few weeks and these features were not finished in time.

However, this update still adds some well needed bug fixes and improvements!

Watch our video overview for FLIP Fluids 1.6.0 and the Preset Library here:

Release Notes: FLIP Fluids 1.6.0 (24-NOV-2022)

For earlier versions, view the Full Release Notes page.

  • FLIP Fluids 1.6.0 mainly adds bug fixes and smaller features, as well as begins an initial test phase for the integration of the preset scenes library into the Blender asset browser.
  • Compatibility Notes:
    • Blender 3.4: The upcoming release of Blender 3.4 (December 7th, 2022) required no changes to the FLIP Fluids addon and is supported in this version.
    • Blender 3.5: At this moment there are no known compatibility issues between this version of the FLIP Fluids addon and Blender 3.5, but this may change as Blender 3.5 develops.
  • Important note on NVIDIA GeForce RTX Driver Compatibility Issue:
    • A recent NVIDIA GeForce RTX ‘Game Ready Driver’ update may cause frequent Blender crashes while baking a simulation. Until this issue is fixed in a NVIDIA driver update, the current solution is to update to the NVIDIA ‘Studio Driver’ version. Studio drivers are typically more stable for content creation software.
    • NVIDIA Graphics drivers can be downloaded here.
    • Read more about this issue here.
    • A warning in the FLIP Fluids Preferences menu has been added and will display info and links if a RTX graphics card is detected.
  • Added: The FLIP Fluids Preset Scenes Library can now be installed into the Blender Asset Browser.
    • This addon feature is currently in an initial test phase.
    • Blender’s asset browser feature is a work-in-progress and the Blender developers are working on adding more features and improvements. There are some necessary features of the asset browser that will be required for improving the integration of our preset scenes in future development.
    • See installation instructions, notes, and known issues here.
    • Watch our video overview (timestamp: 0:59)
  • Added: Operator to copy the active FLIP object settings to all selected FLIP objects of the same type.
    • Supported on Fluid, Inflow, Outflow, Obstacle, and Force Field object types. Not supported on Domain objects.
    • Keyframed settings will not be copied - these will need to be copied manually, such as through the Blender graph editor.
    • Settings cannot be copied to an object that has not already been set as a FLIP type object. You will first need to set non-FLIP objects to a FLIP type. Tip: to set multiple objects to a FLIP object quickly, use the FLIP Fluids sidebar > Add Objects operators.
    • image
  • Added: An Enable Technical Support Tools option to the addon preferences menu.
    • This option enables features used by the developers to assist in technical support requests but may also be useful to artists during issue troubleshooting.
    • If enabled, some of these features will be included as operators under the FLIP Fluids sidebar > Technical Support Tools menu. (Read more here).
  • Added: Save Blender Installation and Simulation Info to Blend File option to the addon preferences.
    • If enabled, save information about your system hardware, Blender installation, and simulation setup into the Blend file.
    • Saving this info into the Blend file helps improve turnaround time when requesting technical support and improves accuracy when diagnosing issues. To view the type of info that is saved, use the Help > FLIP Fluids > Copy System & Blend Info operator.
    • If disabled, this info will be cleared upon the next save of your Blend file, but it may be required to provide additional items and info when requesting support.
    • image
  • Added: Operator to FLIP Fluids sidebar > Add Objects menu to delete a selected domain.
    • This operator will not delete the cache directory.
    • This operator is recommended for deleting domains as deleting within the viewport may leave behind stray child objects such as simulation meshes.
    • image
  • Bug Fix: Fixed issue where scene gravity was not set to 0 when the scene properties Use Gravity option was disabled.
  • Bug Fix: Fixed issue where a mix of static and dynamic Inverse Obstacles would not be computed correctly within the simulator.
  • Bug Fix: Fixed incorrect velocity extrapolation within the simulator (issue #593).
  • Bug Fix: Fixed issue where the simulation would continue baking after stopping a simulation if the cache filepath contained square brackets.
  • Bug Fix: Issue where whitewater spray emission speed could not be set below 1.0. This value now has a soft minimum of 1.0 and a true minimum of 0.0.
  • Bug Fix: Fixed issue where too many threads would be launched when computing obstacle objects containing many separate pieces (mesh islands) which would slow down computation due to overhead managing threads. This issue would affect fracture simulations generated by the Blender Fracture Modifier branch.
  • Improvement: Command line operators that generate a render will now check if the render output directory is valid or else generate an error. This causes the operation to fail early instead of failing after the render is completed.
  • Improvement: Added additional info to the Help > FLIP Fluids > Copy System & Blend Info operator. Information about the Blender Installation and simulation setup is now included to assist in technical support requests.
  • Change: The Set Render Output Relative to Blend operator will now output to a relative folder with a name in the form render_[blendfilename]. This is to avoid multiple Blend files from sharing the same render output folder and potentially overwriting files.
  • Removed: ‘Smooth’ surface tension solving method. This solving method did not work as expected and caused confusion. Useful cases for this option were rare.
  • UI: Removed redundant viewport text in grid visualization debug drawing. This information is already contained in the Domain > Simulation > Grid Info section.

- The FLIP Fluids Addon Development Team

5 Likes

Thanks for the explanation, it gave me a lot of inspiration, I have been troubled by this problem.

Hi RL Guy,

Apologies if this question has been covered elsewhere but I can’t seem to find anything…

Is it possible to take an existing simulation bake and upres it, or do you always have to rebake? I seem to remember Phoenix FD had a feature like this, where you could simulate at low resolution until you got the results you want, and then detail could be added to the existing cache data. Of course, I could be misremembering as it’s some years since I used Phoenix. I know you can upscale in FLIP partway through a simulation, but can you actually add detail to a simulation you’ve already baked…?

I was thinking such a feature could be very useful if you could then upscale parts of your simulation; you could upres closer to the camera and use lower res data for the background. Is this a possibility or just pure fantasy…?

Thanks,

P.

Hi! Upscaling the simulation after baking the cache is not a feature of the addon. I am not aware of general upscaling techniques for liquid simulations, but it may be a possibility.

It is possible to add a feature to upscale the mesh after baking to add more geometry detail, but this is not a feature that is implemented. However, just upscaling the mesh may not produce great results as the underlying physics detail will still be at a low level without any complex motion of a full high resolution simulation.

There are some upscaling approaches. Nils, who brought the first fluid simulation engine to Blender was developing “Wavelet Turbulence for Fluid Simulation”
https://www.cs.cornell.edu/~tedkim/WTURB/
However I’m not sure, if this one is suitable for 2 phase fluids. It was only demonstrated with gaseous fluids.
Nevertheless there’s a later paper, which is dealing with those cases: “Closest Point Turbulence for Liquid Surfaces”
http://www.tkim.graphics/CPT/
I didn’t read them, but maybe you find one of them helpful.

Can I ask a performance related question? I’m trying to understand.

I’m creating a scene with big waves and a revetment on which the waves break. It’s quite a big scene and the waves are approx. 3m high, generated by a simple wave generator (a straight moving wall with a noise signal calibrated on the wave period and wave height). The scene is 320m long and 6m high. The width varies with the resolution: the wider, the better of course.

My question is the following: if I make the scene 15m wide and the voxels 12.5cm in size, the amount of voxels reaches 30 million. If I make the scene 20m wide and the voxels 10cm in size, it reaches 77 million.

So that’s about 2.5 times as many voxels. The bake time for 30 million voxels is about 5 days (3600 frames), which is acceptable for this scene. However, if I bake it with 77 million voxels, you of course expect is to be around 12-15 days of baking time, which is still acceptable in this case. However, it says it will take a staggering 150 days to bake…

How is that possible? How are you able to optimize this, or is it possible to predict when the baking times are going to be this extreme?

Thank you!

PS: suggestion for next release, a wave generator. An object that you can place in the water body that generates a wave spectrum in which you can control the wave height and wave period (the signal depend on the depth of the water) and the seed number for the random signal.

Hi! Are you able to attach or link to a zip of the simulation log files? These files can be found in the simulation cache directory: cache_directory/logs

A log file is saved into this location every time the simulation begins or resumes baking. These will give us a better understanding for how the simulator ran for the different resolutions that you have tested.

The fluid simulation method used in this simulator (FLIP) runs computations that do not scale linearly. Due to the nature of the computations required to ‘solve’ the fluid, the amount of simulation time can begin to greatly increase as the number of voxels occupied by the liquid increases.

Though, a factor of 5 → 150 days or a factor of 30x increase is quite a large amount and it could be possible this is caused by something else.

image

Technical Specifics: If I recall correctly, the bottleneck computations run with polynomial complexity, meaning that the bake time is proportional to C * (voxel_count^r) where C is some scaling constant and r is some constant exponent greater than 1.

Another issue that could explain the large increase in simulation time is if your system is running out of RAM resources. It is possible that when running out of memory resources, the OS could be resorting to using swap memory space that is stored on a SSD or HDD. Due to the large bandwidth difference between RAM/SSD/HDD, this could result in massive performance decreases.

Seeing the log files may help us get a better idea of what is causing the performance issue.

Related topic:

1 Like

Yes! Files, are appended, including the blend file (with safety factor set to 17, which I don’t think makes a really big difference).

High res file with 10cm voxels and 20m wide flume
Voorlandalternatief_v2_hires.blend (1.8 MB)
logs.zip (140.6 KB)

Just in case here’s the mid-res file with 12.5cm voxels and 15m wide flume, should be the same as above but with different settings
Voorlandalternatief_v2_midres.blend (1.7 MB)

I understand the curve well. It was almost lineair even when I did a smaller test run with 20cm voxels, but somehow it hit a roof or something and now it takes ages… I thought of memory usage, but it “only” uses 36GB of RAM, which is only enough to fill 66% of the available 64GB, so that’s not the issue I guess.

Edit: okay here’s the interesting part: I started a bake with 10cm voxels and 15m wide flume, and this decreased the bake time by a factor 10 compared to a 20m wide flume!