Single Blog

  • Home
  • Weekly Development Notes #20 – Stabilizing Force Fields
FLIP Fluids Development Notes #20

Weekly Development Notes #20 – Stabilizing Force Fields

Covering the week of May 18th – 22nd, 2020.

Hello, this is Ryan here with our 20th weekly development update of the FLIP Fluids addon for Blender! Last week was a four day work week due to a holiday here, but it was still a productive week. I mostly spent my development time on our force field implementation, and that is what I will cover in this post.

Implementing a Signed Distance Field Approximation

A signed distance field (SDF) is a type of data that is very important for our upcoming force field feature set. For our force fields, SDF data is computed and used to generate force fields that align with an object’s geometry. SDFs can be very computationally intensive to compute accurately, so we needed to find a good way to make a quick approximation.

The past few weeks have largely involved researching different SDF approximations methods, testing and analyzing error of different SDF methods, and finally implementing a method into the simulation engine. You can read more about this process in last week’s development notes: Weekly Development Notes #19 – Approximating Signed Distance Fields.

Last week’s development mainly involved implementing and integrating a quick SDF approximation method into the simulation engine. I’m glad to say that this new method seems to be working well and I am very happy with the implementation so far! The older method we had implemented had too many potential issues that would make our force field feature difficult to use:

  • Unstable at high resolutions – Our older SDF approximation introduced too much error, especially at higher resolutions. The amount of error was proportional to the number of grid cells away from the objects surface. This would make the force field directions unstable if the fluid was far away from the object. The newly implemented method is much quicker and has greatly reduced the amount of error.
  • Unstable for complex geometry – Complex geometry, such as sharp corners and thin concave regions introduced a lot of error into the approximated SDF grid. This could cause unstable force field directions close to the objects surface, and visually this would look like the fluid is swirling chaotically against the surface. The new method handles complex geometry very well.
  • Not supported for non-manifold geometry – The older method did not support non-manifold geometry. For a force field to be generated correctly, the object was required to be watertight with an inside and outside to the volume. For some force fields, it should not matter if the geometry is non-manifold. The new method is able to support non-manifold geometry such as curved planes and even curves!

Force Field Tests

Here is a quick test of a ‘morphing’ effect using our surface force field mode. This mode draws fluid towards an object’s surface.

[gfycat data_id="saltyhighleveldoe"]

This effect was created by generating two force fields: one field aligned to the surface of the Stanford Bunny and another field aligned to Blender’s Suzanne Monkey model. The morphing effect was achieved by crossfading the strength of the two force fields.

I also had a chance to spend some time starting work on a curve guided force field mode, one of the most popular requests for our force field feature set:

[gfycat data_id="impressionablehorribleharrier"]

Thankfully, the new SDF approximation implementation supports curve geometry. I was bit worried in the past weeks that I would need to develop a separate SDF approximation specifically for curves and infinitely thin geometry.

Next up:

For the upcoming week, there are a few loose ends to tie up on this new implementation. There are some current usability issues that can arise if the force field object geometry is animated.

It seems simulations can become unstable if the force field object is moving quickly through the domain grid. I’ll need to investigate the cause of this, but my guess is that the force field grid is changing too abruptly and causing unstable particle motion between frames. A possible fix for this is to run more substeps for quick moving force fields. If I’m correct in this assumption, the number of substeps could be computed adaptively, which would be automatic within the simulator so the user would not need to worry about this.

Afterwards, I’ll continue work on implementing a curve guided force field mode and a volume force field mode (similar to Houdini’s Suction Force or Blender’s older Control force).

OTOY OctaneRender compatibility issue

We had a user inform us that there is a compatibility issue with the latest version of FLIP Fluids (v1.0.8) and the latest version of OTOY’s Blender Octane Edition (Blender 2.82a 2020.1 – 21.7) that will cause a render server crash. This issue is caused by a change in the Blender Octane Edition. Specifically, an OctaneRender setting has moved locations and the FLIP Fluids addon did not account for this. This has been fixed and will be included in the next version update.

Workaround

There is a simple workaround if you are using the latest version of Blender Octane Edition:

  • Fluid surface rendering – In the object settings for the fluid surface object, change the Object Type to Reshapable Proxy.
  • Whitewater rendering – In the object settings for the whitewater objects, change the Object Type to Scatter.

In the next version, the addon will set these values automatically.

More Development Notes

  • Fixed broken example scene – A user reported that the Strawberry Splash example scene was not rendering correctly in the latest version of Blender (fluid object would not render). This scene has been re-built and the product downloads have been updated. This type of issue is rare and seems to be caused by incompatibilities between Blender versions that can break/corrupt a .blend file. Unfortunately I have not been able to reproduce this issue consistently so that it can be reported as a bug.
  • Documentation Note: Does my obstacle object need to be completely contained by the domain? – Added a documentation note to clarify a somewhat common issue. Obstacle objects can be larger than the domain, and will be computed correctly if so. But if the object is much larger compared to the domain size, this can lead to performance and memory issues or even out-of-memory errors.
  • Blender Bug Report: Render crash when an object is updated with a frame_change_post handler while another object’s Show in Render property is keyframed (T76422) – This was a weird bug reported to us. Blender could crash during render if an object unrelated to a FLIP Fluids simulation had it’s render visibility keyframed.

    I had reported this to the developers, but the issue was closed as not-a-bug. I might not have communicated the issue clearly and may need to follow up on this. The developer’s response mentions that the script works after removing the depsgraph.update() command, but it was recommended to us that this command is necessary for us to prevent other types of render crashes.