Hi zx-81,
This sounds like an awesome project and would be very cool to see this integrated within Blender as well as other 3d software!
I develop a FLIP-based liquid fluid simulation addon for Blender called FLIP Fluids (not a very creative name!), so I can comment a bit on how we integrate the fluid engine into Blender to be useful for artist’s workflow. I was in a similar position a while ago where the fluid engine was only a script-based application and had no graphical interface. I ended up writing a plugin/addon for Blender so that it was easy for users to set up, run, and render a simulation.
Your process of exporting parameters and fluid sources/solids/forcefields so that it can be run from a console application sounds similar to what we do, so it should work. The only problem I see specifically within Blender is handling the OpenVDB data. As far as I know, there is not much functionality in Blender for loading and rendering OpenVDB volumes. There is a separate OpenVDB branch of Blender, but I do not know much about how functional it is.
As for developing an interface in a variety of 3d software, each software will have its own API with differences in how parameter and object data is accessed, exported, and read. So you will need to write a separate interface for each software based on the API that it provides.
I don’t have any experience developing plugins for software outside of Blender, so I’ll list a few details of how we integrate our addon within Blender:
- Our fluid engine is written mainly in C++. Blender’s API uses Python, so we created bindings to operate the engine from a Python script. Our engine is compiled as a .dll/.so/.dylib library which is loaded using the Python ctypes module.
- One of our main workflow goals was to make sure that Blender can still be used while the fluid engine is running a simulation. This meant that we needed to run the simulator from a separate thread so that the the long running fluid calculations would not stall or stutter the Blender interface. A limitation of the Blender Python API is that it is not thread safe, meaning that we could not use the API to retrieve parameters or source/solid data from the simulation thread. We worked around this limitation by exporting all parameters and object data to files before launching the simulation thread.
- Exporting data: our simulation parameters such as resolution, CFL, viscosity, and many others are exported to a JSON file format. We export the fluid source and solid object data as triangle meshes stored in a binary format. In the case that the parameters or meshes are animated, we export these as a list of values/data for each frame. Internally within the simulator, volumes are represented as levelsets so we convert the triangle mesh data to volumes within the engine.
- Running the simulator: the simulator starts running after we launch the simulation thread from Blender. We start by initializing the engine with all of the parameters and mesh data using the Python bindings, and then run the simulation frame by frame.
- Simulation output: After each frame, the simulation thread retrieves the output data from the engine and writes to disk. Our simulation thread writes the free-surface liquid as a triangle mesh in a binary format. We convert the liquid levelset to a triangle mesh within the engine so that it can be easily loaded into Blender. The simulation thread will also communicate to the main Blender thread with info on any errors or whether the user requests the simulation engine to pause/stop.
- Playback and Rendering: The plugin loads. the triangle mesh data into the 3d viewport using the Python API. The Blender API uses ‘frame change handlers’ that can run code whenever a frame changes and we use this to load new mesh data written by the simulation thread into Blender for playback and rendering.
Creating the addon interface to the engine was a very large task. We wanted the engine to feel like it was tightly integrated with Blender, so we have a lot of workflow features to help the user create, run, and render simulations. I would estimate that the addon interface code is about 30% of the total project in terms of lines-of-code.
I hope this helps give some insight into how to complete your task! Let me know if you have any questions and I’d be glad to answer.
- Ryan