Okay, got another problem just trying to see how it runs on my macbook, and I get the following error when I enable the addon:
Traceback (most recent call last):
File “/Applications/Blender/blender.app/Contents/Resources/2.79/scripts/modules/addon_utils.py”, line 350, in enable
File “/Users/Marge/Library/Application Support/Blender/2.79/scripts/addons/flip_fluids_demo/init.py”, line 114, in register
File “/Users/Marge/Library/Application Support/Blender/2.79/scripts/addons/flip_fluids_demo/ui/init.py”, line 77, in register
AttributeError: ‘RNA_Types’ object has no attribute ‘PHYSICS_PT_add’
This error has been seen before in this issue. The problem was that there was another addon installed that was deleting/overwriting Blender’s PHYSICS_PT_add attribute. This attribute is used by the FLIP Fluids addon to add buttons to the physics menu and is needed for the addon to function.
I would suggest trying to disable other installed addons and restarting Blender to see if the FLIP Fluids addon loads correctly.
Thanks for letting me know what addon is causing this issue! I just took a quick look at the blend4web addon code and it looks like they are unregistering the PHYSICS_PT_add attribute from Blender. I’ll check this out further and see if there is anything we can do to accomodate for this or if we can report this to the blend4web developers.
I know how a lot of people may not have experience with coding or building from source code, so I have built the source code of FLIP fluids and packed the add-ons available for download on my GitHub hub page below. The open source part of the add-on does not include all the paid content such as materials and presets, so you if want those I suggest you check out their page over on Blender Market.
You can also find the source code plus the edits I made to get the build working on my machine in case you need to build it for yourself. Download on GitHub
The inflow objects work by filling the mesh with fluid particles at the start of a frame (or substep if multiple substeps per frame) and then the fluid simulation takes over and begins moving the particles.
To fill in the gaps, I would suggest:
Creating a longer inflow object that fills more space per frame.
If your inflow object is keyframed/animated and moving quickly, then increasing the number of substep emissions in the inflow settings can help fill in gaps and eliminate stuttering by interpolating between mesh multiple times per frame.
I started a new simulation/bake and it’s significantly slower than previous ones. I’d forgotten that I’d just installed an update from Microsoft that’s only the Intel microcode update. Then I saw remarks on reddit about how the new microcode slows things down.
I was planning on upgrading to a Threadripper cpu this winter. RLGUY, would upgrading to the whopper 64 thread one help flip fluids? I.e., can it use all 64 threads?
I would not recommend a threadripper for FLIP simulations. The FLIP method isn’t highly parallelizable and will run best on a CPU with high single threaded clock speed and capable of running 8 - 16 threads for the parallelizable parts.
How large is the slowdown? I have not heard of this update yet.
Ok, thanks. So I’m less likely to break the bank on the 2990WX but I’ll probably still get the 2950X (16 cores, 32 threads), and hope for the best. And the Threadrippers have some automagic overclocking that sounds nice.
In later versions after Decoupled Baking is implemented, there is a potential of great benefits for users with many cores/thread and large amounts of memory. Decoupled baking allows to separate fluid simulation, mesh generation, and whitewater generation. Fluid simulation could run slow on this hardware, but there could be performance gains in meshing as multiple frames could be meshed at once. For example, with 32 threads and 4 threads working on each frame, you could mesh 8 frames simultaneously. Parts of the whitewater calculations could also be computed running multiple frames concurrently.
Major Bug Fixes | Please update to version 1.0.4a
Three major bugs have been identified in the new version 1.0.4 particle mesher. These issues have been fixed and are available in a patched version 1.0.4a available on the Blender Market.
For version 1.0.4 the entire particle mesher was rewritten, so there was bound to be a few bugs laying around but we never expected these huge ones to slip past us before releasing v1.0.4, and for that we apologize for these problems that you may have encountered! In this post, we will detail the bugs and what caused them!
Bug Fix: Banding artifacts in surface mesh
This bug caused banding ‘ridge’ artifacts that were quite prominent when the mesh subdivision level was set to 0. This was caused by a programming ‘off-by-one’ error that led to a pattern of mesh calculations to be skipped. These skipped calculations resulted in missing mesh data which is what causes the banding ridges. Once fixed, the missing calculations end up filling out the ridges resulting in a smooth mesh.
This bug could cause triangles to be missing in the surface mesh. This is more likely to occur when the triangles are very small such as in high subdivision meshes and small world sizes. The bug was caused by numerical precision errors due to tiny math in the CPU.
The mesher computes the surface mesh in chunks and then ‘welds’ the pieces together by joining vertices and edges. The numerical errors caused vertices not to line up properly which resulted in holes within the mesh. This issue was fixed by having the simulator internally scale the mesh pieces before welding so that they would be an appropriate size for the CPU to handle the calculations accurately.
Big thanks to GitHub user niklassjogren for reporting this issue!
This bug could cause parts of the surface mesh to be missing near the domain boundary. This bug was caused by a logic error that would result in the adaptive mesher not having full coverage of the fluid particles.
Most of my sims are looking like utter crap, even with high resolution – but I think I can figure that out by reading some more of this thread because I have seen some nice examples. What’s really bothering me is that I have to wait hours to see that utter crap. It’s so slow I feel like I’m in 1996. Why is Blender only using a small fraction of CPU power? I would be more than willing to pay three times the current price for a double speed increase.