Hey, 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, Sebastián > On Feb 19, 2016, at 1:45 AM, David Ullmann <[email protected]> wrote: > > Thanks for your answer Kévin :) > > > On Fri, Feb 19, 2016 at 1:19 AM Kévin Dietrich <[email protected]> > 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 > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
