Covering the week of April 20th – 24th, 2020.
Hey everyone, this is Ryan with our 18th weekly development update for the FLIP Fluids addon for Blender! I usually update these on Monday, but I am posting this one on Friday because today is a very special day for us. Exactly two years ago, our FLIP Fluids addon launched on the Blender Market!
In this post I’ll be covering last week’s Blender Market sale, Dennis’ latest compositing tests, and the latest development on our upcoming force fields feature! And just letting you know that I’ll be skipping next week’s development update post (covering April 27th – May 1st). It will not be interesting and will mostly involve tax preparation and annual business procedures.
Thank you for an amazing 2 years!
Today on May 1st, marks two years since we released the FLIP Fluids addon on the Blender Market. Before launch, we had never expected our FLIP Fluids simulator to be so well received and loved by the Blender Community. The amount of support from all of you over these years have been incredible and keeps exceeding our expectations. Thanks to the generosity of the Blender Community, we have been able to continue growing and developing the addon for the past 24 months, and it does not look like we will be stopping any time soon!
The FLIP Fluids project has been a life changing experience for the both of us. To be able to work on what we are passionate about has been our dream, and we have truly appreciated all of your support and kind words.
To the Blender Community, the Blender Foundation, CG Cookie & the Blender Market, our families, friends, and many more: thank you for making this all possible.
– Ryan and Dennis, the FLIP Fluids Team
Post Blender Market Spring Sale
Last week was the huge Blender Market 2020 Spring Sale, and it was another successful sale for our FLIP Fluids addon! Although we receive a reduced commission on each sale, being a part of these events is very well worth it for the additional sales volume and traffic. These sales contribute a large amount to our development fund and help us keep running throughout the year.
Due to the increased traffic and new users, sales are usually the busiest times of the year in terms of questions and customer support. Usually the sale’s week and following 1 to 2 week’s of development time are almost all spent on customer support. However, for the first time since release, this sale was the first where time spent on customer support has not been higher than an average development week. I would say that this can be attributed to some recent improvements we have made in the FLIP Fluids project that make it easier for new users to avoid problems and find information:
- Improved documentation – In January, many common topics were added to our documentation and wiki. This greatly reduced the amount of time spent on support requests due to making it easier to find information. And for common questions received in support requests, it takes little time to point to relevant documentation topics that were missing before.
- Improved product page – Recently, we have updated our Blender Market product page to better highlight our workflow features and reasons why to choose our addon over the built-in Blender liquid simulators. During previous sales, many questions were related to these topics and having a better product page has reduced the amount of questions.
- Improved addon usability – In the latest version of the addon, there was a large focus on fixing usability issues. We fixed some of the most common issues that were confusing or frustrating to new users. This has greatly reduced the amount of troubleshooting and support requests received in the following week after a sale.
- New tutorials for Blender 2.8 – The FLIP Fluids addon was released before Blender 2.8 and our beginner tutorials were using Blender 2.79. Blender 2.8 made huge changes to the Blender UI and our old beginner tutorials were confusing to those using the current version of Blender. New users have mentioned that our new tutorial series, which focuses on all of the FLIP Fluids settings and how to use them, are very useful to beginners of the addon and to beginners of fluid simulation. This has also reduced the amount of support requests in the week following a sale.
Thanks to these improvements, this has greatly helped reduce the amount of support requests, and this means we can spend more time on development of exciting new features and improvements! Being able to run a sale and simultaneously keep developing the code base has been a huge plus for productivity during this sale.
Dennis has been creating some awesome compositing tests in the last few weeks. In this first test, Suzanne the Blender monkey and a bathtub simulation was composited into real footage with the help of the SynthEyes tracking software.
Now check out Dennis’ second test: A smaller FLIP Fluids simulation composited into a large lake (Rursee, Germany). The fluid simulation only took 2h30m to run, amazing! 3D tracking using SynthEyes, Davinci Resolve for compositing and grading, and footage shot with a Mavic Zoom drone. Check out the animation and breakdown here:
Signed Distance Fields
The last few weeks of development have largely involved reading and testing different methods for generating signed distance fields.
- What is a signed distance field (SDF)? A SDF is a very important type of data in our FLIP Fluids simulator for representing volumes. All of our fluid, inflow, outflow, obstacle objects, as well as the fluid surface are represented by SDF data. A SDF is a function that takes a 3D point (such as a point in the fluid Domain), and outputs the distance to the closest point on the volume’s surface. Many SDFs use the convention that a negative distance denotes points inside of the volume while positive distances denote points outside of the volume.
- Why are signed distance fields useful? In our fluid simulator, they are very useful and efficient for collision handling and detection in the physics calculations. Many of the grid calculations are based on SDFs. A very useful property of a SDF is that, from just the distance values, you can easily derive the nearest point on the surface of a volume (Math Gradient operation).
Signed Distance Fields and our force fields feature
For our upcoming force field feature, we need to add some very expensive computations to extend how our SDF calculations work. These calculations are crucial to a few of our highly requested force field features: surface forces that draw fluid towards the normal of a surface, volume forces and suction forces that draw fluid into a volume, and curve guided forces that allow fluid to flow along a curve.
For regular fluid calculations, SDF generation is much simpler because we do not need to calculate the field for the entire domain grid. We only need to compute a narrow band of SDF values that are within a few grid cells of the fluid or object’s volume, and this is relatively quick and efficient to compute accurately.
But for these force field features, we will need to compute an SDF over the entire domain volume, or at least in a thick band around the object volume. If we were to compute the SDF for the entire grid with 100% accuracy, this would take wayyy too long to compute. For this reason, we will need to approximate the SDF field using quick methods in a way that it is accurate enough for our use case.
Approximate SDF vs Accurate SDF
In the past few weeks I have been reading up on and researching different methods for approximating SDFs. The 3D Distance Fields: A Survey of Techniques and Applications paper contained some very helpful information and resources for this type of computation.
For next week’s development I will be testing out a few techniques for approximating SDFs to see what is suitable for our force fields feature. In order to test and implement methods efficiently, I spent some time last week generating 100% accurate SDF data for two objects: modified versions of the Suzanne Monkey (3508 triangles) and the Stanford Bunny (6966 triangles). Accurate data for comparison is needed to make sure I am implementing the methods correctly, and to test how far the approximations deviate from the accurate results.
Here are some timing results at different grid resolutions in cubic domains. Take a look at just how unreasonable it would be to compute 100% accurate data in our simulator!
|Resolution||Voxels||Suzanne Calculation (s)||Bunny Calculation (s)|
Image having to wait 58 minutes for a single frame to compute! We’ll definitely need efficient approximations to reduce this time down to seconds for more reasonable simulation times.
In next week’s development, assuming I finish testing the required methods, I’ll post the results and conclusions of my tests for the next update on May 11th (Edit: the next update has been delayed to May 19th due to the need to recover from a minor wrist injury)!
Have a great weekend!