I’m back with our 33rd development update for the FLIP Fluids liquid simulation addon for Blender! There was no update last week as I had to take some time off to recover from an illness. I’m fully recovered now and am feeling great!
Lately I have noticed some areas in the simulator where I could make some simple modifications to improve performance, and after some testing, these changes turned out to have a larger impact on speed than I had thought! And that is what I’ll cover in this post.
Simple Performance Optimizations
I noticed there were some areas in the simulator, that with a few small modifications, could benefit performance. These changes mainly involved how memory is accessed and how memory is copied and moved around in the simulator. After a week of simulation compute time testing different simulation features, it looks like these simple changes provide a 10% – 15% boost in performance for medium to large simulations.
Removing Memory Safety Checks
One of that changes was to remove some of our ‘memory safety checks’ from the simulation engine. When our simulator accesses memory on the grid, we had put some checks in place to make sure the memory region being accessed was correct and valid. If an area of memory being accessed was not valid, an ‘Index Out of Range’ error was generated, which users could report to us.
These memory checks were very useful to us during the FLIP Fluids Beta over two years ago as it let us easily debug issues related to out-of-bounds memory errors. But now that our simulation engine has matured, these memory error bugs are much more rare. I can only recall one report over the last 9 months of this type of error, and this was caused by a bug that has been hiding in the simulator for over 3 years.
Toggling Memory Safety Checks On/Off
These memory checking features are still useful to us. Bugs like this can still happen and we mostly catch them during our internal testing and development. Since memory checks are still useful to us, we will now be distributing two versions of the simulation engine with the addon: a fast release version without memory checks, and a slightly slower debug version of the engine that can report memory errors. The debug or release version engine can be toggled in the addon preferences.
Although the changes were simple, this now complicates building the addon for distribution a bit. We now need to distribute and test 6 versions of the simulation engine with the addon. Two engines for each supported OS: Windows, MacOS, and Linux. To work around these complications, I spent some time last week creating some scripts to automate the process of building and testing the addon for each OS. This helps remove any human error during building and testing.
Performance Results
Here’s the results of a test between the debug version of the engine (formerly the engine used in versions older than 9.0.9.05) and the new release engine with memory checks removed and a few other optimizations.
This test was a relatively heavy simulation that stresses the simulator: 350x350x350 resolution, mesh subdivisions set at 1, a high poly dynamic obstacle, and a peak number of 56 million fluid particles.
[gfycat data_id="dopeyincredibleairedaleterrier"]
Overall, the release version of the engine runs about 12.7% faster in this simulation! Saving almost 1.5 hours on this bake is a nice boost!
Sidenote: rendering the above simulation pushed my system to it’s limit! The largest frame contained a fluid surface mesh with 21M vertices and 42M triangles, requiring a mesh files size of 722 MB. I had to close all applications and render on the CPU from the command line in order not to run out of my 32GB of RAM during the Cycles BVH building stage of the render.
Here’s a breakdown of the timing result by calculation category (times are in HH:MM:SS):
Timing Category
Version 9.0.9.04
Version 9.0.9.05
Speedup %
Mesh Generation
02:10:50
2:03:55
+5.3%
Velocity Advection
01:36:43
1:32:19
+4.5%
Fluid Particles
03:32:32
2:50:54
+19.6%
Pressure Solver
02:38:23
2:22:53
+9.8%
Simulation Objects
01:06:10
00:53:02
+19.8%
Other
00:14:20
00:09:35
+33.1%
Total
11:19:00
09:52:40
+12.7%
Force Field Experimental Version 9.0.9.05
Want to try out the latest optimizations? These performance improvements have been added to our Force Field Experimental Builds Package in the latest version!
Release Notes v9.0.9.05
Release notes for other versions can be found here.
Added optimizations that can speed up simulation baking for medium to large simulations by 10% – 15%
Addon now includes two versions of the fluid simulation engine that can be switched in the addon preferences menu. Notes:
Engine Debug Mode enabled: uses a debugging version of the simulation that can generate error messages after a simulation crash, but runs slightly slower
This is the version of the simulation engine used in versions older than v9.0.9.05
Engine Debug Mode disabled: includes performance optimizations, but is unable to generate error messages after a simulation crash
If you are experiencing a persistent simulation crash, switch to the debugging engine and resume/re-run simulation to check for error messages
Running the debug engine or normal engine will not affect the results of the simulation
Addon can now be built/compiled using a Python script (build.py) rather than running CMake and GNU Make directly. The new Python script automates building both versions of the fluid simulation engine.
Addon packaging and distribution for Windows/MacOS/Linux is now automated to reduce issues related to human-error
Fixed potential crash that can be triggered when using Surface, Volume, or Curve Guided force fields
Default value change: FLIP Fluid Simulation -> Update Settings on Resume is now enabled by default
Default value change: FLIP Fluid Surface -> Subdivisions is now set to 1 by default
Note: this produces a more desirable mesh with less artifacts and issues, but takes some extra time to compute. If you want to maximize baking speed during testing, set this value to 0
Weekly Development Notes #33 – Simple Performance Optimizations
Covering the week of September 21st – 25th, 2020.
I’m back with our 33rd development update for the FLIP Fluids liquid simulation addon for Blender! There was no update last week as I had to take some time off to recover from an illness. I’m fully recovered now and am feeling great!
Lately I have noticed some areas in the simulator where I could make some simple modifications to improve performance, and after some testing, these changes turned out to have a larger impact on speed than I had thought! And that is what I’ll cover in this post.
Simple Performance Optimizations
I noticed there were some areas in the simulator, that with a few small modifications, could benefit performance. These changes mainly involved how memory is accessed and how memory is copied and moved around in the simulator. After a week of simulation compute time testing different simulation features, it looks like these simple changes provide a 10% – 15% boost in performance for medium to large simulations.
Removing Memory Safety Checks
One of that changes was to remove some of our ‘memory safety checks’ from the simulation engine. When our simulator accesses memory on the grid, we had put some checks in place to make sure the memory region being accessed was correct and valid. If an area of memory being accessed was not valid, an ‘Index Out of Range’ error was generated, which users could report to us.
These memory checks were very useful to us during the FLIP Fluids Beta over two years ago as it let us easily debug issues related to out-of-bounds memory errors. But now that our simulation engine has matured, these memory error bugs are much more rare. I can only recall one report over the last 9 months of this type of error, and this was caused by a bug that has been hiding in the simulator for over 3 years.
Toggling Memory Safety Checks On/Off
These memory checking features are still useful to us. Bugs like this can still happen and we mostly catch them during our internal testing and development. Since memory checks are still useful to us, we will now be distributing two versions of the simulation engine with the addon: a fast release version without memory checks, and a slightly slower debug version of the engine that can report memory errors. The debug or release version engine can be toggled in the addon preferences.
Although the changes were simple, this now complicates building the addon for distribution a bit. We now need to distribute and test 6 versions of the simulation engine with the addon. Two engines for each supported OS: Windows, MacOS, and Linux. To work around these complications, I spent some time last week creating some scripts to automate the process of building and testing the addon for each OS. This helps remove any human error during building and testing.
Performance Results
Here’s the results of a test between the debug version of the engine (formerly the engine used in versions older than 9.0.9.05) and the new release engine with memory checks removed and a few other optimizations.
This test was a relatively heavy simulation that stresses the simulator: 350x350x350 resolution, mesh subdivisions set at 1, a high poly dynamic obstacle, and a peak number of 56 million fluid particles.
[gfycat data_id="dopeyincredibleairedaleterrier"]Overall, the release version of the engine runs about 12.7% faster in this simulation! Saving almost 1.5 hours on this bake is a nice boost!
Sidenote: rendering the above simulation pushed my system to it’s limit! The largest frame contained a fluid surface mesh with 21M vertices and 42M triangles, requiring a mesh files size of 722 MB. I had to close all applications and render on the CPU from the command line in order not to run out of my 32GB of RAM during the Cycles BVH building stage of the render.
Here’s a breakdown of the timing result by calculation category (times are in HH:MM:SS):
Force Field Experimental Version 9.0.9.05
Want to try out the latest optimizations? These performance improvements have been added to our Force Field Experimental Builds Package in the latest version!
Release Notes v9.0.9.05
Release notes for other versions can be found here.