Is there any news on it?
looking at the bitbucket page, this can be seen on the frontpage of bitbucket;
BlenderIntegration Branch deleted in mantaflow/manta
[thunil](https://bitbucket.org/thunil) · 2015-04-01
but when you go to all commits, you can read from thunil ,I guess that is Nils Thuery? that he merged the latest extensions at the same date.
https://bitbucket.org/mantaflow/manta/commits/c110e265d468085bf5a12c94005a87361190191d[TABLE=“class: aui aui-table-interactive bb-list commit-list”]
[TR=“class: iterable-item conflict-merge”]
thunil [c110e26](https://bitbucket.org/mantaflow/manta/commits/c110e265d468085bf5a12c94005a87361190191d) Merged latest extensions (blender plugins, mesh generation, smooth obstacle boundaries) 2015-04-01
When I see these things it comes to my mind the reason why Google cancelled the GSOC for Blender, another project that doesn’t land in Blender after a GSOC. If I was Google maybe I would have done the same thing.
The real reason was that Google did not like how the BF was formatting their proposals page for the GSoC students, not because of the success rate.
The real problem with the Blender GSoC is that students came in with the intention to write this major new feature that could be made in a high enough quality for master in the space of 3 months (without having so much as even looked at Blender’s code beforehand). They were too big, and the reality is they need to be small and focused.
Roman did an update to his branch in may.
But it seems that it brokes it. I don’t know if Roman use it only in command line.
But for me, it crashes ; each time, I try to play with mantaflow panel.
I’d really like to see Mantaflow integrated properly as another solver in Blender. Looks like it has many benefits over the current Fluid and Smoke sim. I’m not a developer, but I imagine it is not so easy to integrate an external framework like Mantaflow, so it fits with how Blender works (internal + workflow). Don’t think it’s fair to spread blame around. And now with OpenVDB integration on the way, I think there’s more considerations to make. For example Mantaflow has a remesher (think it is essential to how the algorithm works?), but so does OpenVDB. Also, as I understand it, OpenVDB doesn’t need a domain, while Mantaflow and the current solvers do. Would be nice if we didn’t need domains anymore
Here’s the Manatflow presentation from last years Bconf for those who haven’t seen it:
(I’m the guy who asked the OpenVDB question)
The main thing that bothers me is the way Mantaflow works, you need to feed it a python script and a set of OBJ files. So in the Blender integration, it feels a bit hackish. Maybe there’s a way to get to the C++ code directly, but I don’t really know Mantaflow, so I can’t tell.
And now with OpenVDB integration on the way, I think there’s more considerations to make. For example Mantaflow has a remesher (think it is essential to how the algorithm works?), but so does OpenVDB.
At last check, Mantaflow is using the same mesher as the current liquid simulation in Blender. It’s no big deal, but OpenVDB is a bit more advanced on the topic, and offers more control over the meshing process.
Also, as I understand it, OpenVDB doesn’t need a domain, while Mantaflow and the current solvers do. Would be nice if we didn’t need domains anymore
You would still need a domain actually, as in a way to control where the simulation can go.
Software development makes me cry lol
Hi all, Mantaflow related news from me (admittedly technical):
I was playing around with Mantaflow unrelated to blender when I found out about the planned blender integration. What bothered me too was that:
So I used my spare time last week to dive into the Mantaflow code and removed the Python indirection. Now I’m able to call Mantaflow via the C++ API, which works as expected. To check if my amateurish hacking (I’m no professional developer) produces any meaningful result I imported some fluid sims in blender and everything looks ok so far:
I think this could be helpful for the blender integration, so I will contact Sebastián Barschkis (sebbas, the guy who is working on the fluid-mantaflow branch) soon.
Thats pretty awesome dude
now I’m sad, but I still have hope for 2.8 brushup with some unified phisycs.
Nice - I hope you two guys can work together on this!
it’s nice to see this project is not completely dead! Keep it up guys it would be great to have some fresh stuff in blender sims!
Quick update: liquefying Suzanne just because I can
Simulated with my custom Mantaflow build in a 200³ grid, 2 seconds/frame on my machine.
Can’t wait to experiment with OpenVDB’s meshing abilities…
2 sec a frame. That’s crazy fast. Is it using only CPU?
very cool result!
Yes, CPU only. meshing and particle resampling takes actually longer than simulation… Nevertheless I’m very happy with the speed so far.
Also I just came across this:
It’s from (some of) the Mantaflow authors, source code provided and will be a part of the next Mantaflow release - very exciting!
You are making us all very jealous lol
Is it still domain-based? I’d love to see a move to a functional particle-based system without the need for domains (like Lagoa in Softimage) or a hybrid approach (like Realflow).
Really looping forward too seeing mantaflow move towards being included into blender!
reading that you’ve removed the python connection, and call the c++ files directly makes it a solid implementation.
as noted before, it would be great to See you working together with Sebbas on this.
ps: the video you posted; its author is Nils Thuerey. He wrote the current blender fluid system :). And the turbulence used for smoke is also bases on his paper.