Hey everyone, this is Ryan here with this week’s development update of the FLIP Fluids addon for Blender! Our volume of support requests have been lowering over the past month after catching up from our Winter break and after adding some helpful documentation topics. That means more time for code development! This week I had a chance to fix some older bugs and improve how the simulation cache is stored.
Boat Doodle
[gfycat data_id="opulentcelebratedgrayling"]
This little boat doodle was created while testing some changes to the FLIP Fluids cache (described in the next section). Based on Derek Elliott's Boat Animation.
Here is an OpenGL render of the scene to show how this animation works:
[gfycat data_id="liveblackadouri"]
A domain with an inflow at one end and outflow at the other creates a ‘conveyor belt’ of liquid to flow past the boat. The highlighted object is set as a custom meshing volume in the FLIP Fluid Surface panel to generate the fluid island shape.
Important note: there is also an outflow behind the inflow to create an air-gap between the generated fluid and the domain wall. Without the air-gap, there can be a sort of a suction force against the domain wall that prevents the inflow from flowing consistently.
FLIP Fluids Cache Improvements
The FLIP Fluids addon stores all of it’s simulation data into files on your computer in a location called the cache directory. I had a chance this week to fix some some bugs and make some improvements to how the addon stores it’s cache files.
Bug Fix: Allow special filesystem characters to be used in Blender object names
When you set a Blender object as a FLIP Fluid object (such as an Inflow/Outflow/Obstacle), the addon exports the object’s data to files located in the cache directory. There was a flaw in how the addon stores these files: the files were saved using the name of the Blender object. This could cause errors if the object name contained special characters reserved for your OS filesystem, such as: \ / : * ? " < > |
For example, if you had an object named AlembicExportFromMaya:CharacterRig on Windows, this would generate an error in the addon:
NotADirectoryError: [WinError 267] The directory name is invalid: 'C:\\Users\\ryanl\\AppData\\Local\\Temp\\untitled_flip_fluid_cache\\export\\AlembicExportFromMaya:CharacterRig'
In addition to special filename characters, there are also reserved filenames on Windows OS. Try to name a file after any of these names and you will find that it is not possible:
To fix this issue, object names will now be stored on the filesystem by ‘slugifying’ the name, which is a technique used in generating URLs for webpages. The Blender object name will be converted using a whitelist of characters and truncated to 48 characters:
Characters not on the whitelist will be replaced with a dash -. To avoid collisions in edge cases, a 16 hexdigit hash based on the original object name will be appended to the end of the filename. Here are some examples:
Object Name
Slugified Name
Cube.001
Cube-00145c72b5baa3ac7e7
MyFluidObject
MyFluidObjecta3c4a8f8028486da
CharacterMesh()
CharacterMesh–353e4a838993eb7d
CharacterMesh)(
CharacterMesh–0378c26633a7bb14
con
con7ed201fa20d25d22
This bug fix will be included in the next version of the FLIP Fluids addon (> 1.0.7). Until this fix is available, a workaround is to not use special filesystem characters for your FLIP Fluid objects.
More Cache Fixes:
Bug Fix:Issue #477 OSError: [Errno 22] Invalid argument when simulation contains large amount of fluid/particles – If you try to run a very very large simulation (around 120 million particles), the cache files can be very large and there is a possibility that you could encounter an error when reading/writing the cache files. Depending on your system, there may be a limit to how much data you can write or read at once. This issue has been fixed by reading/writing files in smaller chunks instead of all at once.
Improvement:added a fail safe in the case that you run out of storage space – At the end of each frame, the simulator stores a file that contains all of the current simulation data that we call a savestate. This is how the addon is able to resume the simulation after pausing. If you happen to run out of storage space, there is a possibility that this file will not be completely written and become corrupted and you would not be able to resume your simulation. This has been fixed by not deleting the previous frame savestate until the current frame savestate has been completely written. In the case that you run out of storage space, the last savestate will still be intact and you will only lose 1 frame of progress!
Tracking Technical Support Requests
One of our main focuses during development that we pride ourselves on is providing quality support for our users Monday through Friday! Support is a very important aspect of maintaining the FLIP Fluids project. The types of support requests and volume we receive let us know how our users are using the addon and give us ideas for how to improve the addon.
Starting in January, I have been keeping a log of support request volume to see any patterns. If we’re spending a lot of time handling support for common issues, this could indicate that an area of documentation or learning resources is lacking in information. And this time spent on support takes away time from code development, which is also a very important part of our development.
Here is a daily heatmap covering January 6th to February 10th:
The large volume of support at the start of January can be attributed to catching up after our Winter break. There were a few topics that I found myself repeating during January and spent some time updating the wiki/documentation on some well-needed topics. Later into January and beginning in February, I found myself needing to spend less time on support due to catching up after the break and also being able to link to quality documentation topics that help solve our users’ issues.
More Development Notes
Testing AMD ProRender compatibility – We had a question whether FLIP Fluids is compatible with AMD ProRender. After testing, it looks like all FLIP Fluids features are supported and no changes for compatibility are needed. However, there are some performance issues when rendering a large number of whitewater particles (3million+), which rely on Blender’s instancing system. These issues are outside of our control and it looks like this is a known issue in ProRender, so hopefully it can be improved.
Rendering a large number of particles in our tests required a larger amount of RAM: 14GB in ProRender vs 5GB in Cycles. This did not affect amount of VRAM required and seemed consistent between ProRender and Cycles. There was also a longer render setup time: 105sec in ProRender vs 15sec in Cycles.
Fixed some problems in our product Example Scenes. Locking the Blender interface (Blender > Render > Lock Interface) is required during render to fully prevent crashes. Some example scenes were missing this option, which could lead to crashes and confusion! This has been fixed and re-uploaded to the Blender Market.
Restructured our development repository. As the codebase and project grows, we need to become more organized in our development. I spent some time cleaning up our repository and we’re now using the Gitflow Workflow.
Weekly Development Notes #7 – Bug Fixes and Caching Improvements
Covering the week of February 3rd – 7th, 2020.
Hey everyone, this is Ryan here with this week’s development update of the FLIP Fluids addon for Blender! Our volume of support requests have been lowering over the past month after catching up from our Winter break and after adding some helpful documentation topics. That means more time for code development! This week I had a chance to fix some older bugs and improve how the simulation cache is stored.
Boat Doodle
[gfycat data_id="opulentcelebratedgrayling"]This little boat doodle was created while testing some changes to the FLIP Fluids cache (described in the next section). Based on Derek Elliott's Boat Animation.
Here is an OpenGL render of the scene to show how this animation works:
[gfycat data_id="liveblackadouri"]A domain with an inflow at one end and outflow at the other creates a ‘conveyor belt’ of liquid to flow past the boat. The highlighted object is set as a custom meshing volume in the FLIP Fluid Surface panel to generate the fluid island shape.
Important note: there is also an outflow behind the inflow to create an air-gap between the generated fluid and the domain wall. Without the air-gap, there can be a sort of a suction force against the domain wall that prevents the inflow from flowing consistently.
FLIP Fluids Cache Improvements
The FLIP Fluids addon stores all of it’s simulation data into files on your computer in a location called the cache directory. I had a chance this week to fix some some bugs and make some improvements to how the addon stores it’s cache files.
Bug Fix: Allow special filesystem characters to be used in Blender object names
Issue report located here: #462 NotADirectoryError when exporting objects that contain special filesystem characters in the name
When you set a Blender object as a FLIP Fluid object (such as an Inflow/Outflow/Obstacle), the addon exports the object’s data to files located in the cache directory. There was a flaw in how the addon stores these files: the files were saved using the name of the Blender object. This could cause errors if the object name contained special characters reserved for your OS filesystem, such as:
\ / : * ? " < > |For example, if you had an object named AlembicExportFromMaya:CharacterRig on Windows, this would generate an error in the addon:
NotADirectoryError: [WinError 267] The directory name is invalid: 'C:\\Users\\ryanl\\AppData\\Local\\Temp\\untitled_flip_fluid_cache\\export\\AlembicExportFromMaya:CharacterRig'In addition to special filename characters, there are also reserved filenames on Windows OS. Try to name a file after any of these names and you will find that it is not possible:
To fix this issue, object names will now be stored on the filesystem by ‘slugifying’ the name, which is a technique used in generating URLs for webpages. The Blender object name will be converted using a whitelist of characters and truncated to 48 characters:
Characters not on the whitelist will be replaced with a dash
-. To avoid collisions in edge cases, a 16 hexdigit hash based on the original object name will be appended to the end of the filename. Here are some examples:This bug fix will be included in the next version of the FLIP Fluids addon (> 1.0.7). Until this fix is available, a workaround is to not use special filesystem characters for your FLIP Fluid objects.
More Cache Fixes:
Tracking Technical Support Requests
One of our main focuses during development that we pride ourselves on is providing quality support for our users Monday through Friday! Support is a very important aspect of maintaining the FLIP Fluids project. The types of support requests and volume we receive let us know how our users are using the addon and give us ideas for how to improve the addon.
Starting in January, I have been keeping a log of support request volume to see any patterns. If we’re spending a lot of time handling support for common issues, this could indicate that an area of documentation or learning resources is lacking in information. And this time spent on support takes away time from code development, which is also a very important part of our development.
Here is a daily heatmap covering January 6th to February 10th:
The large volume of support at the start of January can be attributed to catching up after our Winter break. There were a few topics that I found myself repeating during January and spent some time updating the wiki/documentation on some well-needed topics. Later into January and beginning in February, I found myself needing to spend less time on support due to catching up after the break and also being able to link to quality documentation topics that help solve our users’ issues.
More Development Notes
Rendering a large number of particles in our tests required a larger amount of RAM: 14GB in ProRender vs 5GB in Cycles. This did not affect amount of VRAM required and seemed consistent between ProRender and Cycles. There was also a longer render setup time: 105sec in ProRender vs 15sec in Cycles.