FLIP Fluids Addon: A liquid fluid simulation tool for Blender

Coding Released Scripts and Themes
,
384

Great to hear you’re having fun!

The simulation stopping on Linux is a known issue. We do not know the cause of the issue at the moment, however. We’re currently rewriting some code to better support Linux, so there is a possibility that this could fix the issue in the next version update. See this document for the current status of Linux/Mac/Windows support: Operating System Support

See this document for an explanation of CPU usage: FAQ: My CPU is running under 100% usage while simulating. Is this normal?. It is possible that lowering the number of threads could lead to increased performance.

We will not be able to add simulation features such as wicking/absorbant materials. The simulation method that we use is meant for use in graphics applications and does not have the accuracy required for this type of simulation. You will likely need to look into simulators aimed towards scientific/engineering applications to visualize this effect.

385

Thanks for the response, I’m looking forward to the next version. :slight_smile:

386

A short question: I have baked 200 of 500 frame. Now I would like to bake the further 300 frames.
Is it possible without baking the first 200 frame again?

387

…yes u can

388

Yes, you can continue baking by pressing the Resume Baking (frame frame #) button. If you need to extend the timeline frame range, you will need to first update the timeline range (ex: 1 to 500) and then re-export simulation settings. See the documentation on Bake Export Settings for how this can be done.

389

Works perfect. Thanks!

390

tl;dr: We have new guidelines for requesting technical support

The FLIP Fluids addon has recently passed 800 (!) sales and we are incredibly grateful for the support that we have received from the Blender community. We had always expected that the addon would be well received, but we never expected to reach this amount of sales in just over two months. Your support has allowed us to keep doing what we are passionate about and that is to continue development of the FLIP Fluids addon and work on new features.

This post will be an update on the current status of the FLIP Fluids addon. Lately we have had some worries that we have stopped development of the addon (we haven’t!) and some complaints about delays in support requests, so this post will also address these issues.

Technical Support

With the growing userbase of the FLIP Fluids addon, we have recently had some trouble keeping up with the increased volume of support requests. Ideally, we would like to respond to all support requests within 24 hours, but lately there have been some days where there is a large influx of messages and we have not been able to respond as quick as we’d have liked.

A problem that we are having is that we have been responding to support requests over a wide variety of platforms (Blender Market, GitHub, Email, Blender Artists, Facebook, Twitter, YouTube, Discord). Handling support requests over all of these platforms was not a problem with a smaller userbase, but at this point, juggling requests and handling issues spread across these sites had become unmanageable.

Another problem that we have been facing is that we have not had a set of guidelines for how to submit bugs, request troubleshooting support, request features, and submit questions/comments. With the lack of guidelines, there has been no way for users to know the most effective method of communicating issues to us. We have often had to ask for additional information, which has led to an increased amount of time to resolve issues.

Guidelines for Technical Support

We have made some changes to the way we offer technical support for the FLIP Fluids addon. We have recently added detailed guidelines for how to request technical support. Since offering support across a large number of platforms has been unsustainable, we have also changed which platforms for which we will offer technical support. Technical support requests will primarily be received through the Blender Market messaging system, with GitHub as an alternative for submitting bug reports, and email ([email protected]) as an alternative for submitting questions/comments.

You may view the new guidelines for requesting technical support here:

The purpose of these guidelines is to streamline the process of reporting bugs/issues, troubleshooting scene issues, requesting features, and submitting questions/comments so that we have all of the necessary information in your request in order to help you as quickly as possible. Before requesting support, please read through the relevant guidelines. If your request for technical support does not adhere to the guidelines, your request may take longer to fulfill, or you may be asked to resubmit your request.

What is the purpose of this Blender Artists thread?

This thread is still an appropriate place to discuss the addon and troubleshoot issues with other users. This thread is not the best platform for requesting direct support from us as it is quite a long read and many questions and issues that come up are repeats from earlier in the thread history that can be difficult to find. I will still be checking in with this thread often and offering support and input when possible, but if you need support urgently, it would be best to contact us through the officially supported channels.

Continued Development

We have received some concerns that we have stopped developing the addon since we have not released version update in over a month (last: June 1st, v1.0.3). I can assure you that we have not stopped development and are continuing to add new updates, features, and bug fixes.

We did not expect the next version (1.0.4) to take this long to release, but there have been some large delays in development for us recently that has caused very slow progress in the past month. The recent issues stated above of offering an unstructured technical support service has largely cut into development time. Dennis and I have also been quite busy in our personal lives. We are both currently in the process of moving homes (Myself within Canada, and Dennis within Germany), which has also cut into development time.

There have been concerns about how long it is taking us to implement new features. We have seen some misunderstandings about how large the FLIP Fluids team is, that we should be developing at a much faster pace, and this is another reason why it may appear we have stopped development. We are actually just a small team of two and have just a single programmer. As we are a small team, it can take some time until feature requests are added to the product and we thank you for your patience.

Here is the current changelog of version 1.0.4:

  • Added support for baking from the command line (issue #329)
  • Added debug functionality to visualize the true domain bounds (issue #299)
  • Added functionality to restrict viewport/render fluid display from the ‘FLIP Fluid’ physics button (issue #222)
  • Added Inflow option to constrain fluid inside of the inflow object to match the inflow emission velocity. Allows inflow to work when submerged (issue #322). Allows low velocity values to have the effect of slowing down inflow emission (issue #90)
  • Fixed bug that would require reloading a scene if an invalid cache directory was set before baking (issue #330)
  • Addon will now display popup error message when exporting a preset package to an invalid directory (issue #320)
  • Fixed bug where surface motion blur rendering would show a ‘hard edge’ of the object that was not properly blurred (issue #87)
  • Fixed bug that would trigger an error if a deformable inflow was located outside of the domain
  • Fixed UI issue to disable ability to insert keyframes into ‘Hold Frame’ option
  • Removed ‘Invert Surface-Contact Normals’ option in ‘FLIP Fluid Surface’ settings. This option does not work as intended and is not useful.
  • Fixed bug where whitewater particles would be killed when boundary behaviour was set to ‘Ballistic’ (issue #354)

There is still some more bugfixes, performance enhancements, and feature requessts to finish up version 1.0.4, and it may be a few more weeks until this version is ready. The next version should be released by August 11th at the latest.

Hope this gives you an adequate look into the current state of development for the FLIP Fluids addon! We thank you for your support and patience!

- Ryan

2 Likes
391

Hi. I tried the demo and everything works fine. But… is it normal to have a large amount of GB cached files?
Also, is there any benchmark to know if my i7 5820k is doing well?
Thanks!

392

There can be several files per frame. 1 bobj at render resolution and 1 bobj at preview resolution, and also a bbox. And when you turn on whitewater you get even more files. The higher the fluid domain resolution the larger each file will be.

I don’t remember how it is by default but in the Domain it changes the FLIP Fluid Cache panel so that for Current Cache Directory it becomes //blendfilename_flip_fluid_cache where // means use the same directory as the .blend file is in. So I always make a new directory for a project so that the cache directory will be alongside its .blend file. Over in the Render panel (under the little camera) you can change the Output directory to //png\ and then it will create a png directolry next to your .blend file when you render the frames and put them there.

So the next time you’re ready to upgrade your pc, first spend some time at www.reddit.com/r/buildapc/ and make sure you get a case that has sufficient hard drive bays, and definitely consider getting 64 gb of ram and not something measly like 16 gb (like I did).

393

Yes, large cache size is normal. Fluid simulation can produce very high detail meshes which take up a lot of space.

The Intel i7-5820K was a very popular processor model during the beta, so we have a full set of results:

test low medium high
Fluid in an Invisible Box 14m30s 1h08m 3h54m 9h30m
Cascading Water Feature 14m45s 1h13m 4h36m 12h59m
Viscous Net 22m32s 1h04m 3h16m 7h40m
Lighthouse 28m52s 3h00m 11h37m 1d5h48m
394

Thanks, guys. I do have 32gb DDR4, but I think that for some serious work I might need a new hard drive only for caching. Maybe a SSD?

395

I only use my SSD for the system/boot disk where the speed is needed. Flip fluids is mosty CPU bound, not I/O bound.

396

During the beta, there were some users caching on hard drives with quite slow write speeds. On these slower hard drives, for high resolution simulations with large cache files, it was reported that the addon spent over 20% of the total simulation time waiting for the cache files to be written to disk.

Note that the simulation times reported within the addon account for only the time spent simulating. This value does not account for time spent writing data to disk. To get the total time spent simulating, you may either time the bake yourself, or check the log file located in the cache_directory/logs/ directory. The log file contains timestamps for each frame, so assuming you ran the simulation all in one go, you can subtract the first and last timestamps to calculate the total time.

I have only tested the addon on machines with SSDs and it seems the time to write cache data is very low. I have not heard reports of how long it takes to write files from users with faster HDDs.

397

My vague memory is that some of blender’s physics simulations compress the files to gz format. That might help with the writing to slow disks. And help alleviate the disk space issue for those with less capacity. Using compression could be an option the user could turn on or off.

398

We actually used to compress the mesh files in early development, but it caused some user experience issues that became worse as simulations became larger. A comment on this is located in this issue: https://github.com/rlguy/Blender-FLIP-Fluids/issues/325#issuecomment-394032756

The addon actually used to lightly compress cache files, but it led to user experience issues and compression was removed. Some of the reasons why cache files are no longer compressed:

  • Large increase in bake time. For large meshes, the compression process took a very long time and added too much time to the bake.
  • Drastically increased simulation playback time. Decompressing large meshes could add 10+ seconds to frame loading.
  • Interference with whitewater simulation playback optimizations. The whitewater particles are stored in a ‘streaming’ format, meaning that if previewing whitewater or setting display % less than 100, only a portion of the whitewater mesh file needs to be read from the cache. If compressing whitewater, the entire file would need to be decoded before reading which increases time for whitewater playback.
399

@RLGUY would using StoreMI help in reducing the waiting time for writing the cache files?

400

It is possible that this could speed up writing the cache files. I do not have the required hardware to test this, so I am unable to say for certain.

401

I’ve been doing some experiments/samples with different viscosities. Here’s a compilation of a blob being run over by a wheel. The render is blender’s OpenGL, using the matcap shading with the gray clay one, and the ambient inclulsion enabled with its default settings.

Resolution: 320
Surface mesh subdivisions: 2
Frame substeps min: 2
Frame substeps max: 32
Whitewater: off

The wheel’s friction is 1.0; with it at 0 the wheel’s texture in the fluid is cleaner.

I’m not happy with the text overlay; it’s using the VSE’s text effect strip which is limited. (I’m trying to figure out how to render a text layer.) I’ll repost when I get that working.

https://streamable.com/91os8

Edit: Updated link with video with better text.

3 Likes
402

Some target object questions (hopefully the answeres will be added to the docs).

Does the target object for an Inflow object need to be inside the domain?

Does a target object with a nonzero size behave differently than using an empty object? I.e., with a nonzero sized target object will the fluid travel to the nearest surface or to the object’s origin?

403

The target object does not need to be inside the domain.

If the target object is of non-zero size, then the fluid velocity will be directed towards the center of the target bounding box.

Added these notes to the documentation!

FLIP Fluids Summer Sale

By popular request, and to celebrate the upcoming SIGGRAPH 2018 computer graphics conference, we will be having a summer sale! The FLIP Fluids addon will be priced at 25% off for the dates of August 12th through 16th. We wanted to announce this sale as early as possible so that those of you that have been thinking about getting the FLIP Fluids addon can take part in this amazing sale.

SIGGRAPH is the world’s largest, most influential conference and exhibition in computer graphics and this year it will be hosted in my home city of Vancouver, Canada during August 12th-16th! Maybe I will get to see some of you there! - Ryan

2 Likes