Hey, this is Ryan here with the weekly development update for the FLIP Fluids Blender addon! Despite last week being a four day work week due to a holiday, it was surprisingly productive.
In this post I’ll add some notes and workflow tips about an animation posted earlier today, and cover what to expect for the next FLIP Fluids addon release next week (v1.0.8).
Hex Grid Island Doodle
This is something I’ve wanted to try for a while now and I’m glad I got a chance to experiment with this effect last week!
[gfycat data_id="nicevastgerenuk"]
In this animation, hexagonal pegs are made visible in proximity to the flowing liquid. I’ll try my best to add some notes and workflow tips for how this was created
Creating a hexagonal grid
I started by creating an object that is composed of just a single vertex. A series of array modifiers with appropriate X and Y offsets were used to generate a hexagonal grid pattern (or honeycomb pattern) of vertices. Vertices were selectively deleted and what was left are a few islands and a boundary to the islands.
For rendering, a six sided cylinder was used for the peg model and set as an instance over the vertex grid. For simulation, the peg geometry was merged and edited into a single object (covered later in this post).
This simulation setup required testing a few different simulation values. A workflow of simulating in a small domain to quickly iterate on finding the right settings was used before increasing the domain to the full size (also covered later in this post).
Dynamic paint as a displacement map
Blender’s dynamic paint feature was used to create a vertical displacement map for the hexagonal pegs. The fluid surface was set to a brush that paints a canvas with it’s geometry plus a large proximity radius for falloff. When this animated displacement map is used as a texture input to a displace modifier, it has the effect of gradually raising the pegs when the fluid is near.
[gfycat data_id="anxiousrawkronosaurus"]
This dynamic paint process is also known as a ‘wetmap’. Here are some tutorials on creating wetmaps using dynamic paint and Blender:
In addition to using the wetmap texture to displace geometry, it was also used in the material shader to color the pegs differently based on how close the peg is to the fluid surface.
No moving parts required in the simulation
No moving parts were required in the simulation, and this is good because moving obstacles take longer to simulate. All collision geometry is known beforehand and an obstacle representing the island boundaries was used.
[gfycat data_id="specifichandyamurminnow"]
Here are some details on how the grid of pegs were converted into a single obstacle for the simulation. Remember that the grid is composed of vertices that represent the location of the pegs with a single peg cylinder model instanced over the vertices. This may not be the best method, but is what worked for me as a beginner in modelling:
Used the Make Instances Real operator to convert all pegs to separate objects.
Selected all separate peg objects and joined them into a single object.
In edit mode, selected all geometry and merged vertices by distance. This joined all of the pegs together at their closest vertices.
The above step produces non-manifold geometry (geometry that can’t exist in real life), which is bad for simulation. The resulting geometry had inner faces inside the mesh where the hexagon pegs joined. I simply used Blender’s built-in 3D-Print Toolbox addon to automatically clean up the non-manifold geometry with it’s Make Manifold operator.
The 3D-Print Toolbox addon is helpful for detecting non-manifold geometry and repairing geometry in simple cases such as this one. The corrections are automated and not always perfect, so it’s always good to inspect the mesh afterwards. In this use-case, the operator created some hexagon shaped holes within the interior of the islands, but this will not end up effecting this simulation.
Emitting fluid from underneath the floor
In this simulation, fluid is emitted upwards from underneath the floor. Hexagonal holes were modeled into a floor obstacle to provide space for inflow objects.
Holes in the floor allow space for inflow objects to be placed
If you try to set this up with the default inflow settings, you will likely run into problems. By default, inflows will not emit or push fluid when fully submerged. This is where an interesting inflow option comes to the rescue: The Constrain Fluid Velocity checkbox!
There are a few applications of this setting: slowing down fluid emission, pushing around fluid when submerged, and in the case of this simulation, creating a pipe that can fill up a container when submerged (See documentation).
Here is a simple example .blend file in case you need some help getting started with this technique. This example can also be run in our free FLIP Fluids Demo addon.
Just press the bake button! Takes roughly 1 minute to simulate.
[gfycat data_id="showyfamousbee"]
Workflow Tip: simulating in a smaller domain volume to find the right settings
Finding the right combination of settings can be the most time consuming part of simulation work. Being able to iterate and test different settings quickly is crucial to workflow.
In this simulation setup, I was mostly concerned with how quickly the fluid spread as it was emitted from under the floor. For many simulation setups, the default domain values are good and only a few settings need to be changed to get the right look. In this scenario I mainly modified these settings to control how the fluid moves as it spreads:
Resolution – To control the level of detail in the physics. Not too low that it looks unrealistic, but also not too high that it would not take too long to simulate.
Inflow Velocity – To control how quickly the fluid should be emitted from the object.
Obstacle Friction – To limit how quickly the fluid spread out over the floor. Not enough friction can sometimes make the fluid-obstacle interaction look hydrophobic. Too much can make the fluid take too long to spread.
Surface Tension – To create more of a small scale look to the fluid. Increasing surface tension in this scenario creates a bit of a cohesive lip to the edge of the fluid as it spreads.
To test different combinations of values, I wanted to be able to iterate quickly between tests. I didn’t want to wait an hour just to see how changing one value affected the result. To quickly iterate, I created small domain centered around just one inflow, and in this scenario that is all that is needed to test how fluid will flow and spread. Simulating a smaller domain volume is much quicker!
[gfycat data_id="fastdistinctcat"]
With this small domain centered around one inflow, it took just over two minutes to run a 100 frame test. At 100 resolution, this domain contained only 200,000 voxels which is quite quick to simulate, and at this voxel size it seems like an adequate amount of detail for the simulation. For a comparison, scaling up the domain to the final size with the same level of detail increased resolution to 426 with 3.6 million voxels and took 45 minutes to simulate the 100 frames.
Tip: When simulating a smaller domain, you will not need to worry if your inflows, obstacles, or other simulation objects are located outside of the domain volume. The addon will take care of this for you and will make sure not to simulate objects that are outside of the domain.
A note on resizing the domain
In this workflow of testing a small region, when you eventually size up your domain to the final size you will want the level of detail and fluid motion to be consistent between both sizes. This will require you to proportionally increase resolution and world size as you increase the domain size.
Proportionally increasing resolution is important for maintaining a consistent level of physics details. The amount of detail is proportional to the grid cell size (or voxel size). You want the voxel size to be the same in both domain sizes. You can do this by enabling the Lock Cell Size option under the resolution setting. This is a workflow feature that automatically adjusts the resolution value as you change domain size so that level of detail is maintained.
Proportionally increasing the world scale of your domain (physical dimensions of the domain) is important for maintaining a consistent scale which affects fluid speed, and physics calculations such as viscosity and surface tension. If you are using the current FLIP Fluids version (1.0.7) with world scaling features disabled, you will not need to change anything. Scaling will be relative to 1 Blender Unit = 1 Meter in the simulation. If you ARE setting a specific world scale, you will need to re-calculate the scale value by hand. In the next version (1.0.8) we are adding a proportional world scaling workflow feature that handles automatic world scaling as you change domain size. More reading on this feature in this blog post: Weekly Development Notes #2 – Improving world scaling workflow.
The next release of the FLIP Fluids addon is coming soon and should be released sometime next week! This will be more of a maintenance update that fixes many reported issues in the addon. A lot of the fixes just change a small ways in how the addon behaves and prevents potential errors or frustrations from occurring. This is a type of update where if you don’t notice much of a difference, that means we will have done something right!
It might not seem like this is much of an update, but there are some large organizational changes to the codebase that I’m happy to finally get into the main branch of the addon. The largest code update is that engine and addon changes to support a huge future force fields feature is now included within the release. The force fields feature is not yet ready for release and the features will not be exposed to the UI, but by using this version you will be indirectly testing many of the codebase changes through regular simulation.
Over the course of this week I’ll be preparing the addon for the next release. Some of the tasks for preparing a new release involve:
Package the addon for Windows, MacOS, Linux
Need to fix my Linux system! It’s stuck in a boot loop at the moment and I’ll need to figure out what’s wrong.
Thoroughly test the packaged addon
Update documentation for new or changed settings and features
Update example scenes to use changed settings
Write the final changelog and release notes
Update Blender Market downloads and send out update notice
More Development Notes
Added workaround for issue that would cause mesh geometry to be exported incorrectly if the Hide from Viewports object option (monitor icon in outline) is used – This is a limitation of how the Blender exporters work according to a developer. Our workaround is to automatically re-enable this option during export to prevent this issue.
Fixed bug where edge split modifiers would not be ignored during mesh export – Edge split modifiers split edges which cause non-manifold geometry. The simulator requires manifold geometry so it is desirable to never process this modifier when the addon exports object geometry. There was a regression during the FLIP Fluids update to Blender 2.8 that would cause this modifier not to be ignored.
Removed ‘unsafe’ cache operations from UI – The move/copy operators in the FLIP Fluid Cache panel have been removed. These operators could cause potential dataloss/corruption of the cache if Blender happens to crash while modifying files. It would be much safer for the user to manually move/copy their cache using their filesystem.
Potential fix for 1st frame not rendering whitewater particles – There is a design issue in Blender that can cause crashes and random odd behavior in addons that update the scene on a frame change. This is the reason why the Blender interface should be locked in order to fully prevent render crashes. According to a developer, this will be fixed during regular development. A side effect of this issue is that it can cause whitewater particles not to render on the first frame of an animation, but we may have found a workaround.
Fixed bug that could trigger an error during command line baking – If command line baking was terminated in the middle of a simulation, the addon would not process some cache files and this could generate an error when resuming a bake from the command line. This has been fixed by making sure the addon finishes processing the cache files when starting the next command line bake.
UI change: Particle Scale will be displayed in red if the value is set to less than 1.0 – Mesh artifacts can occur if this value is set to less than 1.0, but is some use cases it is still okay to use values less than 1.0 so it should not be limited. This change is to prevent a common issue we receive in support where a user has set this value less than 1.0. The goal for this UI change is to alert the user and guide the user towards the tooltip or documentation which explains the issue.
UI change: removed optimization and performance settings from FLIP Fluid Advanced panel – These settings were generally used for testing decreased memory usage at the cost of an increased simulation time. At this point in development, they are no longer considered useful, or reduce memory by a significant amount, and will be removed to clean up the interface.
Added operators for copying command line baking/rendering commands to clipboard (Windows Only) – Due to bugs/conflicts in other addons or a security feature of Windows, it’s possible that the operators that automatically launch command line baking/rendering could not be run. I have added additional operators that copy the commands to your clipboard so that you can manually paste them into Windows CMD to start a command line bake/render.
Operator that automatically launches command line render no longer requires a FLIP Fluids Domain in the scene (Windows Only) – There was a limitation in the UI where this operator was blocked when not using the FLIP Fluids addon. We have removed this limitation so that you can still use the operator to render your scenes without a FLIP Fluids simulation.
Weekly Development Notes #9 – Workflow for iterating quickly on settings and the next FLIP Fluids release
Covering the week of February 17th – 21st, 2020.
Hey, this is Ryan here with the weekly development update for the FLIP Fluids Blender addon! Despite last week being a four day work week due to a holiday, it was surprisingly productive.
In this post I’ll add some notes and workflow tips about an animation posted earlier today, and cover what to expect for the next FLIP Fluids addon release next week (v1.0.8).
Hex Grid Island Doodle
This is something I’ve wanted to try for a while now and I’m glad I got a chance to experiment with this effect last week!
In this animation, hexagonal pegs are made visible in proximity to the flowing liquid. I’ll try my best to add some notes and workflow tips for how this was created
Creating a hexagonal grid
I started by creating an object that is composed of just a single vertex. A series of array modifiers with appropriate X and Y offsets were used to generate a hexagonal grid pattern (or honeycomb pattern) of vertices. Vertices were selectively deleted and what was left are a few islands and a boundary to the islands.
For rendering, a six sided cylinder was used for the peg model and set as an instance over the vertex grid. For simulation, the peg geometry was merged and edited into a single object (covered later in this post).
This simulation setup required testing a few different simulation values. A workflow of simulating in a small domain to quickly iterate on finding the right settings was used before increasing the domain to the full size (also covered later in this post).
Dynamic paint as a displacement map
Blender’s dynamic paint feature was used to create a vertical displacement map for the hexagonal pegs. The fluid surface was set to a brush that paints a canvas with it’s geometry plus a large proximity radius for falloff. When this animated displacement map is used as a texture input to a displace modifier, it has the effect of gradually raising the pegs when the fluid is near.
[gfycat data_id="anxiousrawkronosaurus"]This dynamic paint process is also known as a ‘wetmap’. Here are some tutorials on creating wetmaps using dynamic paint and Blender:
In addition to using the wetmap texture to displace geometry, it was also used in the material shader to color the pegs differently based on how close the peg is to the fluid surface.
No moving parts required in the simulation
No moving parts were required in the simulation, and this is good because moving obstacles take longer to simulate. All collision geometry is known beforehand and an obstacle representing the island boundaries was used.
[gfycat data_id="specifichandyamurminnow"]Here are some details on how the grid of pegs were converted into a single obstacle for the simulation. Remember that the grid is composed of vertices that represent the location of the pegs with a single peg cylinder model instanced over the vertices. This may not be the best method, but is what worked for me as a beginner in modelling:
The 3D-Print Toolbox addon is helpful for detecting non-manifold geometry and repairing geometry in simple cases such as this one. The corrections are automated and not always perfect, so it’s always good to inspect the mesh afterwards. In this use-case, the operator created some hexagon shaped holes within the interior of the islands, but this will not end up effecting this simulation.
Emitting fluid from underneath the floor
In this simulation, fluid is emitted upwards from underneath the floor. Hexagonal holes were modeled into a floor obstacle to provide space for inflow objects.
If you try to set this up with the default inflow settings, you will likely run into problems. By default, inflows will not emit or push fluid when fully submerged. This is where an interesting inflow option comes to the rescue: The Constrain Fluid Velocity checkbox!
There are a few applications of this setting: slowing down fluid emission, pushing around fluid when submerged, and in the case of this simulation, creating a pipe that can fill up a container when submerged (See documentation).
Here is a simple example .blend file in case you need some help getting started with this technique. This example can also be run in our free FLIP Fluids Demo addon.
inflow_pipe_example.blend (916kB) | Blender 2.81, FLIP Fluids 1.0.7
Just press the bake button! Takes roughly 1 minute to simulate.
[gfycat data_id="showyfamousbee"]Workflow Tip: simulating in a smaller domain volume to find the right settings
Finding the right combination of settings can be the most time consuming part of simulation work. Being able to iterate and test different settings quickly is crucial to workflow.
In this simulation setup, I was mostly concerned with how quickly the fluid spread as it was emitted from under the floor. For many simulation setups, the default domain values are good and only a few settings need to be changed to get the right look. In this scenario I mainly modified these settings to control how the fluid moves as it spreads:
To test different combinations of values, I wanted to be able to iterate quickly between tests. I didn’t want to wait an hour just to see how changing one value affected the result. To quickly iterate, I created small domain centered around just one inflow, and in this scenario that is all that is needed to test how fluid will flow and spread. Simulating a smaller domain volume is much quicker!
[gfycat data_id="fastdistinctcat"]With this small domain centered around one inflow, it took just over two minutes to run a 100 frame test. At 100 resolution, this domain contained only 200,000 voxels which is quite quick to simulate, and at this voxel size it seems like an adequate amount of detail for the simulation. For a comparison, scaling up the domain to the final size with the same level of detail increased resolution to 426 with 3.6 million voxels and took 45 minutes to simulate the 100 frames.
Tip: When simulating a smaller domain, you will not need to worry if your inflows, obstacles, or other simulation objects are located outside of the domain volume. The addon will take care of this for you and will make sure not to simulate objects that are outside of the domain.
A note on resizing the domain
In this workflow of testing a small region, when you eventually size up your domain to the final size you will want the level of detail and fluid motion to be consistent between both sizes. This will require you to proportionally increase resolution and world size as you increase the domain size.
Proportionally increasing resolution is important for maintaining a consistent level of physics details. The amount of detail is proportional to the grid cell size (or voxel size). You want the voxel size to be the same in both domain sizes. You can do this by enabling the Lock Cell Size option under the resolution setting. This is a workflow feature that automatically adjusts the resolution value as you change domain size so that level of detail is maintained.
Proportionally increasing the world scale of your domain (physical dimensions of the domain) is important for maintaining a consistent scale which affects fluid speed, and physics calculations such as viscosity and surface tension. If you are using the current FLIP Fluids version (1.0.7) with world scaling features disabled, you will not need to change anything. Scaling will be relative to 1 Blender Unit = 1 Meter in the simulation. If you ARE setting a specific world scale, you will need to re-calculate the scale value by hand. In the next version (1.0.8) we are adding a proportional world scaling workflow feature that handles automatic world scaling as you change domain size. More reading on this feature in this blog post: Weekly Development Notes #2 – Improving world scaling workflow.
Relevant documentation topics:
FLIP Fluids version 1.0.8 is coming soon!
The next release of the FLIP Fluids addon is coming soon and should be released sometime next week! This will be more of a maintenance update that fixes many reported issues in the addon. A lot of the fixes just change a small ways in how the addon behaves and prevents potential errors or frustrations from occurring. This is a type of update where if you don’t notice much of a difference, that means we will have done something right!
It might not seem like this is much of an update, but there are some large organizational changes to the codebase that I’m happy to finally get into the main branch of the addon. The largest code update is that engine and addon changes to support a huge future force fields feature is now included within the release. The force fields feature is not yet ready for release and the features will not be exposed to the UI, but by using this version you will be indirectly testing many of the codebase changes through regular simulation.
Over the course of this week I’ll be preparing the addon for the next release. Some of the tasks for preparing a new release involve:
More Development Notes