FLIP Fluids Addon: A liquid fluid simulation tool for Blender

Awesome to see that Two Minute Papers made a video on this! The work is based on NVIDIA GVDB Voxels. I was following this a while ago, but the development of the project and code has halted.

I can’t seem to find the forum post at the moment, but an author/developers of the paper, Rama Hoetzlein, mentioned that he is no longer working with NVIDIA or on this research and has no plans to continue development. As far as I know, NVIDIA no longer supports the GVDB voxel tech and has not commented on the status of the project, so it is unknown if it will continue. But I could be wrong, it’s been some time since I’ve looked at this.

Our FLIP Fluids weekly development notes #19 is now posted! Weekly Development Notes #19 – Approximating Signed Distance Fields.

Weekly Development Notes #19 – Approximating Signed Distance Fields

Covering the weeks of May 4th – 15th, 2020.

Hey everyone, it has been a few weeks since the last development update! I needed to skip last week’s development update to spend some time healing from a minor wrist injury that had left me with limited typing ability. I now have a comfortable wrist brace that is working fantastic and is helping me recover while being able to work painlessly.

The last two weeks mainly involved testing methods for approximating signed distance fields, and that is what I will cover in today’s post!

Approximating Signed Distance Fields

In the last development update, I discussed what a signed distance field (SDF) is, why we need them, and why it is unreasonable for us to calculate them with 100% accuracy. In short:

  • A SDF is a type of data that helps us represent volumes in the simulator by storing distances to the closest point on a surface. They can also be used to query the closest point on a surface from any point in the grid.
  • For a large part of our force field feature set, we need to compute SDFs efficiently over the entire grid, not just a narrow band near the surface. This is so that we can generate force fields that direct fluid towards or away from an object surface.
  • Computing a SDF can be an intense computation. To compute with 100% accuracy, it could take minutes to an hour+ per frame on a high resolution grid. For this reason, we must compute an approximation of the SDF, which can be fast, but introduces some amount of error into the generated data.
  • For a more detailed overview, see the last development update here: Weekly Development Notes #18.

While testing different methods of approximating a SDF, I think I have settled on a method that will work great for our force field features called a Fast Sweeping Method . It is relatively quick to compute, easy to implement, and introduces just a small amount of error that is acceptable for our use case. For an explanation of the Fast Sweeping Method , you can find a paragraph on page 53 of Robert Bridson’s Fluid Simulation SIGGRAPH 2007 Course Notes.

Fast Sweeping Method Results

In order to test the accuracy of a SDF approximation method, accurate data was needed for a comparison. A brute force computation was run on two object meshes at various resolutions to generate data sets of accurate SDF data:

  1. Suzanne Monkey (3508 Triangles) on a cubic grid at resolutions 64, 128, 196, 256, 320, and 384
  2. Stanford Bunny (6966 Triangles) on a cubic grid at resolutions 64, 128, 196, 256, 320, and 384

monkey_bunny_models

Approximate SDF data was generated using an implementation of a fast sweeping method and compared against the accurate data. A percentage of error was calculated based on the difference between the approximate and accurate data. In the results, the percentage error is considered to be the percentage of grid nodes whose distance differs by more than the width of one grid cell.

Suzanne Monkey Results

Resolution Voxels Accurate SDF (s) Approx. SDF (s) Speedup Error %
64 282 k 9 0.27 33x 0.24%
128 2 M 77 0.83 93x 0.34%
196 7.5 M 233 2.2 106x 0.43%
256 16.8 M 556 5.0 111x 0.54%
320 32.8 M 1054 9.6 110x 0.64%
384 56.6 M 1757 16.2 108x 0.73%

Stanford Bunny Results

Resolution Voxels Accurate SDF (s) Approx. SDF (s) Speedup Error %
64 282 k 18 0.31 58x 0.66%
128 2 M 131 0.89 147x 0.64%
196 7.5 M 467 2.5 187x 0.66%
256 16.8 M 1057 5.2 203x 0.75%
320 32.8 M 2117 9.8 216x 0.81%
384 56.6 M 3490 16.6 210x 0.92%

Error Visualization

According to the above results, approximating the SDF introduces a small amount of error. Is this amount of error acceptable? What is causing the error? To understand what these errors mean, it can help to visualize the data. In the following visualizations, the dots highlight spatially where these errors occur:

https://gfycat.com/shamelessrespectfulinsect

https://gfycat.com/soggyaggravatinggossamerwingedbutterfly

It seems most errors align to concave regions of the mesh where two (or more) points are close to being equal distance from the grid point. For our use case, this type and amount of error is minor, so this is looking promising as a way to speed up some major force field computations!

