利用者:Romanp/GSoC Mantaflow Framework/Progress

Progress of week 1

• Reading Mantaflow Simulation in Blender;
• Ensured playback and rendering to be working. No info is yet stored in cache, as at every step the appropriate file is read (files are not too big, ex. density field file is 600kb for a 64^3 grid, and can be processed on the go).

Here is a SimplePlume setting in Mantaflow, as rendered in Blender

Progress of week 2

• Mantaflow setup script for simpleplume simulation is generated by Blender
• Generalization of use-cases: http://wiki.blender.org/index.php/User:Romanp/GSoC_Mantaflow_Framework/Docs/Use_Cases
• description of Mantaflow setup script: http://wiki.blender.org/index.php/User:Romanp/GSoC_Mantaflow_Framework/Docs/Mantaflow_setup_script
• Work on UI controllers for Mantaflow started.

Progress of week 3

• For passing mesh data, started implementation of a signed distance field generation function to Mantaflow.
• Switcher between 2D and 3D solvers added
• Handling wavelet turbulence settings
• Adding emitter noise field settings

Progress of week 4

• Mesh passing between Blender and mantaflow finished
• Ensured initial geometry to be passed correctly to simulation
• working on SDF implementation

Progress of week 5

• Added dynamic sampling for imported meshes, to allow to handle geometry of any refinement level.
• Finished the mesh import/export function.
• Continued on improving the setup script.
• Started work on running Mantaflow from Blender internally.

Progress of week 6

• Work on Mantaflow as Blender's internal module.
• Mantaflow files compile with Blender correctly.
• Working on runtime errors that occur

Progress of week 7

I'm sending my report today, as I will be offline until Sunday due to university exams. Until today, I got Mantaflow compiling and almost running. I'm still getting the "bpy_import_meth()" error. I have some ideas on how to solve the problem, and I will try them out as soon as I am back.

Progress of week 8

Status on 08.07:

Manta module can be imported from blender command line. For that, I had to re-include manta preprocessed files to source/blender/python. Problem remains, that not whole module is included at startup. Only "vectortools" and "solver" class. (to check type "from manta import * ; a = vec3(0,1,2)")

I have to start new interpreter when script is run, and this is possible place where the rest of module gets initiated. New interpreter is started, because I cannot obtain the PyThreadState_Get() when running operations in smoke_api.cpp

Status on 10.07:

Had to run some tests. The problem with not all classes being included was, I had only one include to Manta PyModule initialization function that did not grasp all header files needed. Part of a problem is that when trying to include files, I get "C++ linkage error"

Status on 11.07:

Having solved the linkage error, the not all classes are initialized at startup, but only those which are in the included files. Figuring out where the classnames are included in original Mantaflow.

Status on 12.07:

Working on manta-as-external-lib integration. Resolved the problem I had yesterday with "blender_add_lib" error. It compiles together. Working on using functions of manta from blender code.

Progress of week 9

Status on 14.07

Figuring out why exactly the same configurations in CmakeFiles from manta and blender output register different number of classes. Trying to link manta explicitly in bpy_interface.c -> getting PyThreadState errors. Problem found: only plugin files are not linked to the manta module. Making sure the original manta can be built with given setup-> positive. Issue:plugin files are preprocessed, but no *.reg files are generated

Status on 15.07

Previous problems were due reason that prep binary was not invoked correctly. The add_custom_command option did not work. Spent most of time figuring the errors. Posted a question here, got help from IRC on possible faults. Solved it by reverting order of preprocessed files to original one.

Next, error appears: Undefined symbols for architecture x86_64:

 "Manta::Namify<Manta::FluidSolver>::S", referenced from:
     Manta::FluidSolver* Manta::fromPyPtr<Manta::FluidSolver>(_object*, std::vector<void*, std::allocator<void*> >*)in libbf_python_manta.a(pconvert.o)

Another issue: ld: warning: directory not found for option 'L/Users/pr110/Documents/ WorkingOnNow/gsoc/Blender_test/blender/ ../lib/darwin-9.x.universal/

Status on 17.07

After merging commits, non-existing files are not generated. This was a cause for "No rule to make target..." issue reported earlier. Finding the problem... Issue solved. Next problem: " Undefined Symbols for architecture"

Status on 18.07

Solved the "Undefined Symbols" issue from yesterday. Cause: static manta library is called outside the blender python folder. Code compiles ok. Problem: cmake with Xcode can link most classes to manta module, while compiling with makefiles does not link almost anything. Comparing compile flags between the two... Issue Solved. Classes that are linked in makefiles and xcode are the same. Next issue: code for plugin files is not invoked when initializing manta python module. Comparing compile flags with original mantaflow. Changing compile flags gave no results. Attempting to add header files for plugin sources, and see if they link to module. Adding header files did not help. Finding another possibilities

Progress of week 10

Status on 22.07

Yesterday, I discovered that when compiling mantaflow module with "Gui" flag, 24 classes are linked to the module, whilst without the flag, only 3 are. Finding the problem. Switched to pre-processed version, to allow cleaner integration. Commited pre-processed, as well as full version. To change between then, change source/blender/python/CMakeLists.txt file, as well as bpy_interface.c file. Added debut output to register methods. Issue found : ImageLoaderMachO not adding all classes

Status on 23.07

After digging into debug output, found that loaded methods belong to fluidsimulation.o object in the library. Figuring out why this this object file is so special. Turns out this file is the only one included for method, which runs mantaflow. Trying to include all necessary files explicitly... Having run into many errors, I discarded this option. On the other hand, found the "all_load" linking flag. Trying to use it explicitly for manta library. Problem: "all_load" loads not only all symbols from manta lib, but from following. using "noall_load" flag did not help, since it's no longer supported. Finding another options... Linking with "force_load" solved the problem. Took some time to resolve all previous inclusions.

Status on 25.07

Testing linking. Added UI controllers for start/end frame of simulation. Made code more readable. Wrote some docs on how to use current version.

Progress of week 11

Status on 31.07

Made sure run_sim_step works in C++ code outside the thread. Made each sim step run in separate thread. Added operators for run_sim_step as with generate_sim_file. Added frame number passing from python code though smd->domain->manta_frame_num. Added frame number to threaded execution. Make UI pass calls to function.

Status on 01.08

Due to bug reports on Linux, day spent installing Ubuntu and Compiling Blender on it. Meanwhile debugging issue with densityInflowMesh hanging if script run more than once. Figured out an error with linking manta module in ld.

Progress of week 12

• Extracting scene force fields to pass them to Mantaflow
• reset scene done re-runs of manta_simulations possible
• Linux compile errors and runtime-errors fixed
• Force fields extracted for Mantaflow simulation

Progress of week 13

• Solved the re-run runtime error when domain settings are changed
• Solved the runtime error when re-running sim with wavelets
• Displaying of wavelet simulation corrected
• Rotated geometry correctly passed to Mantaflow
• Speed-up SDF computation when applying inflows to simulation