Actually, increasing the height of the inflow worked pretty good. It flows smoothly now. Just have another slight issue with particles jumping out of the obstacle, but I’ll email the file for troubleshooting.
@RLGUY
Hi, got any plans for “realtime” FLIP fluids simulations? It would be awesome if FLIP fluids could simulate fluids in realtime.
1 Like
@teddiursa, Nvidia had a real-time flip fluid that ran on DX, it was called cataclysm I think, I wonder if this could be ported to Blender, especially for Eevee?
We don’t have any plans to add any real-time fluid simulation features. If I did have plans for this, I would likely create an entirely new addon based around NVidia fluid technologies. A problem/bottleneck would be loading and displaying the data in realtime within Blender which is quite slow. This would result in quite a bit of lag for interactivity features.
1 Like
Hi all,
hoping someone may be able to shed light on a performance issue.
I’m running Blender and Flip Fluids on a Win10 PC and an OSX MacPro.
The MacPro is baking the exact same scene 3 times faster than the PC.
The Mac is a late 2013 3Gz 8-core Intel Xeon E5, 32gb ram, AMD FirePro D500 3gb
The PC is running Win10Pro and has dual Intel Xeon E5-2640 2.4GHz cpu’s, 64gb ram, and 2 GTX1080’s.
I would have thought the PC would bake much faster than the Mac. Any ideas on why, or am I missing something obvious?
Cheers
Hello Sandrust,
Here are some ideas for why your Mac could be running with higher performance:
- Hard Disk Drive vs Solid State Drive - At the moment, the simulator must stop to write simulation meshes/data to your drive. If your Mac is writing to an SSD while your PC is using an HDD, this could account for difference of simulation times.
- Clock Speed - The higher clock speed of the Mac could account for the difference. Although the simulator is multithreaded, there are some sections of code that must be run on a single thread and this creates a bottle neck. Systems with a high single threaded clock speeds will have performance benefits.
- Simulation Size - To get an accurate benchmark between systems, your simulation should be at a high enough resolution so that a test takes an hour+ to fully run. Low resolution or quick simulation performance will vary wildly across systems and may not be an accurate representation of performance.
More info about FLIP Fluids CPU/GPU performance can be found here: https://github.com/rlguy/Blender-FLIP-Fluids/wiki/Frequently-Asked-Questions#my-cpu-is-running-under-100-usage-while-simulating-is-this-normal
Hope this helps!
The Load Last Frame button in the toolbar on the left doesn’t work with the included .blend file. The green line cursor jumps to the fame but what’s in the 3d View doesn’t show the fluid mesh.
I suspect it’s because I’m using the Hold Frame thing and have it keyframed so it’s off up until frame 900, at which point I move the camera around the frozen/static fluid.
fluid091-d.blend (5.2 MB)
Addendum to the above. It doesn’t work when I jump the cursor to the last frame of the timeline (Shift + Ctrl + Up arrow), in this case frame 1200, and then click the Load Last Frame button. Although now it’s not behaving correctly when I jump to frame 1; it’s keeping (displaying) the fluid mesh from frame 900 but the animated obstacle is moving to where it should be. Am I not doing the keyframing of Hold Frame correctly?
Another addendum; the blend file is slightly screwed up in case you’re trying to understand what I’m doing. It’s supposed to end at frame 900 and then after the simulation finishes I change the end frame to 1200 and then render it with the keyframed camera movement (and Hold Frame at 900).
And yet another addendum. I think the problem is that I forgot to change the timeline’s length to 900 and it was displaying this problem when the simulation was generating frames after frame 900. This file was originally fluid091-c and I copied it to fluid091-d and changed some of the fluid sim parameters, but forgot to change its length to 900 because when it was fluid091-c the last thing I did was do an opengl render from 1 to 1200.
Hey lumpyoatmeal,
Thanks for reporting this and attaching a .blend file. I just had a chance to take a look at this and see what you mean. The issue is that the Hold Frame option was actually not designed to be keyframe animated, so that is why frames are not loading as expected. The interface still allows the user to insert keyframes into this option, so at the moment this is a mistake in the user interface.
I like your use case of animating this option to create a ‘freeze frame’. I didn’t think of this while implementing this option. I have added a feature request to get this option working with keyframes here: #340.
For now, a workaround is to duplicate the surface mesh object at the freeze frame and keyframe the render/viewport visibility for the duplicated object. And also to keyframe the domain render/viewport display mode to ‘None’ when the domain should stop loading meshes.
I might try that. As it is it’s only misbehaving in the 3D View pane. When I render with OpenGL and have the Hold Frame keyframed it works, as long as I make the simulation/animation end at the freeze frame when it’s baking, then after baking I increase the length of the animation and keyframe the camera movement. Therefore I’m keyframing the Hold Frame after it bakes, before I render.
How were you envisioning the Hold Frame being used? I was thinking that another way people might want to use it is what I’d call a “Guy Ritchie” moment where he freezes the action and then has the camera move around the frozen scene, then he resumes the action. (Although I can’t remember if that’s exactly what he does.)
Or, what happens if you keyframe the Speed value in the physics tab for the Domain? I.e., change Speed to 0. Maybe that could be used for my so-called Guy Ritchie effect.
When I was implementing this feature, the only requirement was that the simulator hold a single static mesh over the entire animation. So I had envisioned this feature as being used to just animate a camera around a single frame.
The effect can also be done by keyframing the speed value, but this value will need to be animated before baking. The simulator will also spend time simulating even if the timestep for a frame is 0 seconds. Perhaps I should add a special optimization that will skip simulating the frame when no time passes over a frame.
Yes that would be nice.
Thank you for your reply.
Both machines have SSDs, and the resolution is set to 400.
I checked out the link and will try reducing the number of threads on the PC and see if that helps.
Cheers
Simulation is great, addon is great, code is great, but…
BUT THE FINAL RESULT looks bad, as it usual looks like in all CG-fluid sumulation software.
The only REALLY great Final Result I could see in SMORGANIC script.
Surface Tension is the key.
1 Like
I just realize that the faling carton box is wrong, i mean all should fall equally fast in gravity (the milk shouldnt go faster then the package), it should stay “box shaped” until it hits the ground.
i’m curious why that didnt happen do flipfluid particles react differently to gravity ?
“CG fluids in particular continue to be really difficult to do well. Getting a realistic behavior and appearance for fluids requires dedicated research & development on a long-term basis and when studios only occasionally do fluids or effects work, it’s tough for them to get up to speed to produce high-end effects work within a limited timeframe and budget.”
This is due to a mistake in the simulation setup. There was a frame rate mismatch between the rigid body simulation and the fluid simulation. So the fluid simulation is actually running slightly faster than the rigid body simulation.
What am I doing that causes the initial setup, before it starts generating frames, to use a lot of memory and take so long?
I have an Obstacle object, a bowl, that moves back and forth. Parented to it in order to follow it is an Inflow object. The Inflow object is using a Target, and that’s also parented to the bowl. Whitewater is enabled. Emission rates are both 300. Enable Adaptive Timestepping for Obstacles is on. Frame substeps are the default, 1 and 8. Enable Viscosity is checked, and the value is 0.1. The size of my Domain is 6 meters for x and y, and 3 meters for z.
For the Inflow object Export Animated Target, Add Object Velocity to Inflow, and Export Animated Mesh are all enabled.
It was also just as slow and memory hungry with the Grid Resolution at 80, but I’m now running it at 160. Once it starts generating the frames then it moves along nicely, less than a minute per frame at 160.
fluid093-b.blend (168.6 KB)
I have just bought the addon. I am a hobby artist, and I have allways loved fluid effekts. I am going to try to do this : https://www.youtube.com/watch?v=OHg-CHcflPM&t=1995s with the flip fluid. Tried this in mantaflow with poor result
1 Like