The next step, and what will be the focus of this week’s development, will be integrating and further optimizing this method for the simulation engine. Further testing will be needed on various mesh shapes to ensure that this is a suitable method, but I am quite confident we can make this method work well in our force field feature.

4 Likes

Our FLIP Fluids weekly development notes #20 is now posted! Weekly Development Notes #20 – Stabilizing Force Fields.

Weekly Development Notes #20 – Stabilizing Force Fields

Covering the week of May 18th – 22nd, 2020.

Hello, this is Ryan here with our 20th weekly development update of the FLIP Fluids addon for Blender! Last week was a four day work week due to a holiday here, but it was still a productive week. I mostly spent my development time on our force field implementation, and that is what I will cover in this post.

Implementing a Signed Distance Field Approximation

A signed distance field (SDF) is a type of data that is very important for our upcoming force field feature set. For our force fields, SDF data is computed and used to generate force fields that align with an object’s geometry. SDFs can be very computationally intensive to compute accurately, so we needed to find a good way to make a quick approximation.

The past few weeks have largely involved researching different SDF approximations methods, testing and analyzing error of different SDF methods, and finally implementing a method into the simulation engine. You can read more about this process in last week’s development notes: Weekly Development Notes #19 – Approximating Signed Distance Fields.

Last week’s development mainly involved implementing and integrating a quick SDF approximation method into the simulation engine. I’m glad to say that this new method seems to be working well and I am very happy with the implementation so far! The older method we had implemented had too many potential issues that would make our force field feature difficult to use:

  • Unstable at high resolutions – Our older SDF approximation introduced too much error, especially at higher resolutions. The amount of error was proportional to the number of grid cells away from the objects surface. This would make the force field directions unstable if the fluid was far away from the object. The newly implemented method is much quicker and has greatly reduced the amount of error.
  • Unstable for complex geometry – Complex geometry, such as sharp corners and thin concave regions introduced a lot of error into the approximated SDF grid. This could cause unstable force field directions close to the objects surface, and visually this would look like the fluid is swirling chaotically against the surface. The new method handles complex geometry very well.
  • Not supported for non-manifold geometry – The older method did not support non-manifold geometry. For a force field to be generated correctly, the object was required to be watertight with an inside and outside to the volume. For some force fields, it should not matter if the geometry is non-manifold. The new method is able to support non-manifold geometry such as curved planes and even curves!

Force Field Tests

Here is a quick test of a ‘morphing’ effect using our surface force field mode. This mode draws fluid towards an object’s surface.

This effect was created by generating two force fields: one field aligned to the surface of the Stanford Bunny and another field aligned to Blender’s Suzanne Monkey model. The morphing effect was achieved by crossfading the strength of the two force fields.

https://gfycat.com/saltyhighleveldoe

I also had a chance to spend some time starting work on a curve guided force field mode, one of the most popular requests for our force field feature set:

https://gfycat.com/impressionablehorribleharrier

Thankfully, the new SDF approximation implementation supports curve geometry. I was bit worried in the past weeks that I would need to develop a separate SDF approximation specifically for curves and infinitely thin geometry.

Next up:

For the upcoming week, there are a few loose ends to tie up on this new implementation. There are some current usability issues that can arise if the force field object geometry is animated.

It seems simulations can become unstable if the force field object is moving quickly through the domain grid. I’ll need to investigate the cause of this, but my guess is that the force field grid is changing too abruptly and causing unstable particle motion between frames. A possible fix for this is to run more substeps for quick moving force fields. If I’m correct in this assumption, the number of substeps could be computed adaptively, which would be automatic within the simulator so the user would not need to worry about this.

Afterwards, I’ll continue work on implementing a curve guided force field mode and a volume force field mode (similar to Houdini’s Suction Force or Blender’s older Control force).

OTOY OctaneRender compatibility issue

We had a user inform us that there is a compatibility issue with the latest version of FLIP Fluids (v1.0.8) and the latest version of OTOY’s Blender Octane Edition (Blender 2.82a 2020.1 – 21.7) that will cause a render server crash. This issue is caused by a change in the Blender Octane Edition. Specifically, an OctaneRender setting has moved locations and the FLIP Fluids addon did not account for this. This has been fixed and will be included in the next version update.

Workaround

There is a simple workaround if you are using the latest version of Blender Octane Edition:

  • Fluid surface rendering – In the object settings for the fluid surface object, change the Object Type to Reshapable Proxy .
  • Whitewater rendering – In the object settings for the whitewater objects, change the Object Type to Scatter .

In the next version, the addon will set these values automatically.

