FLIP Fluids Addon: A liquid fluid simulation tool for Blender

[RLGUY]

Weekly Development Notes #48 – Three Years Since The FLIP Fluids Addon Beta!

Covering the week of February 8th – 12th, 2021.

Thanks for checking out our 46th development update for the FLIP Fluids liquid simulation addon for Blender! Last week’s work mainly involved updating how our simulation engine manages and stores fluid particles (More info in dev notes #47).

Slime Experiments From Artell Blender

Take a look at these satisfying slime simulations created by Artell Blender using our FLIP Fluids addon, the Molecular addon, and E-Cycles for rendering.

Slime Fun (Blender 2.92, Flip Fluids addon, Molecular addon)

Three years since the FLIP Fluids addon beta!

This time went by so quickly! On February 13th, 2018 we launched our FLIP Fluids addon beta test! During a 10 week period, over 250 testers helped us get the addon ready for launch on May 1st, 2018. When starting this project, we’d never expected the addon to become as popular as it is today, and we are super grateful.

Huge thanks to all of you beta testers who put in so much time help us, who had worked through the many bugs and crashes so that others wouldn’t have to!

Our original beta announcement can be viewed here:

FLIP fluids addon for Blender | call for betatesters

Force Field Experimental Version 9.0.9.14

This new experimental version update contains some large structural changes to how fluid particles are managed and stored, as well as adds some fixes to bugs reported since the stable release of FLIP Fluids 1.0.9a.

Want to try out these fixes? They can be tested in our Force Field Experimental Builds Package in the latest version!

Release Notes v9.0.9.14 (18-FEB-2021)

• This is the first experimental version since release of FLIP Fluids Stable 1.0.9a (03-FEB-2021).
• New system for storing and managing particles in the simulation engine (More info in development notes #47). This is a large structural change for how the simulator functions and may be a potential source of bugs. Please let us know if you are experiencing any of the following issues:
  • Crashes or error messages during baking.
  • Out of Memory errors or simulations using an unusually large amount of memory.
  • Inability to pause, resume, or upscale a simulation.
• Bug Fix: Issue where keyframing a min/max property could overwrite other min/max properties (issue #516).
• Bug Fix: Updated addon code to be compatible with Python 3.9. Some Linux distributions package Blender with Python 3.9 rather than the officially supported Python 3.7.
• Bug Fix: Removed extraneous debugging code that would cause (harmless) error messages in Blender 2.79.
• Bug Fix: Issue where the bake operator status could hang on Calculating time remaining….

[RLGUY]

Weekly Development Notes #49 – Viscosity Solver Improvements

Covering the weeks of February 15th – 26th, 2021.

Thanks for taking a look at our 49th development update for the FLIP Fluids liquid simulation addon for Blender! There wasn’t a dev update last week for the week prior as the work was mostly uninteresting: home office improvements, taxes, and a little bit of code cleanup.

However, last weeks development felt quite productive! I was able to finish up some large structural changes for how particles are stored in memory and in the simulation cache, added some functionality to the code to add custom attributes to the particles, and made some improvements to the viscosity solver.

Letter Transformation Using Force Fields

Check out Dennis’ cool force field test!

Letter Transformation using force fields (FLIP Fluids Addon)

This effect uses a volume force to attract liquid into letter shapes. Transitioning between letters was achieved by keyframing the force field strength between letter objects, like a crossfade. A little bit of viscosity was added for a smooth flow, and upping the smooth modifier created a very smooth surface. The hue shift was a post processing effect created in DaVinci Resolve.

Viscosity Solver Improvements

The viscosity solver has undergone some structural changes to improve accuracy in the solver set up and how memory laid out. Changes like these, especially in a solver, can be a source of new bugs. If testing today’s experimental version, please let us know about any issues when using the viscosity feature such as crashes, error messages, or unexpected behaviour.

Bug Fix: Stream Velocity Bias

I was finally able to solve a long-standing bug in the viscosity solver where low viscosity streams would have a large noticeable velocity bias in the positive X/Y/Z direction. This bug was reported 21 months ago (issue #455)! I had tried a few times in the past to fix this, but with no success until recently.

To take another shot at this issue, I started by re-writing the viscosity solver from the start. During this re-write, I had noticed a simple mistake in the code. Part of the solver requires shifting the offset of a grid position by half of a voxel width. The mistake I made was that I had applied this offset twice in different areas of the code (and in different files), leading to a total offset of 1 voxel instead of half of a voxel. This is what caused the stream to always have a bias in the +X/+Y/+Z direction.

Viscosity Accuracy Option

The viscosity solver works by running a loop where each iteration improves on the ‘solution’ to the viscosity equation. There is an internal ‘error tolerance threshold‘ within the viscosity solver that is used to determine when the solver should stop running the loop. The more iterations that are run, the more accurate the solution is, but this also takes longer to compute.

During some testing, I noticed that you could get away with a much higher error tolerance in some situations. We’ve added an Accuracy setting to allow for user control over the error tolerance.

Decreasing the accuracy can greatly speed up a simulation. For example, the Viscous Net example scene ran in about 5h10m at an accuracy of 4, and in 3h30m at an accuracy of 1. Note: the default value of 4 is the amount of error tolerance used internally in earlier versions of the addon.

Force Field Experimental Version 9.0.9.15

This new experimental version update contains some large structural changes to how fluid particles are managed and stored, how the viscosity solver functions, as well as adds some fixes to bugs.

Want to try out these updates? They can be tested in our Force Field Experimental Builds Package in the latest version!

Release Notes v9.0.9.15 (03-MAR-2021)

• Similar to the last experimental release, this version contains large structural changes in how the simulator functions which may be a potential source of bugs. Please let us know if you are experiencing any of the following issues:
  • Crashes or error messages during baking.
  • Out of Memory errors or simulations using an unusually large amount of memory.
  • Inability to pause, resume, or upscale a simulation.
  • Error messages when using a cache created by an older addon version.
• Safety Factor (CFL Number) setting in the FLIP Fluid Advanced panel has moved from the Simulation Stability section to the Frame Substeps section. The Safety Factor option is more closely related to how the simulator calculates adaptive substeps.
• Added an operator to the FLIP Fluid Helper sidebar menu to generate a Windows batch file (.bat) to command line render each frame of an animation one by one.
  • Operator will detect already rendered frames in the output directory and disregard these from the batch file.
  • Upon a render crash, the batch file will start up Blender again and begin rendering the next frame. In this way, you can minimize unrendered frames if your system is prone to render crashes.
  • Can be used outside of the FLIP Fluids addon to render a sequence of frames individually. There are some bugs in Blender which can cause an animation to be rendered incorrectly and a workaround to these issues is to render each frame one by one.
• Viscosity Solver Improvements
  • Large structural changes to the viscosity solver code and memory layout. Please let us know about any baking crashes, error messages, or incorrect behaviour.
  • Bug Fix: Fixed issue where low viscosity streams would have a velocity bias in the positive X/Y/Z direction (issue #455).
  • Improved accuracy of viscosity solver setup.
  • Added an Accuracy option to the viscosity solver to control the solver error tolerance.
    • Decrease to speed up baking at the cost of accuracy. Increase to improve accuracy at the cost of baking speed. High viscosity thick or stiff fluids benefit the most from increasing accuracy. Low viscosity thin fluids often work well at the lowest accuracy. Setting above a value of 4 may have greatly diminishing returns on improvement.
    • The default value of 4 is the same amount of error tolerance used internally in previous versions.
• Bug Fix: Fixed issue where disabling the whitewater feature and resuming a simulation would result in invalid whitewater cache files being generated in the cache directory.
• Bug Fix: Fixed typo in code that would cause an error that would prevent a helpful error message from being displayed (Pull Request Here).
• Bug Fix: Fixed UI issue where the Resume From Frame X label could be displayed in red text instead of the default white.

What’s Coming Next?

With the last few updates, there are have been some large changes in the code to allow for attaching custom attributes to particles and exporting attributes to the simulation cache. We’ll start by adding an optional ‘lifetime’ attribute to the fluid particles to control when generated particles should expire.

We’ll be updating with a new stable version of the addon in early April. _{And this version will have a nice ‘surprise‘ feature for you to play with}

[Pavel_Blend]

Hello, @RLGUY
I have a small feature request. Can you add one parameter for Particle Debugging? Now there is a checkbox Enable Particle Debugging, which enables saving particles to disk and displaying them in the viewport. Can you make two instead of this one?:

Enable Particle Debugging - saves particles to disk.

Show Particles Debugging - draws particles in a 3d window.

I am doing a simulation that will take a day. I turned on debug particles, but they bothered me, and I turned them off. But after resuming baking, I forgot to turn them back on. I want to render these debug particles. I will render the particles using my python script. But due to the fact that I forgot to turn them on, I do not have them in all frames. If there was a separate option show debug particles, then it would be possible to save particles, even if they are not visible in the 3D window.

[RLGUY]

Yeah, that would be a good option to add for the debug tools. I’ve run into the same problems.

[RLGUY]

Weekly Development Notes #50 – Collision Handling Improvements

Covering the week of March 1st – 5th, 2021.

Welcome to our 50th development update for the FLIP Fluids liquid simulation addon for Blender! Last week’s development mainly involved fixing a few bugs and adding a few small improvements. A nice improvement is that we were able to find a fix for a simulation stability bug that could cause simulations to ‘explode’ in certain conditions, and that is what will be covered in this post.

Melting Gold

A cool new test from Dennis! In this animation, the Blender 2.79 Fracture Modifier build was used to fracture the sphere along a path, letting molten gold to flow out. All materials were from the Extreme PBR Evo addon.

MeltingGOLD (FLIP Fluids Addon)

Fixing a Collision Handling Bug

This section will detail an important fix for a bug that could cause particles to become stuck on sharp edges of an obstacle, and in some cases would cause an unstable simulation.

Bug Report #1

In December 2020, PavelBlend reported an issue where fluid particles would become stuck to the borders of an obstacle (See issue #508). From the fluid particle debugging tool, it can be seen that the particles in red color have quite a high velocity even though they are not moving:

The reason for the high velocity particles is a side effect of how the FLIP method works where stuck particles can gain velocity and accelerate from the surrounding particles that are moving. If you set the PIC/FLIP ratio to 1.0 to make a completely PIC simulation, they wont have as high velocity but they will still stick.

Bug Report #2

Last week PavelBlend reported that a simulation becoming unstable and exploding. On the left is the unstable simulation, on the right is the simulation after fixing this bug:

https://gfycat.com/livesmartarrowcrab

After checking out the simulation, it looks like this instability was a side effect of the particles becoming stuck and gaining a high amount of velocity. In this image, the yellow highlighted particles show which particles are stuck while having a high velocity:

In the simulation, the stuck particles would continue to gain higher and higher velocities. Eventually a single particle would shift and become loose. Due to the particle’s extreme velocity, it would affect surrounding particles and create a chain reaction that would cause the entire simulation to explode.

There is an option that is enabled by default to automatically detect and remove particles with extreme velocities that would prevent this situation. However, this is not a good workaround for this bug. Due to the large number of particles that could become unstable, it would be better to fix the underlying problem that is causing particles to become stuck in the first place rather than using a workaround.

This bug was marked as a high priority to fix due to the potential problems this could cause in other situations.

Solving and fixing the issue

My guess was that the area of code that handles collision detection and collision response would be the cause of this bug.

Collision Detection and Response

Ideally, in a perfect simulation, the solver would never allow particles to flow into an obstacle and collisions would never happen. But due to limits in simulation resolution and numerical error, collision are inevitable and need to be handled.

In short, here is how the simulator handles fluid particle collisions:

• Obstacles are converted to volumetric data as a signed distance field (SDF). Collision detection is much quicker to compute with a SDF than a triangle mesh. SDFs are also already computed and used in many other areas of the simulator.
• If a particle is close to an obstacle’s surface, a collision check is run:
  • A particle’s path with be incrementally traced from it’s start location to it’s end location. If at any point this path intersects the obstacle’s volume, a collision will be detected and then handled.
  • If a collision is detected, the simulator will attempt to use the SDF data to project the particle to the closest location that is outside of the obstacle. If the simulator is unable to find a suitable location, such as if the projected position ends up inside another area of the obstacle or inside another obstacle, the collision response will have failed and will be handled by reverting the particle back to it’s starting location.

Detecting Stuck Particles

The way I usually start with bugs related to particle behavior is to detect the problem particles, isolate them into a smaller group and output what those particles are doing in the code to find a pattern.

In this bug fix, I started with detecting which particles have become stuck. I considered a particle that remained in a position close to it’s starting position and also that has also failed it’s last two collision responses to be ‘stuck’. This text output prints the number of stuck particles frame by frame:

2, 4, 5, 7, 10, 16, 19, 26, 32, 37, 44, 52, 57, 68, 81, 97, 109, 121, 131, 152, 170, 12, 12, 37, 41, 106, 108, 138, 150, 179, 196, 212, 229, 244, 265, 281, 298, 324, 378, 405, 422, 442, 466, 504, 535, 561, 583, 643, 8, 8, 632, 24, 24, 631, 188, 195, 575, 431, 446, 565, 557, 574, 605, 622, 646, 669, 682, 704, 729, 748, 771, 794, 66, 66, 702, 723, 741, 764, 784, 811, 793, 817, 864, 888, 368, 375, 760, 782, 593, 608, 740, 769, 741, 760, 788, 808, 822, 842, 863, 878, 892, 909, 935, 956, 970, 997, 1016, 1041, 1047, 1062, 1089, 1105, 1102, 1119, 1152, 1169, 1158, 1172, 1191, 1209, 1214, 1229, 1263, 1285, 1253, 1273, 1316, 1340, 1242, 1253, 1336, 1355, 973, 987, 1212, 1230, 1178, 1186, 1238, 1249, 1245, 1260, 1284, 1300, 1318, 1338, 1346, 1357, 1360, 1409, 1416, 1423, 1429, 1426, 1421, 1458, 1468, 1482, 1502, 1523, 1527, 1567, 1582, 1590,

The number of particles peaks at about 1600 before becoming unstable. There are about 160,000 particles in this simulation and having 1% of them becoming stuck is not good at all.

Why are particles becoming stuck?

Visualizing the obstacle’s SDF using the obstacle debugging tool shows jagged artefacts at the obstacle’s edges:

These jagged artefacts are due to the SDF data being aligned to a 3D grid of voxels. Since the obstacle is at a slight angle and the simulation is relatively low, these artefacts are quite noticeable in the underlying simulation. Particles are becoming stuck near these artefact locations:

The SDF data near these sharp jagged edges is not very good or consistent, and this affects how particles are projected outside of the obstacle in a collision response. The collision response is failing in part due to artefacts in the SDF data.

Improvement #1: More accurate collision detection

After looking at the SDF data, I found that the accuracy decreases as the particle penetrates deeper into the obstacle’s volume. But the SDF data very close to the surface of the obstacle is much better. The fix for this is to detect the collision point closer to the surface before the particle becomes too embedded inside of the obstacle.

This can be improved by decreasing the incremental distance that a particle is traced in a collision detection. Before this change, a particle was stepped in increments of 0.5 voxels. Changing this to 0.1 voxels makes it so that the collision is detected at most 0.1 voxels deep into the obstacle. Here are the stuck particle counts after this change:

1, 1, 1, 1, 1, 1, 1, 2, 2, 3, 3, 5, 5, 6, 6, 6, 8, 9, 10, 10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 5, 6, 7, 8, 8, 9, 10, 14, 17, 19, 22, 24, 26, 30, 36, 37, 38, 40, 42, 45, 46, 47, 48, 47, 49, 50, 53, 54, 56, 56, 60, 62, 64, 66, 67, 71, 72, 73, 75, 76, 81, 81, 81, 81, 84, 0, 0, 24, 66, 69, 71, 72, 72, 72, 75, 77, 79, 83, 86, 87, 88, 93, 95, 99, 103, 104, 105, 107, 107, 108, 110, 111, 114, 116, 119, 116, 116, 118, 120, 121, 121, 121, 121, 121, 123, 126, 124, 127, 127, 125, 125, 124, 121, 121, 123, 123, 123, 126, 126, 125, 128, 128, 128, 129, 131, 131, 132, 131, 132, 133, 133, 133, 135, 136, 135, 135, 135, 134, 135, 135, 134, 135, 135, 136, 136, 136, 136, 136, 136, 136, 136, 136, 137, 137, 138, 138, 138, 138, 139, 140, 140, 140, 141, 142, 144, 141, 142, 143, 146, 147, 148, 142, 143, 142, 143, 142, 143, 141, 141, 140, 140, 137, 137, 126, 126, 127, 130, 128, 129, 129, 129, 113, 113, 113, 116, 117, 118,

The counts are much lower after this change! But still not great. The step distance could be changed to 0.01 or 0.001 for a better result, but the returns are diminishing and has a larger performance impact.

It looks like particles are not becoming stuck permanently, and this is preventing the simulation from becoming unstable. So that’s a good start.

Improvement #2: Randomizing starting position

In addition to the first improvement, I tested randomizing the starting position of the collision test for particles that continue to be stuck. Remember: in the case that a collision response fails, the particle reverts back to it’s original location before the collision. By adding a very small randomness to the starting position, it seems that this helps prevent particles from trying to solve and fail at the same collision check over and over again.

Here are the stuck particle accounts with improvements 1 and 2 applied:

1, 1, 1, 1, 2, 2, 3, 4, 4, 4, 5, 5, 5, 5, 6, 6, 6, 7, 11, 14, 17, 19, 19, 21, 22, 27, 28, 3, 4, 6, 9, 9, 14, 16, 20, 20, 23, 25, 25, 29, 30, 31, 34, 37, 40, 38, 43, 42, 43, 44, 46, 49, 50, 51, 53, 53, 55, 52, 54, 41, 42, 0, 0, 0, 0, 14, 20, 11, 10, 10, 13, 13, 14, 15, 17, 17, 18, 19, 22, 24, 25, 28, 29, 29, 32, 17, 19, 23, 24, 0, 0, 1, 2, 3, 4, 4, 5, 5, 7, 9, 15, 13, 13, 3, 3, 5, 6, 7, 10, 13, 15, 18, 19, 23, 24, 27, 29, 30, 32, 32, 36, 38, 40, 41, 43, 44, 45, 47, 46, 45, 46, 49, 49, 0, 0, 3, 25, 0, 0, 2, 8, 0, 0, 0, 0, 0, 0, 1, 6, 9, 12, 13, 14, 17, 20, 21, 23, 22, 24, 25, 26, 28, 30, 25, 27, 0, 0, 0, 8, 8, 10, 11, 13, 14, 15, 16, 18, 22, 24, 25, 26, 28, 31, 31, 33, 34, 0, 0, 0, 2, 2, 2, 2,

Better, but can still be improved!

Improvement #3: Resetting particle velocity

As a last resort, in the case that the particles are still stuck, they will have their velocities manually reset to a velocity based on nearby stable particles. This will be like the stuck particles being simulated with 100% PIC velocity for a frame while disregarding FLIP velocity. I usually like to leave velocity handling completely to the solver, but in this case I think it is acceptable to modify the small number of particles.

After this change, there are 0 particles that are stuck for more than one frame in a row. In these following counts, these are the number of particles that become stuck for a single frame rather than two frames:

1, 1, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 4, 5, 5, 7, 8, 10, 10, 13, 14, 13, 12, 10, 9, 10, 10, 8, 6, 6, 7, 6, 6, 5, 4, 4, 3, 3, 2, 2, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 5, 6, 6, 6, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 2, 2, 3, 3, 3, 3, 1, 1, 1, 2, 2, 2, 2, 2, 2, 3, 4, 5, 5, 5, 5, 5, 3, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 6, 6, 5, 5, 4, 3, 3, 3, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 2, 2, 2, 2, 2, 3, 3,

Those are nice low numbers for how many particles are failing their collision responses! The changes to the code are very small, but we will still keep an eye on fluid-obstacle collision and interaction to make sure there are no bad side-effects.

Force Field Experimental Version 9.0.9.16

Want to try out these updates? They can be tested in our Force Field Experimental Builds Package in the latest version!

Release Notes v9.0.9.16 (10-MAR-2021)

• This version adds a few bug fixes and improvements.
• Bug Fix: Fixed an issue where many particles could become stuck to sharp obstacle edges which could lead to an unstable simulation (issue #508).
• Bug Fix: Potential fix for render crashes when the Fluid Particle Debugging or Force Field Debugging tools are enabled (issue #521).
• Bug Fix: Fixed error messages in Blender 2.79 due to difference in icon names in Blender 2.8+.
• Bug Fix: Fixed issue in Blender 2.91+ where rendering fluid meshes with motion blur enabled could result in longer Cycles render times.
  • Note: Motion Blur Rendering of fluid surfaces or whitewater particles is not currently supported (See: Motion Blur Support).
  • This fix will only apply to newly created scenes. To workaround this issue in an existing scene, select a fluid/whitewater object and disable the Object Properties > Motion Blur option (only applies if Cycles is the selected renderer).
• Added a UI warning and tooltip if the Estimated Surface Tension Substeps info value exceeds the allowed Max Frame Substeps Value (Documentation).
• Added viewport visibility toggles to the fluid particle, force field, and obstacle debug tools.

[rbx775]

@RLGUY

Another example of why a better particle system is needed would be in adding an APIC (Affine Particle-In-Cell) solver which requires a 3×3 matrix to be attached to each particle.

APIC sounds great!
Would PolyPIC then also be possible for even better vorticity conservation and elasticity?

[RLGUY]

I don’t know much about PolyPIC, I’ve only just skimmed through the paper quickly. At first glance it does looks more complicated and more involved to develop compared to APIC, but it’s something to look further into!

[rbx775]

I cant believe I forgot to append the Video!

A Polynomial Particle-In-Cell Method

Happy to hear that you are intrigued!
Cant wait to play around with your APIC update!

[Bernardo]

Hi! I guess I’ve become a regular visitor of this thread with some question about how to achieve results

So… this time what I am trying to achieve is something like this:

https://www.behance.net/gallery/86999653/Chocolate

I am playing mainly with viscosity, but I wonder if sheeting and surface tension might help me as well?

The main difficulty I am encountering at the moment is achieving a really thin sheet of chocolate (so maybe I need sheeting? ) without it being all broke and jagged during the simulation.

Another challenge is trying to maintain a bit of shape once the chocolate starts folding onto itself, without it looking a piece of cardboard

Hope I managed to explain things properly!
Thanks in advance for any help!

[RLGUY]

Hi! I was working on something similar recently, so this type of simulation is still fresh in my mind. Here are some tips:

• Create an inflow that is as thin as you want
• Turn on grid visualization (FLIP Fluid Debug panel) and increase resolution so that the thickness of the inflow covers at least 1 grid cell. 2 grid cells of thickness is better, and even more is best if you have the compute power or patience (Relevent Topic: What is the simulation grid?)

• Turn on Jitter Surface Particles (FLIP Fluid Advanced panel) - this emits particles of the thin sheet in a randomized pattern which helps with stability in thin sheets and can help prevent patterned breaking
• I would suggest turning on sheeting. The default values are usually good.
• Small amount of surface tension could help with realism, but isn’t always needed.
• Setting FLIP Fluid Surface subdivisions to 1 or 2 are usually good.
• I usually use a huge amount of smoothing on these types of simulations. Often up to or more than 60+ smoothing iterations on the smooth modifier.

@Bernardo

Another challenge is trying to maintain a bit of shape once the chocolate starts folding onto itself, without it looking a piece of cardboard

From the reference description, the artist used spatial variable viscosity to thicken the chocolate over time, which would help but this is not a feature of the FLIP Fluids addon. I would suggest just tuning viscosity to what looks best. You could also try keyframing viscosity to increase near the end, but this will thicken the entire domain of fluid.

Hope this helps!

[Bernardo]

thank you so much as usual for all the great tips!!

I’ll report back!

[RLGUY]

Weekly Development Notes #51 – Experimental Version Testing

Covering the week of March 8th – 12th, 2021.

Welcome to our 51st development update for the FLIP Fluids liquid simulation addon for Blender! Last week’s work mostly involved testing the latest experimental version to prepare the addon to be as stable as possible for the next stable release, set during the week of April 5th. Thanks for helping us test the addon and for all of the issues you have reported!

Simple Whitewater Stream

Just a simple inflow stream and a few minutes of simulation time at a low resolution of 100 is enough to show the satisfying and swirly motion of bubbles underwater!

https://gfycat.com/thickunevencoypu

Particles were shaded using an emission node with varied colour based upon the particle’s position on the Y axis. Here’s a top-down view of the domain:

Force Field Experimental Version 9.0.9.17

Want to try out the latest updates and fixes? They can be tested in our Force Field Experimental Builds Package in the latest version!

Note: A large focus and goal of these experimental releases is still to add changes that complement and accommodate for more force field features, but there are also developments that benefit other areas of the simulator as well. Many of the changes, fixes, and additions to the experimental versions are becoming less related to the Force Fields feature set. We’ll soon be renaming them and updating our documentation to just call these Experimental Versions and Experimental Builds Packages to avoid confusion.

Release Notes v9.0.9.17 (17-MAR-2021)

• This version is a minor release containing only stable bug fixes and improvements as we get ready for the next stable release, version 1.0.9b, set during the week of April 5th. Thanks for all of your testing and reports!
• Blender 2.93 Alpha support: As of the March 11th daily build, there are no know compatibility issues between the FLIP Fluids addon and Blender 2.93. Issues related to Blender 2.93 compatibility can be reported and tracked in issue #519.
• Bug Fix: Error message when using command line batch baking operator if render output directory does not exist ont he filesystem.
• Bug Fix: UI issue where domain FLIP operator displayed the hide/show viewport/render icons in reverse order compared to regular Blender convention.
• Bug Fix: Bug where using the inflow Constrain Inflow Velocity option could cause a bulge to form in the lower x/y/z corner of the domain.
• Bug Fix: ValueError that could be triggered upon creating a domain if the .blend file was located on a different drive than the Blender installation.
• Bug Fix: Potential issue where instanced particle objects could have Motion Blur enabled, causing longer render times in Blender 2.91+ (related to similar fix in v9.0.9.16).
• Fixed: Bug where using the FLIP Fluids Helper > Solid/Wireframe operator would deselect Fluid/Inflow/Outflow objects after execution.
• Changed: The FLIP Fluids Helper > Solid/Wireframe operators no longer change the render visibility of the objects. This functionality has been split into a separate row of Show/Hide Render operators that sets the render visibility of all selected objects.

[rafal_w]

Hi!
Short question:
Is it possible to use the addon to generate mesh from imported point clouds?

[RLGUY]

Hi! It won’t be possible to use the addon for generating meshes outside of fluid simulation. The mesh generator was only designed to work with generating meshes from our simulation data.

[rafal_w]

Ok, thanks for the quick answer.

[RLGUY]

Weekly Development Notes #52 – Blender 2.93 Geometry Attributes

Covering the week of March 15th – 19th, 2021.

Hey, it’s our 52nd development update for the FLIP Fluids liquid simulation addon for Blender! Similar to the last update, the past week’s work mainly involve a lot of testing to get ready for the next stable release. I also had a chance to try out a cool new feature in Blender 2.93: custom geometry attributes that can be accessed in Cycles.

Custom Geometry Attributes

With the new geometry attribute features in Blender 2.93 Alpha, we can now export custom data from our FLIP Fluids engine that can be accessed in through a Cycles Attribute Node for rendering. Here’s an example of exporting velocity to the surface mesh:

https://gfycat.com/unhealthytedioushorsefly

In this test, we used the new Blender Python API feature to attach velocity vectors to each vertex on the mesh. The vector could then be accessed in a Cycles shader through an attribute we set called flip_velocity:

This opens up so many possibilities for new shading features as we can now attach different types of data to our simulation meshes including vectors, colours, and numbered values. Some possible examples:

• Shading based on velocity direction, velocity speed, and vorticity
• Shading based on particle age and particle remaining lifetime
• Shading based on fluid inflow sources (ex: multiple material fluids)

This Blender functionality couldn’t have come at a better time as our recent development work has been centred around expanding our attribute import and export functionality within the simulation engine.

Prototype Build

Want to play around with velocity based shading? We have created a very early proof-of-concept build if you are interested. This is a single-purpose build only meant for use in testing velocity attribute simulation and rendering. The code is not yet optimized or in a good design, but is functional under the current limitations. The feature is also partially incomplete as there are missing features in the Blender 2.93 Python API that are needed for full functionality.

Notes:

• Only supported in Blender 2.93 (Alpha builds can be found here). This build may break as Blender 2.93 develops.
• The Generate Velocity Vectors option in the FLIP Fluid Surface panel must be enabled before baking.
• Whitewater features are not yet supported. A required geometry attribute transfer for instanced particles feature is not yet implemented in Blender 2.93.
• Frequent render crashes are expected. There is a suspected bug in Blender 2.93 that is causing render crashes due to our addon accessing attributes between frames (similar to T60094). This is something we will need to investigate and report on. It is recommended to render via command line as a workaround.

Accessing the Prototype Build

As this is a very early single-purpose build, the feature is not yet suitable to be included in our regular experimental releases package. Instead the build can be found in the Older_Versions_(unzip)_(24_mar_2021).zip package (See product downloads).

After unzipping this file, the installation file, notes, and an example .blend file can be found in experimental releases > misc > velocity_geometry_attribute_prototype.

[RLGUY]

Weekly Development Notes #53 – New Stable Version Next Week!

Covering the week of March 22nd – 26th, 2021.

Thanks for checkout out our 53rd development update for the FLIP Fluids liquid simulation addon for Blender! Last week was more testing and minor fixes. Just a tiny update today (and two days earlier than normal) as we’ll be quite busy this week getting ready for the next stable release of the FLIP Fluids addon, version 1.0.9b, on April 6th, 2021.

Experimental Version 9.0.9.18

Want to try out the latest updates and fixes? They can be tested in our Experimental Builds Package in the latest version!

Release Notes v9.0.9.18 (31-mar-2021)

• This version is a minor release containing only stable bug fixes and contains almost every change that will be included in the next stable release, FLIP Fluids 1.0.9b (April 6 2021).
• Bug Fix: ‘TypeError’ that could be triggered in Blender 2.93 by pressing the F3 operator search key.
• Bug Fix: Removed deprecated cache operators (Copy/Move/Rename) from being searchable and executable in the F3 operator search menu.
• Bug Fix: Fixed UI issue where bake information would not be updated when using the Reset operator if the current cache directory did not exist.
• Bug Fix: Fixed missing icon errors in Blender 2.79 due to icon renaming in Blender 2.8+.
• Example Scene Fix: Fixed volume_force_animated_character.blend example scene issue where the fluid objects would be emitted in the wrong direction. Corrected in the example scenes file as of March 25, 2021.

[RLGUY]

Blender Market Summer Sale: April 7th - 11th

- YouTube

As usual, we like to give a bit of an advance notice for upcoming sales.

The Blender Market Spring Sale begins next week! Starting April 7th, our #FLIPFluids addon and so many other amazing #b3d products will be 25% off. We’ll also be releasing FLIP Fluids v1.0.9b next week with cool little surprise feature. Can’t wait to tell you about it!

This was our first fluid simulation that we had rendered using LuxCore renderer. We’re loving the caustics!

2021 Customer Reel

We’re also calling for participants in our 2021 Customer Reel. We had so much fun seeing all of your work and producing the artists reel last year and have been looking forward to getting started on this year’s reel. Interested in participating? You can check out the info, guidelines, and last year’s reel here: https://flipfluids.com/customer-reel-2021/

[nate066]

Any chance for viscoelastic simulation, the only software that I’ve found supports it is real flow. Would be great to see it in flip fluids as well.

[RLGUY]

Viscoelastic/viscoplastic solvers would be very helpful. I had read some papers on this in the past, but I had struggled to understand the math/physics side of the research and how to relate the methods to programming. It would be good to take another look at again, but to be honest, I think it will take me a few more years of simulation programming experience to improve my understanding enough for a good implementation.