One feature I miss a lot - is motion blur. I know I can do it in Davinci Resolve/Fusion using Optical Flow, but native motion blur would be better. Is there a chance it will be implemented in future?
BTW, can simulation born large bubbles somehow?
2 Likes
At the moment, addons do not have a way to send or attach motion blur data to meshes, so native motion blur is not support. We have some more info in this topic: Motion Blur Support
Realistic and physically accurate large bubbles are not supported in this simulator. This would require a multiple liquid simulation feature (ex: simulating both a water fluid and a low density air fluid). Due to the complexity of this type of simulation, this feature may be outside of the scope of the FLIP Fluids addon project.
I’m currently testing flip fluids for a bridge destruction scene. I’m using an alembic cache for the obstacle but as Flip Fluids doesn’t really see the weight of the bridge, there is hardly any splashing happening when the parts go into the the water. Is there a way to fake this a bit, so you get a much bigger reaction?
Thanks
I’ll add some tips that can help with this type of simulation.
I think these first two points are already set up correctly based on the video, but I’ll add them just in case:
- Make sure that the Alembic obstacle has the ‘Export Animated Mesh’ option enabled so that the complex animation is evaluated correctly. Fracture caches can contain a large amount of geometry and this can take a lot of time to export. Tip: The Skip Re-Export option can be useful in this situation so that you do not need to export the entire animation after each simulation test.
- Make sure that the fractured geometry is composed of closed/watertight/manifold geometry so that it is processed correctly within the simulator.
- Make sure that the fractured geometry contains consistent topology (ex: number of vertices do not change between frames). By default, the addon will warn you about this during mesh export. If the topology does change and you disable this warning in the Advanced Settings panel, the simulation will not be able to calculate fractured velocities and there will not be very much interaction with the liquid.
- Set the physical size of the liquid simulation to match the physical size of the fracture simulation (World Size Documentation). For realistic results, the physical size should match. But if you want to exaggerate the impact of the obstacles, this can be done by setting a larger physical scale for the liquid simulation.
- You will need to set a sufficiently high domain resolution so that the fractured pieces are adequately resolved on the simulation grid. The fractured pieces will need to have at lease 1 voxel coverage on the grid to interact with the liquid, but ideally most pieces should cover a width of at least 5 voxels for best interaction. (Doc: What is the domain simulation grid?).
- Tip: during testing you may want to enable the obstacle debugger to visualize how the fractured object is being voxelized.
- I would suggest reducing the domain size to fit as tightly around the simulation effect in order to maximize performace and detail (Doc: How large should I make my domain object?).
- If there is still little reaction and you do not want to increase resolution further, you may want to increase the number of simulation substeps for better solid-liquid interaction. This will take longer to simulate, so you may want to just keyframe these values higher during parts where the fractured object is quickly impacting the liquid. (Doc: What are substeps, and how do the min, max, and CFL parameters relate to each other?).
Hope this info helps!
1 Like
Thanks for the suggestions Ryan…I think most of these things are covered, but I’ve not tried changing the scene scale yet. My test sim is at 380 which is around 5 million voxels, and everything is at a real world scale, so should be enough for decent interaction. Wondering, if the lo res land proxy needs some extra detail and surface displacement to help offer more resistance to the fluid?
I took a closer look at the animation and it does look like the scales for the liquid and fracture simulations are matching and should be large enough for good interactions.
I don’t think changing the terrain would help. I would expect more splashing and interaction even if the liquid was just contained in a box.
This fracture simulation is from one of our early development tests at 550 resolution, which isn’t that much higher than 380:
https://gfycat.com/apprehensivegenuinecopperhead
I would think that if everything was running correctly that you would expect comparable splashes and interaction in your scene. I am not exactly sure what the problem could be, but if you are able to attach or link to a .blend file (or send to support@flipfluids.com), I’d be glad to check it out.
1 Like
Yeah…thats definitely more what I’m after!..I’ll email you a link to my scene files shortly…thanks for the support!
At last I’ve finished this animation) Thanks for your advices, RLGUY
14 Likes
Hello, @RLGUY
I have a question about the speed of the addon.
What part of the miscalculation is the bottleneck for performance and parallelization?
If we hypothetically run the simulator on a computer with 100 TB of RAM, and set the resolution to 5000, then at which stages of the simulation will the addon start spending the most time?
What’s the bottleneck if I don’t use white water, viscosity, surface tension, mesh generation? Calculation of FLIP particles only.
I have 16 GB of RAM, but I cannot use it 100%. I have to wait too long. I usually use a resolution around 200x200x200. Although the RAM allows you to run 400x400x400.
I’m wondering what takes the most time and can the engine be optimized in the future?
Hello! As resolution increases, the bottleneck is almost always the pressure solver and viscosity solver if viscosity is enabled. The technical details are that the pressure/viscosity solver are solving a linear system of equations using a Conjugate gradient method.
The reason why these are the bottle neck is because much of the solver needs to be run single threaded. These solving sections also require processing a large amount of memory and memory transfer speed between RAM->Cache->CPU can be a hardware bottleneck.
The entire engine can be optimized, including these solvers. And it will be, it just takes development time and resources. There is a lot of room for improvement for optimizations in speed and memory usage.
2 Likes
FLIP Fluids version 1.1.0 is now available!
This maintenance update adds support for the Apple Silicon chip, preliminary compatibility for Blender 3.0 Alpha, many bug fixes, and other improvements.
Release Notes
- Blender 3.0 Compatibility: Blender 3.0 is still in development and is set to release in October 2021. At the moment, there are no known issues when using Blender 3.0 or the Blender 3.0 Cycles-X branch with this version of the FLIP Fluids addon.
- Compatibility may break as Blender 3.0 is developed. Issues related to Blender 3.0 compatibility can be reported and tracked in this thread: issue #535.
- Added support for the Apple Silicon chip.
- Added functionality to the Automatic Command Line Bake operator (Windows Only):
- If a simulation error occurs that stops the simulation, the operator will now attempt to automatically re-launch and resume the simulation. Certain errors such as ‘Out of Memory’ errors can be solved by re-launching a simulation.
- If Blender crashes, the command line bake will try to detect the crash and attempt to re-launch Blender and the baking process.
- The max number of re-launch attempts can be set in the FLIP Fluid Preferences menu.
- Added ‘Remove Mesh Near Domain’ feature support for the preview mesh.
- Added operator to FLIP Fluid Cache panel to set the cache location to a directory based on the name of the .blend file.
- Added +/- operators to the FLIP Fluid Cache panel to increment/decrement a number at the end of a cache directory, similar to the icons when saving a .blend file.
- Added support for all render output image file types when using the Helper > Generate Batch File operator.
- Added support for curves that use the Poly spline type when used as a Curve Guided Force Field.
- Improved support for fracture simulations set as a FLIP Fluid Obstacle where the fracture simulation contains non-manifold geometry.
- Instead of ignoring the entire mesh when non-manifold geometry is detected, the simulator will only ignore fractured pieces of the mesh that contain non-manifold geometry.
- Bug Fix: Simulation will no longer stop if a frame statistics temporary file is found to be in use and unable to be deleted (issue #529).
- Bug Fix: Issue where command line operators may not work if spaces are contained in the Blender executable path, specifically when located in C:/Program Files/.
- Bug Fix: Fixed inconsistent UI issues (issue #533).
- Bug Fix: Issue where non-mesh type objects could be selected as a custom whitewater particle object, leading to an error during render.
- Bug Fix: Re-fixed preview rectangle artifacts issue that was introduced as a side effect by another bug fix (issue #491).
- Bug Fix: Issue where the whitewater display percentage setting loaded an incorrect amount of whitewater after resuming a simulation. Notes:
- This was caused by the addon saving incorrect information to the savestates cache.
- Simulations will need to be re-baked for this fix to take effect.
- Bug Fix: Fixed a FileNotFoundError when using the FLIP Fluids Helper > Generate Batch File if the render output location was set to a relative path.
- Bug Fix: fixed issue where Helper > Generate Batch File operator did not support image file prefixes in the render output location.
- Bug Fix: When baking from the command line and an error is encountered within the simulation, an error message will now be output correctly to the command line window.
- Bug Fix: The cache directory can no longer be set to a location directly relative to the .blend file (ex: ‘//’).
- Bug Fix: Fixed issue where liquid could be spawned with triangle line artifacts for cuboid shaped Fluid objects in high resolution simulations.
- Bug Fix: Crash that could be caused by using undo after activating the Create Domain operator on a selected object.
- Bug Fix: Fixed incorrect render issue when ‘Render > Persistent Data’ option is enabled. Note: with this option enabled, rendering can be less stable. It is recommended to render through the command line if enabling this option.
- Bug Fix: Fixed issue where a curve or empty type object could not be added as a force field object through the helper menu.
- Bug Fix: (Blender 3.0) TypeError which prevents fluid surface object from being generated upon creation of a domain.
- Bug Fix: (Blender 3.0) KeyError generated upon starting a simulation.
- Bug Fix: (Blender 3.0) Immediate crash upon starting a render of a FLIP Fluids addon cache generated in Blender 2.93 or lower.
- Blender Bug: Added a workaround for issue T87629 to return a ‘fake’ preferences with default values if the actual preferences cannot be accessed. This workaround is to support activating the FLIP Fluids addon through the command line.
- Blender Bug: There is an issue that causes render crashes when rendering vertex attributes (T88811). The only known workaround is to render using the command line.
4 Likes
Hey there! I noticed in the weekly changes thread over on DevTalk that Brecht submitted a patch for exporting motion blur velocities via attributes: https://developer.blender.org/D12305
Will this have any future implications in terms of more robustly supporting motion blur within the addon? 
2 Likes
Hey! I was quite excited when I saw this. I haven’t had a chance to test this yet, but will be able tomorrow.
The one worry I have is that the patch only mentions ‘Export’ of the velocity attribute. And that makes me think it only affects how velocity data is accessed/exported to Cycles and other renderers. What we need is a way to import velocity data from Python into the velocity attribute.
A few months ago I was trying to access the velocity attribute to add our velocity data but found out it seemed to be read-only and would not work. To work around this, we just renamed our velocity attribute to flip_velocity. Really hope that we’re now able to now store that data into the standard velocity attribute. If so, motion blur support could be as simple as just renaming the attribute in code.
3 Likes
Just tested this, and it looks like we’re not able to modify the velocity attribute with our own data, so I guess it may still be read-only. Maybe things will change in the future or there will be a workaround.
1 Like
I did some more experimenting, and it looks like motion blur on the fluid surface will work - and without any modifications to the FLIP Fluids addon!
Although we cannot modify the velocity attribute directly, we can transfer and scale the existing flip_velocity attribute and transfer this to the velocity attribute using a node setup:
Enabling motion blur in Cycles as well as on the fluid_surface object properties, it appears this does render with correct motion blur vectors.
This will not work for whitewater particles at the moment. I am not sure if there is a feature in geometry nodes to transfer attributes to instances yet, but there could be. I’ll look into it. If anyone knows, let me know as it has been some time since I have kept up with the geometry nodes development.
Note: the velocity attribute feature is hidden in the latest FLIP Fluids 1.1.0 due to a bug (T88811) preventing this from being considered as a stable feature. This feature can be unhidden from the FLIP Fluid Surface panel by enabling the Developer Tools option in the addon preferences menu.
Here is a basic .blend file setup:
geometry_node_motion_blur_setup.blend (1.3 MB)
14 Likes
Great news that it was easy enough to implement without requiring any modifications to the addon! And impressed with how effortlessly geo-nodes could edit and rewrite the attribute to achieve the correct result. Curious if there’s a reason that you scaled the flip_velocity attribute by 3 when transferring, or if that just dialed in how much blur is applied to the motion? It’s a shame about the API bug reducing stability, hopefully that can be fixed by the devs soon!
And with regards to transferring attributes to instances, if Jacques’ DevTalk post from 16th is something to go by, it’s unfortunately still not possible yet; but something the devs are aware of and intending to support in the future:
Another thing we don’t support yet but should eventually are attributes on instances. Again it would probably be easier for artists to instance first, and then add attributes to the instances. Those attributes could then be used either by later processing steps or the renderers. Often it is conceptually important whether an attribute is on the instance or on e.g. every vertex. Shaders are build with that in mind.
2 Likes
Thanks for the info on instancing, that is very helpful to know!
The scale value was just used to make the velocities larger to exaggerate the motion blur effect. A value of 1.0 would be the accurate amount to use for rendering.
Hi,
Is it possible to bake Whitewater after baking the whole simulation ?
My goal is to save Whitewater’s computing time and bake it if I am satisfied with the simulation.
Also, is there a big impact on the computation time and on the shape of the simulation if we change the scale of the world? In my scene I want something very “Splashy”, precision is not very important.
Actual domain : 40x20x20m
I do not think you can bake WhiteWater after the initial simulation.
if I recal correctly world size certainly has an impact on how the water will behave, just like I think resolution itself does.
1 Like
Just adding an update on the fluid surface motion blur. The previous motion blur rendering setup is no longer recommended and contains a legacy geometry node. Legacy nodes will eventually be removed before Blender 4.0 and they also cannot be added as nodes in more recent versions of Blender 3.0.
I have updated the setup to use the newer Geometry Nodes ‘Attributes and Fields’ workflow. The example file can be found in the Experimental Builds package and requires an installation of the most recent FLIP Fluids experimental version (current: v9.1.3, 03-NOV-2021).
The example file can also be downloaded here: motion_blur_rendering_example.blend (1.2 MB)
Notes from the example file:
This example .blend file demonstrates a quick set up for how to render
the FLIP Fluids addon liquid surface with motion blur. This example file
is intended to be used with builds of Blender 3.0 on the date of or later
than October 31st 2021.
Blender 3.0 adds a feature that allows for the FLIP Fluids surface to be
rendered with realistic motion blur, something that was previously not
possible. Whitewater motion blur rendering is not yet possible, but will
hopefully be added by the Blender developers at a later date.
This set up uses a simple Geometry Node network to transfer the FLIP Fluids
addon velocity data attribute into Blender's own velocity attribute, which
can then be used by the Cycles renderer for motion blur rendering.
How to use this example file:
- Bake the fluid simulation
- Render an image or an animation
- Note: motion blur rendering is not displayed in viewport render
- The node network and data values can be viewed by selecting the
fluid_surface object. The GeometryNode modifier can be view in the
fluid_surface modifiers tab.
How the node set up works:
- The FLIP Fluids addon stores its own custom surface velocity vectory data
into the attribute named 'flip_velocity'.
- A vector math node scales this vector and stores the result into Blender's
internal velocity attribute which is named 'velocity'.
- The amount of motion blur can be optionally scaled by adjusting the 'Blur Scale'
value in the fluid_surface modifiers tab.
- The geometry node attribute data values can be viewed in the spreadsheet window
when the fluid_surface object is selected.
Additional notes:
- These notes may be helpful for if you want to set up motion blur rendering on a
new scene.
- By default, the option to generate the 'flip_velocity' attribute is hidden. This
option can be unhidden by enabling the 'Developer Tools' option in the FLIP Fluids
preferences menu. Afterwards, the option to generate velocity attributes can be
enabled the FLIP Fluid Surface panel.
- Generating velocity attributes is still considered an experimental feature due to
a bug in Blender that can cause render crashes
(https://developer.blender.org/T88811). Until this bug is fixed, a workaround is
to render from the command line.
- Motion blur rendering is only supported in Cycles. Motion blur rendering must be
enabled in the Render Properties menu as well as on the fluid_surface Object
properties menu.
- The 'flip_velocity' attribute is added as a Group Input node in the node network.
The input attribute name (flip_velocity) is specified in the GeometryNode modifier.
- Blender's 'velocity' attribute is added as a Group Output in the node network.
The output attribute name (velocity) is specified in the GeometryNode modifier.
Here’s an example animation using motion blur, created for Halloween!
9 Likes