More Development Notes

  • Fixed broken example scene – A user reported that the Strawberry Splash example scene was not rendering correctly in the latest version of Blender (fluid object would not render). This scene has been re-built and the product downloads have been updated. This type of issue is rare and seems to be caused by incompatibilities between Blender versions that can break/corrupt a .blend file. Unfortunately I have not been able to reproduce this issue consistently so that it can be reported as a bug.

  • Documentation Note: Does my obstacle object need to be completely contained by the domain? – Added a documentation note to clarify a somewhat common issue. Obstacle objects can be larger than the domain, and will be computed correctly if so. But if the object is much larger compared to the domain size, this can lead to performance and memory issues or even out-of-memory errors.

  • Blender Bug Report: Render crash when an object is updated with a frame_change_post handler while another object’s Show in Render property is keyframed (T76422) – This was a weird bug reported to us. Blender could crash during render if an object unrelated to a FLIP Fluids simulation had it’s render visibility keyframed.

    I had reported this to the developers, but the issue was closed as not-a-bug. I might not have communicated the issue clearly and may need to follow up on this. The developer’s response mentions that the script works after removing the depsgraph.update() command, but it was recommended to us that this command is necessary for us to prevent other types of render crashes.

11 Likes

Thank you for all of the support! Another year has passed and in this development update, we’ll cover some of our new features and additions over the past year as well as what we are working on right now!

Thank you for watching,
The FLIP Fluids Addon Development Team

• Please, subscribe our new FLIP Fluids channel on YouTube: youtube.com/c/FLIPFluids
• All information about the Customer Reel 2020 can be found here: Customer Reel 2020
• Our new homepage is here: flipfluids.com
• We’re also on Facebook, Twitter, and Instagram

3 Likes

Hello @RLGUY

Will the CUSTOMER REEL 2020 contain only users videos? Or will your own renders also be included?

Hello! The customer reel will only contain user created videos. We have also been working on a separate reel over the past year for our own videos which will have some animations we have not shown yet.

1 Like

@RLGUY, But how do you know how much time it took to calculate the surface tension? Can you add this information to the statistics?

At the moment, there is not an easy way to get a good estimate for how long the surface tension calculations in the UI. Most of the surface tension compute time is in the FLIP Fluids Stats Other category, which is also used for a lot of other calculations.

A way to get an idea for how long this is taking is to check the logfiles or the system console (Blender > Window > Toggle System Console) at the last substep of a frame. In this display, most of the surface tension calculations are located in the Calculate Surface Curvature category. Some calculations are in the Solve Pressure System category, but this section contains a lot of other types of calculations as well.

That stats in the UI and the logfiles/console are very simplified. I’ll be expanding the stats for the version after 1.0.9 when we re-design the simulation engine. There is a lot more useful data and timing info that we can output that will help both users and ourselves analyse how the simulator is performing. There are many specific settings in the UI that can add extra time to the simulation and can be separated into their own timing categories.

2 Likes

Our FLIP Fluids weekly development notes #21 is now posted! Weekly Development Notes #21 – Volume Force Fields.

Weekly Development Notes #21 – Volume Force Fields

Covering the week of May 25th – 29th, 2020.

Hello and welcome to our 21st weekly development update of the FLIP Fluids addon for Blender! Last week was great for development progress of our upcoming force fields feature set. Last week’s work mainly involved finishing up our surface force field mode as well as starting work on our volume force field mode, and that is what I’ll cover in this post.

Volume Force Fields

Our volume force field mode is quite similar to the surface force field mode discussed in the last few development updates. Surface forces attract fluid to the surface of an object- it creates a shell of fluid around the object. Volume forces attract fluid into the interior of an object’s volume. Here is a simple test using Blender’s Suzanne Monkey model:

https://gfycat.com/hoarsethosedwarfmongoose

If you are familiar with Blender’s older Elbeem liquid simulator, our volume force mode is similar to the Fluid Control object type. We are basing our implementation of this force mode after Houdini’s Suction Fluid tool.

Water Elemental

I started running this simulation as a test before finishing work for the weekend, and I did not expect this to turn out as well as it did! In this animation, a volume force field is used on an animated character from Mixamo:

https://gfycat.com/pointlessscrawnyamericantoad

This test at a low resolution of 150 to make sure animated volume force fields would work correctly, and it seemed it did!

https://gfycat.com/verifiablezanybrocketdeer

A few modifications were made to the setup and the resolution was cranked up to 450 before I let the simulation run over the weekend. Here is an OpenGL scene view of the simulation:

https://gfycat.com/sharpexhausteddaddylonglegs

Next Up:

