Theverat
commented
5 years ago It would be great if you could provide a test scene with 1 frame of the baked simulation that shows the problem and doesn't require the FLIP fluids addon.
Open happysmash27 opened 5 years ago
Theverat
commented
5 years ago It would be great if you could provide a test scene with 1 frame of the baked simulation that shows the problem and doesn't require the FLIP fluids addon.
happysmash27
commented
5 years ago https://happysmash27.me/Upload/Fluid%20Test.blend seems to work when I disable the addon.
Theverat
commented
5 years ago Thanks, I can reproduce the problem.
Theverat
commented
5 years ago The main problem is the way the FLIP fluids addon creates the "whitewater_foam": It uses dupliverts to duplicate a low-poly icosphere with just 20 tris. This creates 101527 instances of this icosphere in your scene.
The long time during export is spent in LuxCore's DuplicateObject() function, which is C++ accelerated already (much faster than Python).
Maybe this function could be optimized a bit, but I doubt it can be multithreaded, as the whole scene initialization process is currently singlethreaded (apart from special stuff like BVH building) - @Dade916 can probably tell us more about this.
However, it is not a good idea in the first place to create many instances of a low-poly object. Every instance has a fixed memory cost, and if the mesh only has 20 tris, this fixed cost is probably higher than the memory saved by instancing.
So, what the FLIP fluid addon should do instead: Create one mesh that contains all the icospheres joined together and has 20 * 101527 = around 2 Mio. triangles (i.e. nothing). A mesh with 2 Mio. triangles can be exported in 0.6 seconds.
canonex
commented
5 years ago So, what the FLIP fluid addon should do instead: Create one mesh that contains all the icospheres joined together and has 20 * 101527 = around 2 Mio. triangles (i.e. nothing). A mesh with 2 Mio. triangles can be exported in 0.6 seconds.
It is not easier, for animations, have the path for single instances instead of rebuilding the mesh every frame?
Theverat
commented
5 years ago I don't think it would make much of a difference. I assume they are already using some fast code path (e.g. C++) to create the mesh with 101527 verts for dupliverts distribution.
happysmash27
commented
5 years ago Surely it could at least be more multi-threaded? My PC has 16 threads, but this only uses one!
It appears that it may be related to https://github.com/LuxCoreRender/BlendLuxCore/issues/197, but I'm not sure. This may also occur with any large object count, such as a render with many very low poly NYC buildings (mostly untextured) which had import times almost as long as it took to actually render each frame.
System Information
Gentoo Linux kernel 4.18.5-gentoo, AMD Radeon RX 480 8GB, 2x Xeon X5560, 4 core 8 threads each resulting in 16 total threads.
Software Version
Short description of error
When rendering water generated with Flip Fluids with whitewater on, exporting the particle objects takes many minutes and uses only a single core. Since this is taking almost an hour and I am only actually rendering for around 20 seconds, this performance is absolutely terrible...
Exact steps for others to reproduce the error
Install Flip Fluids (this can be done by compiling from source, zipping the bl_flip_fluids/flip_fluids_addon folder, then installing the zip).
Add a domain.
Add a plane-like cube as a collision object in the domain.
Add a water inflow in the domain.
Check "Enable Whitewater Simulation" and all whitewater particles under "FLIP Fluid Whitewater" in the physics options of the fluid domain.
Click "Bake" (make sure you have lots of space available on your bake disk though!)
Several hundred frames in, when the water has hit the cube-plane and made lots of whitewater, render the frame or even use the preview render. It will take ages just to prepare the scene, orders of magnitude longer than Cycles even opening Blender from scratch.