Great, thanks.
I’m struggling to find a setup that lets me add flowing fluid to a specific level so I can add static and moving obstacles to see how things react. How do I get the right inflow to add fluid to its complete height flowing right to left? Constrain inflow velocity didn’t help as I thought it would. No matter how I set it up the fluid is always significantly lower than the top of the inflow and at a different height depending on the resolution. Is there no way to precisely control this before baking?
Hi, this is how I usually set up these types of simulations:
An inflow on each end to enforce the flow velocity as well as an outflow on each end. The outflow on the origin side acts as an airgap between the domain wall which is necessary for a consistent flow rate.
Here is a basic .blend file in case it helps:
constant_liquid_flow.blend (1.3 MB)
Tip: Depending on the simulation and objects that the liquid is reacting with, there may be some energy loss that causes the liquid to slow down, which tends to result in a lower liquid level on the outflow end. If this is not desired in the visualization, using the custom meshing volume feature to hide parts of the fluid simulation can be useful.
Hope this info helps!
2 Likes
That’s great, thank for the help and explanation. That is a very cool setup.
What causes this phenomenon? I’ve run into it in other setups, where what I think should be a smooth flow even after many frames will set up a kind of standing displacement pattern with whitewater that makes it useless for any kind of surface obstacle animation. The higher the baking resolution the worse the pattern gets. This is your setup even after 315 frames at resolution 300 without the obstacle active so you can see the pattern.
I would be interested in knowing too,
Few months ago , i was trying to use this kind of set up for setting my ship sim, i did run on similar problem as you . i’ve tried many things but i couldn’t remove the initial ‘’ bump ‘’ at the water level made by the inflow ( worst in the first few frames of the sim). The white water that was emiting from this bump was messing up the sim.
Only thing that helped for me was setting the inflow substep to a higher level. that removed alot of artifact on the flip surface , but not enought to remove the whitewater from them.
i did resolve to use a moving obstacle instead, with a meshing volume that follow the area of interest. It work great and the Baking time is pretty good on the case i work on.
These types of artifacts are related to low physics accuracy, specifically how frequently simulation substeps are computed.
Related topic: What are substeps, and how do the min, max, and CFL parameters relate to each other?
With the default settings in this set up, the minimum number of simulation substeps that will be computed matches the animation framerate, so 24 substeps per second. This may not be enough substeps for all situations.
When the number of substeps are lower, this can lead to inaccuracies in the physics computations that can cause different side effects. In this case, the side effect of low substeps causes those undesirable ripples.
The frequency of substeps to compute can be adjusted in the Domain > Advanced > Frame Substeps menu:
One way to increase the accuracy is to increase the number of Min Substeps in this menu. For example, a value of 5 will cause the simulator to run at least 5 substeps per frame, which will be 120 substeps per second in this setup.
Here is an example using 5 Min Substeps. Halfway through the animation, this value is keyframed to 1 Min Substeps for comparison:
In this situation, increasing the minimum substeps results in a smoother flowing liquid at higher resolutions.
Hope this info helps!
3 Likes
Thanks again for the thorough explanation.
Thanks you, i’ll try this soon ! 
That works a treat, however… 
I’m removing the boundary mesh and killing all whitewater at the boundary, so what’s generating this mesh and whitewater interaction along the boundary? Is there a way to predict this or is it just better practice to set up a meshing object slightly smaller than the domain before baking?
Hello ELinder,
Quote from Flip Fluid Github Wiki (Tips-for-Creating-Ship-Simulations) ;
‘’ * You may want to disable the Enable Emission Near Domain Boundary option in the Whitewater Advanced Settings. This will prevent whitewater from being generated near the edges of the domain.’’
Nice scene by the way!
2 Likes
This can be a good solution to the issue.
As mentioned above, disabling the Enable Emission Near Domain Boundary can help. One thing to note is this won’t prevent whitewater particles that are created away from the domain boundary and then flow closer to the edge.
The Kill option at the domain boundary will remove particles that collide with the edge, but depending on the flow the particles may flow near the edge, but not collide with it.
Ah, thanks, I overlooked that emission near boundary option. I don’t mind particles flowing to the edge, I just don’t want any created along the edge or stuck there forming a line before they lifespan die.
Is anyone using cryptomattes with Flip Fluids? I’ve gotten Blender to write the fluid surface matte into multilayer exr and open it in Fusion Studio with the Reactor Cryptomatte node, but ideally I’d like to have mattes for each of the whitewater elements either as separate material IDs or as separate object IDs.
edit: Actually, never mind. As long as you enable both Object ID and Material ID they are all there in the cryptomatte. They’re just quite hard to get the cursor on the just the right spot to select them.
FLIP Fluids Experimental 9.4.2
A new experimental version is now available in the Experimental Builds Package.
Release Notes
-
version 9.4.2 (Jul 07 2022)
- This experimental release adds bug fixes and mainly improves support for attributes and command line tools.
- Added: Expanded support for fluid surface attributes.
- Option to generate accurate velocity-based surface attributes against obstacles. Notes:
- Velocity-based attributes are the velocity, speed, and vorticity attributes of the fluid surface.
- If this option is enabled, correct velocity-based attributes will be generated at the interface where the liquid and obstacles meet, but at the cost of simulation performance.
- If disabled, velocity-based attributes where liquid and obstacles meet may be incorrect and may contain motion blur spikes or shading artifacts.
- This option only needs to be enabled if rendering with velocity-based shaders and/or motion blur where the liquid-obstacle interface is visible, such as when there are transparent/invisible obstacles.
- Attributes are now supported when using the Upscale Domain Resolution on Resume feature. Previously, attributes would be initialized to a default values on resume when using this feature.
- Attributes are now supported when using the Sheeting Effects feature. Previously, newly created fluid particle attributes would be initialized to a default value.
- Attributes are now supported when the FLIP Fluid Surface > Particle Scale is greater or less than the default value of 1.0. Previously, using larger or smaller values could result in shading artifacts or missing attribute data.
- Exceptions: The Source ID attribute will not be supported in the above changes. This attribute is deprecated and is being replaced by a similar attribute that expands functionality and improves use cases.
- Option to generate accurate velocity-based surface attributes against obstacles. Notes:
- Added: Expanded command line operator support to MacOS and Linux (previously Windows-only features). Notes:
- Operators that automatically launch a new command line window processes are now supported on MacOS and Linux.
- These operators include the Bake Simulation, Render Animation, and Render Frame features.
- These operators can be found in the FLIP Fluids Sidebar > Command Line Tools menu.
- Linux notes:
- These features rely on and assume that the xterm terminal emulator is available on the PATH in your Linux distribution.
- If the option to open image file after rendering a frame is enabled, the xdg-open program will be used to open the file.
- Added: Shortcut operator to the Blender > Help > FLIP Fluids submenu that opens the FLIP Fluids addon preferences.
- Added: Functionality to preserve Color Attribute mesh data groups between frames in Blender 3.2. Note: the Color Attribute group functions similarly to the deprecated Vertex Color group in Blender 3.1 and earlier.
- Bug Fix: Fixed error that could be triggered if a simulation mesh contained a Vertex Color group in a .blend file created in Blender 3.1 or earlier that was opened in Blender 3.2 or later.
- Bug Fix: Fixed UI issue where cache info stats could display a vorticity attribute entry when the vorticity attribute was not enabled.
- Bug Fix: Fixed error that could be triggered if a surface/whitewater mesh object was in edit mode while starting/resetting a bake.
- Bug Fix: Fixed issue where resuming from an earlier savestate and ending the simulation before the frame completes may not update the most recent savestate to the correct frame.
- Bug Fix: Fixed misc errors that could be triggered in the OTOY Octane Render for Blender 3.1 version when the renderer was set to Octane.
- Change: Reduced log filename length to a max character length to prevent filepaths from becoming to long in order to reduce Windows OS path length related issues.
- Improvement: improved accuracy and performance of color attribute to mesh transfer.
- UI: Initialize Motion Blur operator in the sidebar now cannot be used without first enabling the Preferences > Developer Tools option. This sidebar menu will now prompt the user to enable the developer tools option. This change will only affect future stable versions as the developer tools option is not relevant in experimental versions.
- UI: removed redundant Render Tools menu from sidebar.
Summer Holiday Notice
Just letting you know that I’ll be away on holidays beginning July 8th 2022. Regular development will resume on July 26th 2022. During this time responses to support requests here and through the marketplace messaging systems may be delayed longer than usual. Thank you for your patience!
6 Likes
Are there any online render farms that support just baking the Flip Fluids simulation? I’m not looking for them to do the rendering, just the cache baking. I’ll render it myself.
Hey @RLGUY.
I have a question.
Is it possible to add calculation of individual simulation stages using neural networks to the addon?
To make the simulation take less time.
To be easily parallelized on the CPU.
I would like the simulator to be much faster, but give about the same results as it does now.
For neural networks to guess the values of fluid pressure, so that the Pressure Solver stage takes a short time and is not a “bottleneck”.
And make a calculation of neural networks for all difficult stages, for example, for the viscosity solver.
I would like to be able to create simulations at 750x750x750 resolution in a reasonable amount of time (several hours).
To get these results:
https://blenderartists.org/uploads/default/original/4X/a/5/9/a590fc561ba99914ff794a5f57839755db9209fd.jpeg
There are not any as far as I know. The Polargrid farm used to offer this as a service but there was not enough demand to keep it running.
I have heard of other artists using general cloud computing services to run simulations and other Blender tasks. For example the Amazon Compute Services, but I’ve heard this can be a bit technical to set up correctly and there is a learning curve if you’re unfamiliar with these types of computing services.
I have heard from a few artists that they found the free set up using Google Cloud Computing worked, but the performance was quite slow.
The easiest to set up may be to rent a cloud desktop.
1 Like
Hi! Sounds like an interesting idea, but is not something I am sure I can answer accurately. This is an area (AI, machine learning) that is outside of my area of knowledge at the moment.
It could be something to take into account in future development, but would likely be quite far into the future. Our most limited resource is time and our backlog of current tasks is measured in years.