For this week, I will be finishing up the volume force field mode, and if I’m as productive as last week, I’m hoping I’ll be able to start on adding another mode. There are a few features left to do on this mode as well as some simple bug fixes:

  • Anti-gravity – A useful feature for volume forces is to be able to alter the gravity strength/direction within the interior of the object. For example, it may be desirable to have no gravity (or low gravity) inside of the object, which could help with filling up the volume more evenly.
  • Optimization Bug – Before running these tests, I noticed there was a bug that prevented using some force field optimizations that would help speed up the simulation.
  • Stability Bug – Something is causing volume forces to become unstable in rare cases. I have found that the instability is related to nonsense data in the force field calculations. Before running animation tests, I quickly added a workaround for this by detecting and replacing bad data, but it will be better to find the root cause and fix this bug properly. The good news is that this fix should be simple since I have a .blend file that can consistently and quickly reproduce the bug.

Stabilizing Surface Force Fields

In last week’s development notes I had mentioned that there was a stability issue where surface force fields could become unstable if they were animated. My hypothesis was that the force field data was changing too abruptly and more substeps would be needed to keep the simulation stable. After testing this last week, it turns out I was quite wrong!

It turns out the stability issue was caused by a divide-by-zero bug, and it was an easy fix of adding a few checks to prevent the simulator from dividing by zero and generating bad data.

https://gfycat.com/allrealislandcanary

Although the fix was easy, this was a frustrating bug to find the root of the problem. This was a rare bug to reproduce and I started noticing a weird pattern in my tests. In all three of my scene setups that could reproduce this issue, a common pattern was that the bug would only occur if the animation keyframes were set to bezier and would not occur if set to linear . This made me assume that the bug was related to how meshes are interpolated within the simulator, which was wrong. It turns out this pattern was a complete coincidence and it led me to initially look into an unrelated area of the simulator during debugging, and that wasted quite a bit of time!

