[Bf-committers] Blender Mantaflow integration

Sebastián Barschkis sebbas at sebbas.org
Sat Feb 20 15:22:52 CET 2016


good to see this getting some traction!

First of, David: After watching your fluid simulation videos I had to try it 
myself. I ran the flip scenes after baking the simulation data with the console 
applications and got some nice splashing Mantaflow fluids in Blender :) That's
actually a really nice approach.

Though it is probably difficult to merge in your C++ API (too much modified
Mantaflow code), I could see this as good starting point for a Blender developer 
getting started with Mantaflow. You should, however, provide some more
explanations (in the readme) on how your modified Mantaflow code relates to 
Blender and how to get started.

Yesterday I also spoke to Nils and we discussed some of the concerns that were
raised earlier. As for the "Python vs. C++ API" question, we are for now going
to stay on track with Python. 
Yes, I admit some clean up needs to be done. However, having direct access to
the solver might come in handy later on.
I think it also good to use what we already have, as we can now expand from 
smoke sims to liquids sims. An official Mantaflow C++ API might come anyway, so
there is no need to build a "special" one for Blender.

Best wishes,

> On Feb 19, 2016, at 1:45 AM, David Ullmann <robozyt at gmail.com> wrote:
> Thanks for your answer Kévin :)
> On Fri, Feb 19, 2016 at 1:19 AM Kévin Dietrich <kevin.dietrich at mailoo.org>
> wrote:
>> ...
>> 1. the various "lookup" functions are put inside (threaded) loops [0]
>> 2. a Python API is generated
>> My idea was to just use the result of (1.), and make a nice C/C++ API
>> for it for use in Blender.
> I think I know what you mean, my modified Mantaflow library does use the
> result from (1.)
> since it is actually based on the already preprocessed functions (expanded
> to the OpenMP versions)
>> With your approach, it'll make things a bit harder if we want keep the
>> code somewhat aligned with upstream (unless you get your work accepted
>> by upstream). Maybe others can comment here too. But it could work out,
>> I guess.
> Indeed, keeping up to date with upstream is not easy with my approach since
> it differs significantly from vanilla Mantaflow, mainly because <-->
>> ... the only way the Mantaflow
>> "integration" will be accepted in Blender (in master), is to either get
>> rid of, or bypass, the Python API (i.e. not hacking the BPY module).
>> (And I know Sebastián is not really to blame here ;) )
> <--> I removed the Python API completely.
> Btw I got pretty excited when I just read on BA that you are working on a
> OpenVDB based fluid solver ;)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list