From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Week 3

Week 3 was all about improving the particle cache and the FLIP visualization that I showed you last week.

What's been done

  • To better control the amount of particles in the simulation, I wanted to add a field to the UI that controls the narrow band width. You might recall from last year, where I implemented the Narrow-Band FLIP, that this is the band where all particles live in. So with this new option you can set a wider band and, if set high enough, fill up the entire fluid volume with particles. (rB8b7a20de97cc)
  • It's now possible to visualize mesh and FLIP particles both at the same time in the viewport. For this to work, I decided to divide the cache into two parts: One caches fluid surfaces, the other volumetric data. This way you can freely choose the parts of the simulation that should be cached (e.g. tick both surface and volume caching to visualize mesh and particles). (rBf686625d8bd0, rBdfb1d7f1bd25, rBae8f0385c510)
New options for surface and volumetric caching in the Fluid Cache panel
  • My idea behind this is that simulation and cache should be independent. One should not dictate the other. For instance, smoke simulations currently only work with concurrent volume caching. However, similarly to liquids and particles, I could see smoke meshing become another option beside the volume based Point Cache. Mantaflow vortex-sheets based smoke, for example, does that.
  • While working on the mesh / particle visualization, I discovered that the viewport display switcher for liquids did not work. I pushed some changes that explicitly reload the low-res / high-res mesh when toggling the switcher. For baked caches this works fine, for caches created on-the-fly not so much yet (cache gets reset, I need to look at this again later). (rB8a79adcaf7b4)
  • When reading and writing the cache, particle velocities are now also taken into consideration. For this to work I had to access the pVel array (Mantaflow stores particle properties such as velocity in a separate data structure) and save / load it alongside the actual particle system. (rBe3850739a0bf, rB443d5672347c)
  • I also committed two minor non-particle improvements that are worth mentioning:
    • There is now a CFL field in the UI. It should give the user a bit more control over the size of timesteps. (rBa3efe4898713)
    • As you may know, Mantaflows multigrid solver is already integrated. There was just one bug with closed smoke domains. That's now fixed. (rB8f2ffc1b1cd3)
  • I started with the plugin for liquid drop generation in Mantaflow. So far, it can generate particles based on a given velocity threshold.

Next up

  • I would like to add a new panel for "Fluid particles" to the UI. Through this panel, the user should be able to control particle types (i.e. FLIP, drops, floats, tracer) and particle amount (i.e. how many drop particles to generate) in the scene.
  • While basic drop particle generation in my Mantaflow prototype works, I still need to think about an adjustment constraint. That is, when to kill drop particles. My idea was that either when velocities fall below a given threshold or when drop particles get too deep into the fluid, it is safe to delete them.

Questions

  • On IRC a question on liquid inflow and how to better control it came up. I see that it's currently a problem (inflow objects produce too much liquid), but I am not quite sure how to fix this. How can we have inflow that just drips a bit? I'll probably bring up this topic next Friday when I meet Nils.