More Development Notes

  • Added functionality to re-compute force fields on substeps between frames – Originally, force fields were only recomputed at the start of a frame, and not on substeps. This will be needed to compute accurate motion for fast moving force fields. TODO: it would be good to have an option to only re-compute force fields at the start of a frame . For slower moving force fields, re-computing on substeps would add extra simulation time and be overkill. Perhaps this could be automatic and made adaptive?
  • Added UI setting to limit maximum strength of a force field – For usability, it is important that we add a limit to the maximum strength of a force field. Depending of the force field falloff, the evaluated force strength can be inversely proportional to distance (1 / distance^falloff). In fluid simulation, the particles can become very close to the force field origin and can take on near infinite force field values that can cause the simulation to become unstable. To make our force field system easier to use, force fields will have a Maximum Force Factor value. This value will limit the maximum force field strength to the max_force_factor * base_strength . The default value is currently set at 3.0. For example, if your force field base strength is set to 9.81 (default strength of gravity), the maximum force field strength will be capped at 3.0 * 9.81 = 29.43 .
  • Bug Fix: Estimated Surface Tension Substeps value would not update after a frame change ( issue #497 ) – This info UI element displays the estimated number of substeps that the simulator will compute depending on amount of surface tension, surface tension accuracy, physical domain scale, and framerate. It was reported to us that the value would not be updated on a frame change when the simulation time scale (speed) was animated.
  • Possible workaround for rendering OpenGL debug visualizations – A common request we receive is to be able to render the OpenGL particle debugging visualization into an animation. I asked in this Twitter thread if this was possible, and received some very helpful info. Unfortunately, it looks like it is not possible to render custom OpenGL drawing in regular Blender rendering, but there is a workaround where we can do this by scripting a special render operator.

https://gfycat.com/illustriousfirsthandbadger

10 Likes

Hello, you’ve probably addressed this issue before (i remember seeing it somewhere) and provided a solution but from Googling around i couldn’t find any information about this issue


i thought the issue was because i didn’t have sheeting on, turned it on and still appeared at 200 resolution. the obstacle is just a sphere with the inverse setting

Hi, see this documentation topic: Scene Troubleshooting: Mesh banding artifacts against curved obstacles. I almost always recommend setting the surface subdivision level to 1 for a final simulation.

The Meshing Offset Mode setting may be relevant in this situation. If the inverse obstacle won’t be visible in the render, setting the offset mode to On Surface can generate a better mesh.

Hope this helps!

1 Like

Yes a combination of those 2 settings fixed the problem, thank you! just a simple side question if you don’t have the time you don’t need to answer, but why is the scene initializing, loading, bvh etc taking 95% of the render time when whitewater is on? I understand it’s because of the considerable amounts of data but is there any way to speed that part of the process?

I am not very knowledgeable about how the Blender renderers work. It does seem that having many particle instances really add a lot of time to the render setup and initialization stages. For around 6 - 8 million particles, it can take around 90 seconds for the setup.

If using a volumetric material on the whitewater particles, this can add a lot of time to the setup.

Something to test could be to play around with the acceleration structure settings to see if they can help speed things up (If using the Cycles renderer):

I’m not sure if tile size affects the setup time, but this could be something to try as well.

You might be able to find more information by searching around on this forum or on https://devtalk.blender.org/.

1 Like

Our FLIP Fluids weekly development notes #22 is now posted! In this post, I’ll detail how we optimized the engine and simulation setup to reduce baking time of a volume force field scene from 27 hours down to 10 hours. Weekly Development Notes #22 – Debugging, Optimizing, And Testing Volume Forces.

Weekly Development Notes #22 – Debugging, Optimizing, And Testing Volume Forces

Covering the week of June 1st – 5th, 2020.

Hey, everyone! This is our 22nd development update for the FLIP Fluids liquid simulation add-on for Blender. I had a productive week and a fantastic weekend, and I hope you did as well! Last week’s development mainly involved debugging, optimizing, and testing our upcoming force fields feature set. I also had a chance to fix some small issues within the add-on that had been bothering me (and maybe others!) for a while.

In this post, I’ll detail how we optimized the engine and simulation setup to reduce baking time of a volume force field scene from 27 hours down to 10 hours.

Optimizing Volume Forces

In last week’s post, I covered a volume force field test using an animated character. You can read more about more here: Weekly Development Notes #21 – Volume Force Fields.

The test in last week’s post took a very long 29 hours to compute! A large contributor to the compute time was the result of a bug that did not allow some optimizations to kick-in as well as overkill in the amount of force field simulation accuracy in the simulation setup.

I made some modifications in the scene setup and ran some tests over the weekend to compare baking performance. In the original animation, the fluid character grows over time due to a large amount of added liquid. For these tests, the added liquid was removed so that the fluid would more closely conform to the character mesh shape, which would make it easier to compare results. The simulation was re-run without bug fixes and optimizations, and the animation without added liquid took about 27 hours to compute.

After adding a few small force field optimizations to the simulation engine, the compute time was then reduced to about 18 hours! But we can improve this time further with a simple optimization the force field setup.

Optimizing Force Field Resolution

The FLIP Fluids add-on is largely a grid-based simulator. Many different calculations are run on a 3D grid where the resolution setting controls how many times the domain is divided into voxels. The simulation voxel grid is similar to a 2D pixel grid in an image in the way that the size of a single pixel is the minimum amount of visual detail that can be resolved in the image. In a 3D simulation grid, the size of a single voxel is the minimum amount of physics detail that can be resolved in the simulation.

Like many other calculations in the simulator, force field calculations are also run on a grid. But the force field grid does not need to be the same resolution as the domain resolution. Depending on your effect, the force field grid resolution can be much lower than the domain resolution and still produce a good simulation result. Some force field calculations such as our volume force mode can be very computationally intense and using a lower resolution grid will help speed up these calculations.

Our upcoming force field feature set has a setting to choose the force field grid resolution using four quality modes: low , medium , high , and ultra . You will also be able to visualize this grid using our existing grid visualization tool in the FLIP Fluid Debug panel. Using the visualizer can help you determine which level of quality you will need.

Force Field Resolution Comparisons

Here is a comparison of baking times between different force field resolutions in the animated character volume force test:

https://gfycat.com/adorableflusteredasianconstablebutterfly

At the lowest resolution, the simulation time is reduced to 10h20m ! Each tests looks quite similar visually with some minor differences. To decrease baking time as much as possible in this scene setup, reducing the force field grid resolution to low or medium would be a good idea.

The reason why a a low force field resolution would be okay to use in this effect is because at this grid density, the size of a voxel is still small enough to capture the details of the mesh shape. Here is a comparison of the low , medium , high , and ultra grid resolutions using our grid visualization tool:

https://gfycat.com/angelicickyibadanmalimbe

More Development Notes

  • Blender 2.83 compatibility – Blender 2.83 released last week. The addon was tested with the official Blender release and it was determined that no changes were needed in order to stay compatible with the new release. Our Blender 2.8 support documentation was updated to include the 2.83 release as well as the 2.9x experimental releases.

  • Bug fix: possible divide-by-zero error in point-to-triangle distance calculation – A very rare bug could cause our point-to-triangle distance test to result in a divide-by-zero (NaN) error. This was found in a simulation setup where the mesh contained a specific arrangement of triangles around another triangle with zero area. It looks like this bug has been in the simulator since it’s creation, but was rare enough that we never noticed it until last week and we had never had a report of this issue. This issue was fixed by detecting a zero area triangle and reducing the distance calculation to either a single point or a line segment.

  • Bug Fix: Attribute Error when retrieving domain – A possible error message has been resolved when the add-on searches for the domain object. If Blender is in an incorrect context, an Attribute Error message would be displayed in the Blender System Console window. This error was harmless and did not affect the functionality of the add-on, but it’s still good to prevent error messages!

  • UI fix: Added checkboxes to collapsed submenus – In an earlier development post, we displayed screenshots of how we cleaned up the UI by making it possible to collapse submenus. We received a very helpful usability tip that pointed out a flaw in our design: When a submenu is collapsed such as viscosity or surface tension, you would not be able to tell whether the feature was enabled and you would not be able to quickly enable/disable this feature without re-opening the submenu. This has been fixed by adding a checkbox toggle to show whether the feature is enabled or not:

    collapsed_ui

  • UI Fix: Stats alignment issue – Fixed a possible usability/alignment issue when the FLIP Fluids Stats panel is set to show frame info. If you scrub through the timeline to see the frame info results, and you scrub past the point where there is available stats data, the panel will show a small Data Not Available message. This message causes the vertical height of the panel to be reduced, which causes a vertical UI shift in the properties panel. This issue has been very frustrating to me for a while because this vertical shift makes it needed to manually scroll the UI in order to see the stats panel again. This has been fixed by making sure that the vertical height of the panel remains consistent when there is both data available and not available.

  • Updated Whitewater Advanced Settings tooltips – Added a note to some tooltips that in most cases, you will only need to modify the settings displayed in the Basic Settings View. Modifying settings in the Advanced Settings view is rarely needed, and if you do not understand what some of the settings do, this could cause odd behaviour or no whitewater to be generated.

  • Force Field Optimization: Smoother Force Fields Force field grid data is now interpolated/smoothed when the force field grid does not match the domain grid. This results in smoother force field data at lower resolutions, which can allow you to get away with using a lower resolution force field in the simulation setup.

  • Force Field Optimization: Added Adaptive Timestepping for Force Fields option – This settings is similar to the Adaptive Timestepping for Obstacles option in the FLIP Fluids Advanced panel (both disabled by default). Force fields don’t need to be updated as frequently as other simulation calculations in order to remain stable. In most cases, force field calculations will only need to be updated on the first substep of a frame. Enabling this option will update force fields on every substep, and will add additional substeps if the force field is moving very quickly. Enabling this option will only needed if the animated force field object will move a large distance within the domain between frames.

  • Force Field Exporter Improvement – Added functionality to skip exporting animated force field data if it already exists in the cache. This is similar and functions in the same way as how animated Fluid/Inflow/Obstacle/Outflow objects can be skipped during export.

6 Likes

Our FLIP Fluids weekly development notes #23 is now posted! Weekly Development Notes #23 – Customer Support and Fixing Usability Issues.

Weekly Development Notes #23 – Customer Support And Fixing Usability Issues

Covering the week of June 8th – 12th, 2020.

Hey everyone, this is Ryan here with our 23rd development update for the FLIP Fluids addon for Blender! I’ll keep this update short since it’s been quite a busy week and there’s a lot that I’d to get done before Friday. Last week’s development almost entirely involved handing customer support. I was feeling a bit overwhelmed by the workload during last week, but it looks like we’ll be getting back to a normal workload by next week!

Keeping track of customer support requests

We have been receiving an unusually high amount of customer support requests during the past week. Here is a heatmap graphic showing daily support volume between January 6th and June 12th of this year:

Starting in January I have been keeping track of daily support request volume. Light green/yellow to dark green represent time spent on customer support during the work day, ranging from less than an hour on light days to four+ hours on heavy days. Blank days represent the weekend, or holidays and sick days.

The majority of the support requests over the past week were from new users of the FLIP Fluids addon fromt he past two months. Gaining feedback from new users is excellent for us in determining what can be improved to make the addon more friendly to beginners.

Möbius Strip Experiment

In this experiment, a Surface Force Field is aligned to the normals of a Möbius Strip, a non-manifold one-sided surface:

It looks like the Gfycat link is not currently working. At the moment, the animation can be viewed on our Twitter account here.

Development Notes

Many of the small developments over the last week are based on feedback and to prevent potential issues. Preventing issues from arising is very important to us because this allows for more time input into code development.

  • Blender Devtalk: Faster scene initializingArc4g posted a good question on the Blender Devtalk forum, which is why scene render initialization takes so long for whitewater particles? I have added a simple scene to the thread that can reproduce the issue using a simple script without the use of the FLIP Fluids addon. Hopefully we’ll get an answer or some insight to why this is happening.
  • Fixed FLIP Fluids stats display bug – Fixed a bug that could cause the FLIP Fluids stats panel to display the data from the previous simulation if viewed after resetting the cache.
  • Force Field Antigravity Implementation – It can be helpful to set a region within a force field to have lower, higher, or zero strength gravity. Last week I had a chance to add an implementation for all force field modes to allow for this using an gravity strength setting. Still a little bit of work to finish this feature.
  • Added a file to display info if the addon has been installed incorrectly – A common issue when installing the addon using the source code is that the source code .zip file is not actually an addon installation file. Instead of displaying nothing when installing the addon incorrectly, a ‘fake’ addon file has been added to display info about how to properly install the addon or how to get the addon.
  • Updated FLIP Fluids project page readme file – A source of confusion was that there are some differences between the features displayed on our GitHub project page and our Blender Market product page. The project page readme has been updated to redirect to the Blender Market page for the up-to-date list of features.
  • Added a reminder the Beginner Friendly Mode is active – The beginner friendly mode hides all but the most important settings of the addon. A source of confusion is that a user could forget the Beginner Friendly Mode is active and they will be wondering why settings are missing. I have added a text reminder in the Blender Physics Panel that this mode is active and how to disable this mode.
  • New documentation topic: Tips for Creating Ship Simulations – Added a topic for a very common question that we have been receiving: can the FLIP Fluids addon be used to create ship simulations. This topic provides tips and info on this topic.
  • Added missing operator for whitewater selection in FLIP Fluids toolshelf panel – The toolshelf panel contains come quick selection operators for selecting the whitewater mesh objects. The Dust object type was missing from this panel.
4 Likes

Thanks for the weekly updates! Really nice to read all the new cool features.
Is there an eta for a new experimental build to test all the new stuff out?

Great to hear! That’s a good question, and something I’ve been thinking about a lot recently. I haven’t decided yet whether there will be an experimental release before a full release of these features.

I really want to get this feature set ready and released as soon as I can, but without sacrificing quality (usability/stability). In my past experience, experimental releases are great for feedback, but they can add a lot of overhead in terms of requiring additional support for our userbase which takes away from time spend on code development and finishing the features.

I’ll think about this some more and address this in next week’s update.

Edit: Yes, we will start providing weekly experimental builds starting next week. More about this in the next development update on the 23rd or 24th.

1 Like

Our FLIP Fluids weekly development notes #24 is now posted! Weekly Development Notes #24 – Experimental Force Field Builds Starting Next Week!.

Weekly Development Notes #24 – Experimental Force Field Builds Starting Next Week!

Covering the week of June 15th – 19th, 2020.

Hello and welcome to our 24th development update for the FLIP Fluids addon for Blender! Last week’s development, as well as the week previous, was largely spent on handling customer support requests. Lately we have been receiving a larger than normal volume of support requests, possibly for the reason that we have so many new users learning simulation that have recently started using our FLIP Fluids addon!

So far for this week (June 22nd – 26th), the volume of support is a bit higher than average, but it is starting to reduce down to normal levels, so hopefully I’ll be able to get back onto a more regular development schedule soon.

Next week we will be starting to release weekly experimental builds of our work-in-progress force field feature set, and that is what I will cover in this post!

Force Field Experimental Builds

We have received an overwhelming amount of questions about when, or whether we will be releasing experimental builds for our upcoming force field features. At first I was hesitant about this idea. In my past experience, experimental releases are great for feedback, but they had added a lot of overhead in terms of requiring additional support for our user base which takes away from time that we can spend on code development and finishing the features.

So many of you are excited about these features and there is clearly a desire for experimental builds- even if the full feature set is not completely ready. After spending some time on this idea, I think we can handle experimental builds a bit differently this time. We’ll make some changes to our procedures so that we can create builds for you to test, while still giving us a good portion of time to continue and finish the development of the feature set:

  • Documentation – In past experimental versions, new features and settings were not documented until the stable release, which led to some confusion and many questions. Before releasing experimental builds, we’ll be preparing adequate documentation with clear guidelines on what can be expected in experimental builds.
    • It will be made as clear as possible (in the UI and documentation) that the experimental builds are not production ready and should not be used by new users to the FLIP Fluids addon.
    • If you are new to the FLIP Fluids addon, we would highly advise using the stable version rather than the experimental versions.
    • Scenes created in different experimental version may not be compatible with each other, including simulation caches created in different versions.
    • Scenes may break permanently due to bugs, so it would be recommended to save backups frequently.
  • Reduced SupportScene troubleshooting support, which accounts for a large portion of support time, will not be offered for the experimental builds. Full customer support will still be available for the stable releases.
  • Not all features will be available – Not all up-to-date features and changes will be released into the experimental builds. Some features will spend some time in internal development and testing before they will be considered ‘ready’ for experimental testing. Only the more stable features/changes will be included in order to avoid confusion and potential issues.
  • Communication Guidelines – We will provide a single GitHub issue thread for discussion, suggestions, feedback, and questions in order to concentrate information to a single location. We may not have time to answer all questions or respond to feedback in a timely manner, but we will be closely monitoring the thread.
  • Bug Reporting Guidelines – We are usually quite lenient with our bug reporting guidelines. In order to speed up development, we may be more strict with our reporting guidelines for experimental builds.
  • Example Scenes – We are creating a set of example scenes to show you how to use the features and help you get started with common force field effects. Until the stable release, these scenes will only be available in Blender 2.8+ (and 2.90). They will not be compatible with Blender 2.79.

The decision to release experimental builds will likely prolong the development of the force field features, but not as much in the past. Overall, I think the feedback gained from a ‘beta’ test of the features will be good for the long run in terms of stability and usability.

Weekly experimental builds will start on the next development update next week.

When will the stable force fields version be released?

This force fields feature set has been the largest and most ambitious feature we have developed for the FLIP Fluids addon, has taken quite some time- with many delays of which some have been outside of our control. We are not using Blender’s force field system due to limitations and we have been writing our own system from scratch. Many of the force field features have been popular requests, are specifically tailored to liquid physics, and are not possible using Blender’s built-in force field system.

We do not have a solid release date. We have a high standard for stability and usability which will not be compromised and the next version will be ‘ ready when it is ready ‘. We’re at a ‘ Coming Soon ‘ stage of development right now, but we do not want to set an exact date and end up missing it due to unexpected delays. When we do announce a date, the stable release will follow very shortly after, within two weeks.

Thank you for your patience!

Summer Vacation

A potential delay to the release is that force field development may intersect with my summer vacation, which I am overdue for! Development workload has been high in the past few months and I may take a well needed vacation away from the FLIP Fluids project for a short two or three weeks. I still absolutely love working on the FLIP Fluids addon, but sometimes I need a break to clear my head and re-energize to avoid burnout. I hope this will be understood.

Bringing back fluid control objects with volume forces!

One of the most popular requests we have had for our force field features has been to bring back the Fluid Control Object that was a feature in Blender’s older Elbeem simulator. Since Blender 2.82, this type of object is no longer available.

Our ‘ Volume Force ‘ mode, which directs fluid towards the interior of an object, can now be used in a similar way to the older control object feature. In this test, fluid in the shape of Blender’s Suzanne Monkey rises from a pool of liquid:

https://gfycat.com/readyhairydutchshepherddog

We will add this quick and simple example to the experimental build example scenes.

More Development Notes

  • Fixed force field render visibility bug – Fixed issues related to render visibility for force field objects to make these types of objects consisten with other FLIP Fluid objects (inflows/outflows/fluid/obstacles).
  • Completed force field antigravity settings – Completed and tested features that can be used to reduce or negate gravity inside or near force field objects. For example, by setting a low gravity or zero gravity inside a volume force, this can be used to mimic Blender’s older fluid control object.
  • Fixed out-of-range errors for force field objects – Fixed errors that could cause crashes and memory errors when force field objects are located outside, or partially outside of the domain.
  • Fixed issues related to force field compatibility with Blender 2.79 – We still support, and will continue supporting Blender 2.79 for a while! The force field features have been updated to be compatible with Blender 2.79.
  • Improved force field default values – To make it easier to use for many effects.
7 Likes

Hi there,
is there a chance to have inflows and outflows where I can specify the amount of liquid coming into the scene or leaving it? For instance an inflow object that gives an amount of 2 Liters per minute and an outflow of 1 liter per minute so that the amount of fluid is increasing over time?
Something like that would be highly appreciated. Not only by me I think.
Anyway. Many thanks for your incredibly good work so far :slight_smile:
Pete

At the moment, only emission velocity can be specified and not volumes. This type of feature can actually be a difficult thing to implement and may not be suitable for this type of simulator. The FLIP simulation method is a bit weird in that it does not really have a consistent concept of volume. Due to this, FLIP simulators are often not good at accurately preserving volume during the simulation. An inflow might emit fluid at a certain volume, but this mass of fluid can expand/shrink over time. Relevant documentation topic.

This type of feature can also become complex to implement on general and arbitrary inflow geometry. I think you would need to determine the cross sectional area of the object aligned to the flow direction, and this can get complex if the inflow is cut off by another object, or has varying cross sectional area at different areas of the mesh. This type of feature could be easier to implement if it were limited to simple shapes.

Although volume might not be consistent over time, you might still be able to simulate a rough estimate using inflow velocities. You will need to enable the Constrain Fluid Velocity inflow option to enforce the inflow emission speed. By simulating an inflow and outflow pipe, you can enforce how quickly fluid is added to, and removed from the simulation.

Here is a quick diagram:

Since the simulator only uses velocities, to estimate the emission volume you would need to make a few calculations by hand taking into account the cross sectional area of the inflow object.

For more accurate simulations like these, a particle based simulator such as one using the SPH (Smoothed Particle Hydrodynamics) method might be more suitable. The Blender particle system fluid is an SPH simulator and is able to preserve volume over time. For best accuracy, you would likely need a simulator aimed towards scientific/engineering use.

1 Like