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
