Mantaflow Review #59995

New Issue

Bastien Montagne · 2018-12-30T22:06:48+01:00

Bastien Montagne commented

2018-12-30 22:06:48 +01:00

Since Mantaflow project review itself is split in over ten patches, think it's worth having a general task to link them all, and also to manage general requests and discussion.

Detailed review is to happen in relevant differentials.

Since Mantaflow project review itself is split in over ten patches, think it's worth having a general task to link them all, and also to manage general requests and discussion. Detailed review is to happen in relevant differentials.

Sebastián Barschkis was assigned by Bastien Montagne

2018-12-30 22:06:48 +01:00

Bastien Montagne commented

2018-12-30 22:06:48 +01:00

Added subscribers: @mont29, @brecht, @Sergey

Bastien Montagne commented

2018-12-30 22:09:47 +01:00

@sebbas think first step here would be to merge (new, 2.8) master into the branch, feels a bit odd to work on code for 2.7x generation. Gave it a quick try, but there are some noisy amount of conflicts, better to be solved by someone who knows the code. ;)

Jérôme Matthey commented

2018-12-31 02:02:09 +01:00

Added subscriber: @Jerome-Matthey

Rainer Trummer commented

2018-12-31 06:43:10 +01:00

Added subscriber: @RainerTrummer

Sebastián Barschkis commented

2019-04-07 19:42:06 +02:00

@mont29 Yes, that's definitely a good idea. I just updated the diffs (now it's branched from the 2.8 "master") and also synced it with the fluid-mantaflow branch which can be used for test builds. From here we could now get the review rolling.

Nils Thuerey commented

2019-04-08 10:09:40 +02:00

Added subscriber: @n_t

Nils Thuerey commented

2019-04-08 10:09:40 +02:00

Hi everyone, great to see the manta integration being re-revived! @sebbas thanks for the large patch collection. I just checked out and tried the revised diff "from scratch". Works nicely on my MAC. The sims also run through without problem (I tested based on the quick-smoke and quick-liquid setups). So I think this patch looks good, overall. There are some obvious next steps, like removing the old liquid/smoke modifiers, and cleaning up the code, but I think this would be better to address once the manta code is integrated.

I think the basic simulation functionality has also been tested in depth over the course of the last year (and the core solver has been in use for many years), so that should be unproblematic. The integration uses the existing interface for smoke & liquids (the "old" solvers), so I think the key point to look at are the changes to the blender interface. This is relatively straight forward though.

Hi everyone, great to see the manta integration being re-revived! @sebbas thanks for the large patch collection. I just checked out and tried the revised diff "from scratch". Works nicely on my MAC. The sims also run through without problem (I tested based on the quick-smoke and quick-liquid setups). So I think this patch looks good, overall. There are some obvious next steps, like removing the old liquid/smoke modifiers, and cleaning up the code, but I think this would be better to address once the manta code is integrated. I think the basic simulation functionality has also been tested in depth over the course of the last year (and the core solver has been in use for many years), so that should be unproblematic. The integration uses the existing interface for smoke & liquids (the "old" solvers), so I think the key point to look at are the changes to the blender interface. This is relatively straight forward though.

Nils Thuerey commented

2019-04-17 09:46:07 +02:00

@sebbas - I noticed the exported python scene has a few lines at the top for OS/multi-processing checks that don't seem to be used or necessary. (from "withMP ... up to VARIABLES", ca. lines 8 to 18). Those could be removed, right?

Brecht Van Lommel commented

2019-04-17 11:37:10 +02:00

Can someone remind me why this is integrated through Python rather than C++, and how much work it would to change it to C++?

Using Python for modifiers is really bad performance due to the global interpreter lock, and just generally seems to add an additional layer between Blender and Mantaflow whose purpose I don't understand. Not saying it's a showstopper, but I would like to understand what our options are here.

Can someone remind me why this is integrated through Python rather than C++, and how much work it would to change it to C++? Using Python for modifiers is really bad performance due to the global interpreter lock, and just generally seems to add an additional layer between Blender and Mantaflow whose purpose I don't understand. Not saying it's a showstopper, but I would like to understand what our options are here.

Sebastián Barschkis commented

2019-04-18 09:19:04 +02:00

@n_t Yes, you're right. Those lines won't be needed in the future anymore. Will remove them.

Sebastián Barschkis commented

2019-04-18 09:57:12 +02:00

@brecht Right now the only way to access all Mantaflow functions is through Python. In terms of performance I wouldn't say that this is an issue. Once the Manta solver acquires the GIL it will compute one "step" and only once completed release it. The time between steps where other resources (like the UI) can acquire the GIL and Manta has to wait for it would be the only delay during a bake job. This delay is negligible from my experience unless there are other resources that could block the GIL for a very long time.

An alternative to this setup would be to use Mantaflow's C++ API. I am not sure though how far the development of that is, @n_t? And even if it is ready, I don't think using it would bring a performance boost as all code that is called through Python right now runs in OpenMP / TBB. Using a C++ API would also make the solver setup more "static". The current API through Python is more flexible. It makes it really to export the Blender scene as a standalone Mantaflow script. I think it would also be helpful to have Python access for a future node based solver.

@brecht Right now the only way to access all Mantaflow functions is through Python. In terms of performance I wouldn't say that this is an issue. Once the Manta solver acquires the GIL it will compute one "step" and only once completed release it. The time between steps where other resources (like the UI) can acquire the GIL and Manta has to wait for it would be the only delay during a bake job. This delay is negligible from my experience unless there are other resources that could block the GIL for a very long time. An alternative to this setup would be to use Mantaflow's C++ API. I am not sure though how far the development of that is, @n_t? And even if it is ready, I don't think using it would bring a performance boost as all code that is called through Python right now runs in OpenMP / TBB. Using a C++ API would also make the solver setup more "static". The current API through Python is more flexible. It makes it really to export the Blender scene as a standalone Mantaflow script. I think it would also be helpful to have Python access for a future node based solver.

joel heethaar commented

2019-04-18 11:16:50 +02:00

Added subscribers: @DavidUllmann, @joel_nl

joel heethaar commented

2019-04-18 11:16:50 +02:00

There's a pull request from David Ullmann extending the NOPYTHON option.

@DavidUllmann Perhaps you can give some insight in regards to performance?

There's a pull request from David Ullmann extending the NOPYTHON option. @DavidUllmann Perhaps you can give some insight in regards to performance?

Nils Thuerey commented

2019-04-18 16:19:56 +02:00

@brecht Good question, to add to sebbas comments, there are a few reasons for the python bindings: a first mundane one is that that's how the mantaflow solver worked originally, and it would have been a lot more work to switch to C/C++ bindings. Also, the performance impact is negligible, as mantaflow provides all the solver building blocks via python, but each of the steps is quite expensive. So there are no low-level operations in python (e.g. access to grid cells), but just a small number of calls to high level functions that typically make several passes over the full grid.

And then the python bindings provide some interesting outlooks: it will make it very easy to merge any future improvements from mantaflow back into blender, and hopefully at some point also allow for very flexible simulations. E.g., users could add own scripted hooks and modifications via python into the simulation loop to change the way the simulation runs without having to recompile. In general, it makes the data flow in the simulations very flexible. In the long run, I think it would also be awesome to have a kind of node editor to set up the simulations, but that's a bit further away :)

@brecht Good question, to add to sebbas comments, there are a few reasons for the python bindings: a first mundane one is that that's how the mantaflow solver worked originally, and it would have been a lot more work to switch to C/C++ bindings. Also, the performance impact is negligible, as mantaflow provides all the solver building blocks via python, but each of the steps is quite expensive. So there are no low-level operations in python (e.g. access to grid cells), but just a small number of calls to high level functions that typically make several passes over the full grid. And then the python bindings provide some interesting outlooks: it will make it very easy to merge any future improvements from mantaflow back into blender, and hopefully at some point also allow for very flexible simulations. E.g., users could add own scripted hooks and modifications via python into the simulation loop to change the way the simulation runs without having to recompile. In general, it makes the data flow in the simulations very flexible. In the long run, I think it would also be awesome to have a kind of node editor to set up the simulations, but that's a bit further away :)

Brecht Van Lommel commented

2019-04-18 17:00:54 +02:00

Ok. The main concern is not so much that it's slow for fluid simulation by itself, but if multiple performance sensitive areas use Python it does become a problem to have these global locks. If this is how the Mantaflow API works and it's a big burden to use C++ instead it seems acceptable.

For further customization, we should try to figure out a way to fit this into the new node system that is being designed, rather than using Python scripting. We are still trying to work out the design for these kinds of systems, but if there are specific ideas regarding Mantaflow nodes it would be interesting to see what they could look like and how they can fit in.
https://wiki.blender.org/wiki/Source/Nodes

Ok. The main concern is not so much that it's slow for fluid simulation by itself, but if multiple performance sensitive areas use Python it does become a problem to have these global locks. If this is how the Mantaflow API works and it's a big burden to use C++ instead it seems acceptable. For further customization, we should try to figure out a way to fit this into the new node system that is being designed, rather than using Python scripting. We are still trying to work out the design for these kinds of systems, but if there are specific ideas regarding Mantaflow nodes it would be interesting to see what they could look like and how they can fit in. https://wiki.blender.org/wiki/Source/Nodes

Stephen Swaney commented

2019-04-18 17:16:43 +02:00

Added subscriber: @StephenSwaney

Jacques Lucke commented

2019-04-18 21:26:15 +02:00

Added subscriber: @JacquesLucke

Martin Felke commented

2019-04-19 15:10:13 +02:00

Added subscriber: @scorpion81

Nils Thuerey commented

2019-04-23 13:53:49 +02:00

@brecht Okay, yes - the GIL seems to be unproblematic so far. It could make the UI somewhat unresponsive when baking large sims, though. The new node system notes look interesting. I think for mantaflow it would neat to go for the "everything-nodes" direction, where a node graph would define the data flow of the simulation. This could then use a python back-end, or directly hook into the mantaflow functions (the functions that are exposes to python are the crucial ones that ideally would also be available as nodes). It's definitely a good point to keep in mind.

Sam Van Hulle commented

2019-04-25 14:58:13 +02:00

Added subscriber: @frameshift

Nils Thuerey commented

2019-04-26 12:41:10 +02:00

I have another question here for the experienced blender devs (@brecht @frameshift @scorpion81 @JacquesLucke and maybe others?): what would be the best next steps for an official 'approval' of the mantaflow diffs? I saw the 2.8 timeline, and I guess it would be ideal to verify that the patch is in a good enough state some time soon. Then it could be merged into the main branch as soon as possible after 2.8 is released in July, such that it can be included for the 2.81 release.

We could also continue with smaller fixes on @sebbas branch on the side. These shouldn't change anything within the larger structure of the diff here, but there are a few smaller cleanup and UI fixes that would be good to address.

I have another question here for the experienced blender devs (@brecht @frameshift @scorpion81 @JacquesLucke and maybe others?): what would be the best next steps for an official 'approval' of the mantaflow diffs? I saw the 2.8 timeline, and I guess it would be ideal to verify that the patch is in a good enough state some time soon. Then it could be merged into the main branch as soon as possible after 2.8 is released in July, such that it can be included for the 2.81 release. We could also continue with smaller fixes on @sebbas branch on the side. These shouldn't change anything within the larger structure of the diff here, but there are a few smaller cleanup and UI fixes that would be good to address.

Brecht Van Lommel commented

2019-05-01 11:25:21 +02:00

The plan is still for @mont29 to do the initial code review. @mont29, will you have time to do this in the next few weeks? Spending like one day to go over the code and testing the functionality.

Bastien Montagne commented

2019-05-01 15:54:49 +02:00

Yes, it’s still on my radar for this week or next one…

Nils Thuerey commented

2019-05-02 13:56:49 +02:00

@brecht, @mont29 - okay, very good!

Bastien Montagne commented

2019-05-02 16:32:52 +02:00

@n_t Hmm, looks like the branch could use a merge with master again. ;)

Bastien Montagne commented

2019-05-04 11:10:13 +02:00

Some initial usability review after using the branch for a few tests, and a first quick review of the patches:

Results looks great!

Am by no means a specialist of that area, but there is definitively a serious improvement over previous fluid/smoke sims. And I have yet to try all the advanced stuff (especially guiding…).

Usage is less 'user friendly' than with previous sims

You have to bake to see anything, there is no real-time preview/simulation done during play.
For fluids, besides the Show FLIP option which can give you an idea of the result, you even need two steps of baking to get a result (first bake the simulation, then bake geometry and/or particles from sim).

I don’t have a very strong opinion on that, it is more a topic to discuss with artists I guess. Yet I’d expect it to make the 'entry point' for beginners/casual users much higher at least… Realize this is also likely a limitation of the python binding design, this could probably not work well in a real-time context?

On the other hand, the ability to separate baking in steps can also be very useful in more production-oriented cases I think, since you save time by not having to recompute everything if you want to e.g. generate finer mesh.

And the possibility to pause and resume baking is also a nice feature.

Showstoppers

IMHO, opened to discussion, and other devs are welcome to shine in on that topic of course.

Cache Handling

If you go to Edit mode, or try to render non-first frame of the (fully baked) simulation, you lose everything and get dummy domain cube again, until you go back to first frame and 'scroll' again… This is a caching bug, which does not affect cloth simulation in same branch e.g., so think there is an issue in how mantaflow integration code handles this?

Incidentally, there is also missing feedback about cached frames in the timeline (the colored band in the cached range of frames).

No Versioning & Crash

There is no versioning done at all. This means that currently old elbeem sim remain, old smoke one is kind of badly converted to new manta (and crashes)… this should be addressed, in worst case by just nuking old sims altogether.

Trying to open a file with some old sims just crashes for me: old_fluid_sims_test.blend.

Misc

Am getting those messages repeatedly in the console:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 143, in bake_mesh_74
  File "<string>", line 128, in bake_mesh_process_74
NameError: name 'sm74' is not defined

Names are not fully consistent (e.g. the modifier place-holder is still called Smoke, think Fluid would be best here, since it’s the name chosen for the Physics Sims button…). This seems to also sneak in code, where sometimes smoke is used for general MantaFlow handling (in Cycles class name e.g.)…

The old fluid sim code seems to still be around, you can even still use the 'fluid' quick effect operator to set up one, though only half-exposed in the UI then… Think that one should be fully removed.

Adaptive domain is missing (marked as TODO in some areas of code), not a showstopper imho, but still a feature regression.

Code Wise

Some more detailed comments will follow in each differentials, but from general point of view:

Why try to re-use existing Smoke modifier code? To me it only adds confusion, makes naming fuzzy (prefix vary between defines/enums/structs/functions/etc., from old smoke to (way too) generic fluid to few cases using better manta one…). Some names are even plain old ones from smoke, that is utterly confusing.
Old Fluid (elbeem) sim code remains half-active, user cannot directly see/edit it but it can still be added indirectly (through quick effect e.g.), this should be cleaned up I think.
To me it looks like the patches have been split by some kind of logical categorization, but unless am mistaken, they are not independent (as in, I doubt much previous patches can be applied and compile without the last one (D3861)). This is fine for review, but has to be kept in mind for final commit into master (we want all commits there to build and not crash ;) ).

Some initial usability review after using the branch for a few tests, and a first quick review of the patches: ## Results looks great! Am by no means a specialist of that area, but there is definitively a serious improvement over previous fluid/smoke sims. And I have yet to try all the advanced stuff (especially guiding…). ## Usage is less 'user friendly' than with previous sims * You have to bake to see anything, there is no real-time preview/simulation done during play. * For fluids, besides the `Show FLIP` option which can give you an idea of the result, you even need two steps of baking to get a result (first bake the simulation, then bake geometry and/or particles from sim). I don’t have a very strong opinion on that, it is more a topic to discuss with artists I guess. Yet I’d expect it to make the 'entry point' for beginners/casual users much higher at least… Realize this is also likely a limitation of the python binding design, this could probably not work well in a real-time context? On the other hand, the ability to separate baking in steps can also be very useful in more production-oriented cases I think, since you save time by not having to recompute everything if you want to e.g. generate finer mesh. And the possibility to pause and resume baking is also a nice feature. ## Showstoppers IMHO, opened to discussion, and other devs are welcome to shine in on that topic of course. ### Cache Handling If you go to Edit mode, or try to render non-first frame of the (fully baked) simulation, you lose everything and get dummy domain cube again, until you go back to first frame and 'scroll' again… This is a caching bug, which does not affect cloth simulation in same branch e.g., so think there is an issue in how mantaflow integration code handles this? Incidentally, there is also missing feedback about cached frames in the timeline (the colored band in the cached range of frames). ### No Versioning & Crash There is no versioning done at all. This means that currently old elbeem sim remain, old smoke one is kind of badly converted to new manta (and crashes)… this should be addressed, in worst case by just nuking old sims altogether. Trying to open a file with some old sims just crashes for me: [old_fluid_sims_test.blend](https://archive.blender.org/developer/F7004972/old_fluid_sims_test.blend). ## Misc Am getting those messages repeatedly in the console: ``` Traceback (most recent call last): File "<string>", line 1, in <module> File "<string>", line 143, in bake_mesh_74 File "<string>", line 128, in bake_mesh_process_74 NameError: name 'sm74' is not defined ``` Names are not fully consistent (e.g. the modifier place-holder is still called Smoke, think `Fluid` would be best here, since it’s the name chosen for the Physics Sims button…). This seems to also sneak in code, where sometimes `smoke` is used for general MantaFlow handling (in Cycles class name e.g.)… The old fluid sim code seems to still be around, you can even still use the 'fluid' quick effect operator to set up one, though only half-exposed in the UI then… Think that one should be fully removed. Adaptive domain is missing (marked as TODO in some areas of code), not a showstopper imho, but still a feature regression. ## Code Wise Some more detailed comments will follow in each differentials, but from general point of view: * Why try to re-use existing Smoke modifier code? To me it only adds confusion, makes naming fuzzy (prefix vary between defines/enums/structs/functions/etc., from old `smoke` to (way too) generic `fluid` to few cases using better `manta` one…). Some names are even plain old ones from smoke, that is utterly confusing. * Old Fluid (elbeem) sim code remains half-active, user cannot directly see/edit it but it can still be added indirectly (through quick effect e.g.), this should be cleaned up I think. * To me it looks like the patches have been split by some kind of logical categorization, but unless am mistaken, they are not independent (as in, I doubt much previous patches can be applied and compile without the last one ([D3861](https://archive.blender.org/developer/D3861))). This is fine for review, but has to be kept in mind for final commit into master (we want all commits there to build and not crash ;) ).

Bastien Montagne commented

2019-05-04 15:57:22 +02:00

Note: just updated the branch against latest master (was kinda painful, thanks to some 'cleanup' in BKE physics files :( ), would be nice if patches could be updated too.

Nils Thuerey commented

2019-05-05 15:44:39 +02:00

@mont29 thanks for the detailed comments! We'll have to more carefully look at the points you mentioned. Good idea to make the naming scheme consistent, to properly indicate the parts of the new solver. I'd suggest using "manta" there to distinguish it from the old smoke and liquid version.

And you think it would be better to remove the elbeem and smoke solvers directly? That definitely would be a good next step. The manta code was built using the previous smoke version, hence all the similarities. The old smoke modifier should be removed though. And the liquid one as well, together with all the elbeem code...

The cache handling looks like a bug, I'll try to reproduce that. And regarding the old smoke and liquid sims, I think it would be safest and easiest to add a warning they're not supported anymore. The smoke ones potentially could be converted to some extend, but the liquid sims work quite differently now.

@mont29 thanks for the detailed comments! We'll have to more carefully look at the points you mentioned. Good idea to make the naming scheme consistent, to properly indicate the parts of the new solver. I'd suggest using "manta" there to distinguish it from the old smoke and liquid version. And you think it would be better to remove the elbeem and smoke solvers directly? That definitely would be a good next step. The manta code was built using the previous smoke version, hence all the similarities. The old smoke modifier should be removed though. And the liquid one as well, together with all the elbeem code... The cache handling looks like a bug, I'll try to reproduce that. And regarding the old smoke and liquid sims, I think it would be safest and easiest to add a warning they're not supported anymore. The smoke ones potentially could be converted to some extend, but the liquid sims work quite differently now.

Conrad Dueck commented

2019-05-31 17:44:32 +02:00

Added subscriber: @ConradDueck

Grant Kim commented

2019-08-02 05:46:16 +02:00

Added subscriber: @Archost

Sebastián Barschkis commented

2019-09-02 20:57:46 +02:00

Hi everyone! Some very needed updates on the Mantaflow fluids!

Here are some changes that have been addressed (@mont29 thanks for the detailed comments!)

The diffs are now ready for a clean merge. I.e. the 12 diffs could be applied one at a time without any compilation issues in the master branch. One only has to consider the new dependency order (1, 2, 3, 10, 4, 7, 9, 11, 6, 5, 8, 12). That is, [Part 2] depends on [Part 1], [Part 3] depends on [Part 2], and so on.
Old smoke and liquid (Elbeem) code is completely gone.
Names have been cleaned up. Old smoke references have been replaced with "manta".
Adaptive smoke domains are now supported too.
Minor UI cleanups.
Fix for caching bug.
Fix for versioning crash

As always, the fluid-mantaflow branch is up-to-date with the diff (and 2.81 of course). Minor fixes will always go there first and it could be merged into the diffs one last time before landing them in master.

Hi everyone! Some very needed updates on the Mantaflow fluids! Here are some changes that have been addressed (@mont29 thanks for the detailed comments!) - The diffs are now ready for a clean merge. I.e. the 12 diffs could be applied one at a time without any compilation issues in the master branch. One only has to consider the new dependency order (1, 2, 3, 10, 4, 7, 9, 11, 6, 5, 8, 12). That is, [Part 2] depends on [Part 1], [Part 3] depends on [Part 2], and so on. - Old smoke and liquid (Elbeem) code is completely gone. - Names have been cleaned up. Old smoke references have been replaced with "manta". - Adaptive smoke domains are now supported too. - Minor UI cleanups. - Fix for caching bug. - Fix for versioning crash As always, the fluid-mantaflow branch is up-to-date with the diff (and 2.81 of course). Minor fixes will always go there first and it could be merged into the diffs one last time before landing them in master.

Nils Thuerey commented

2019-09-03 18:41:50 +02:00

@sebbas - neat! I've tested the version in the last days. It compiles and runs nicely on my mac. I think this version is ready to be merged, as far as I can see.

Gottfried Hofmann commented

2019-09-09 10:24:32 +02:00

Added subscriber: @GottfriedHofmann

Gottfried Hofmann commented

2019-09-09 10:24:32 +02:00

Thanks to adaptive domain this is now feature complete compared to the old system, yay! Thank you for the hard work over all those years.

I discovered two showstopper issues:

Currently I cannot add modifiers after the manta mod. Many users add modifiers after fluid sims, for example to apply some controllable smoothing that does not require re-bakes.
The cache indication (colored lines) in the timeline is missing.

A nice to have would be a button that bakes both simulation data and mesh at the same time.

Thanks to adaptive domain this is now feature complete compared to the old system, yay! Thank you for the hard work over all those years. I discovered two showstopper issues: - Currently I cannot add modifiers after the manta mod. Many users add modifiers after fluid sims, for example to apply some controllable smoothing that does not require re-bakes. - The cache indication (colored lines) in the timeline is missing. A nice to have would be a button that bakes both simulation data and mesh at the same time.

Gottfried Hofmann commented

2019-09-11 11:22:49 +02:00

What influence does the parameter for Real World Size have? I have created a demo file with a 10cm domain and a simple drop and the result looks like a huge splash (file is attached):

28.02.blend

What influence does the parameter for *Real World Size* have? I have created a demo file with a 10cm domain and a simple drop and the result looks like a huge splash (file is attached): ![realwordsizedrop.png](https://archive.blender.org/developer/F7734498/realwordsizedrop.png) [28.02.blend](https://archive.blender.org/developer/F7734497/28.02.blend)

til ation commented

2019-09-13 21:51:22 +02:00

Added subscriber: @Tilation

til ation commented

2019-09-13 21:51:22 +02:00

This comment was removed by @Tilation

*This comment was removed by @Tilation*

Gottfried Hofmann commented

2019-09-22 10:26:00 +02:00

I found another issue - here the fluid is has an offset to both the inflow and the collision object. The domain has been changed in edit mode:

threeDscans.01.blend

I found another issue - here the fluid is has an offset to both the inflow and the collision object. The domain has been changed in edit mode: ![threeDscans.01.png](https://archive.blender.org/developer/F7768187/threeDscans.01.png) [threeDscans.01.blend](https://archive.blender.org/developer/F7768193/threeDscans.01.blend)

Sebastián Barschkis commented

2019-09-25 15:38:01 +02:00

Hi Gottfried!

The issue with the modifiers should be fixed now! The colored timeline is still a to-do, I'll look into that.

The "Real World size" is currently only being used so that viscosity values can be entered in [m^2 / sec]. Another to-do is to go through all input values and adjust them to world units where possible - taking into consideration the world size (e.g. initial velocities in m/sec).

Your last issue seems to be because of the offset of the origin. If you first apply all transformations and then set the "Origin to Geometry" it should all line up. I see the issue though, better would be to not have to worry about the location of the origin.

Hi Gottfried! The issue with the modifiers should be fixed now! The colored timeline is still a to-do, I'll look into that. The "Real World size" is currently only being used so that viscosity values can be entered in [m^2 / sec]. Another to-do is to go through all input values and adjust them to world units where possible - taking into consideration the world size (e.g. initial velocities in m/sec). Your last issue seems to be because of the offset of the origin. If you first apply all transformations and then set the "Origin to Geometry" it should all line up. I see the issue though, better would be to not have to worry about the location of the origin.

john baker commented

2019-10-05 20:25:59 +02:00

Added subscriber: @jbaker8935

john baker commented

2019-10-05 20:25:59 +02:00

This comment was removed by @jbaker8935

*This comment was removed by @jbaker8935*

Henri Burau commented

2019-10-20 11:18:27 +02:00

Added subscriber: @henrib

15ewolsey@gmail.com commented

2019-11-02 07:43:02 +01:00

Added subscriber: @Enoch11223

Julien Leménicier commented

2019-11-04 21:42:21 +01:00

Added subscriber: @lemenicier_julien

Sam Van Hulle commented

2019-11-24 11:19:43 +01:00

Removed subscriber: @frameshift

Sebastián Barschkis commented

2019-11-29 17:02:11 +01:00

Hi everyone,

so during the past weeks I was able to improve some more areas in the fluid-mantaflow branch. I would say these are the final bigger changes before the master merge.

Here's a quick summary:

Cache: Is much more user-friendly now. In addition to the modular baking system (i.e. bake the base simulation, mesh, and particles all separately), there are 2 new modes:
- Replay: Similarly to the current smoke cache, which bakes on-the-fly during replay.
- Final: Which just bakes the current state of the settings with a single button click.
Fractional Obstacles: Liquid simulations where suffering from stepping effects at inclined obstacles. The new "Fractional" option fixes this problem (it can be thought of as an "anti-aliasing" at the fluid-obstacle interface).
Code structure:
- Mantaflow files have moved to extern/ and are clang-formatted (the Mantaflow updater script (also in extern/) handles this).
- There are only Mantaflow TBB source files now (having the OMP as well gave no real advantage).
New options: Several parameters, that I feel are very useful for artists, have been added to the UI (e.g. FLIP ratio, timestep min/max).
Bug fixes: I counted a total of 16 bug fixes since the last diff.

The only feature that's still missing is the cache color indicator in the timeline. I still might be able to add it before the official release though (I am currently working on the patch for that).
The diffs have been updated too (same state as fluid-mantaflow 6b7b619f06af).

So all in all, I would say the branch is ready for master!

Hi everyone, so during the past weeks I was able to improve some more areas in the fluid-mantaflow branch. I would say these are the final bigger changes before the master merge. Here's a quick summary: - Cache: Is much more user-friendly now. In addition to the modular baking system (i.e. bake the base simulation, mesh, and particles all separately), there are 2 new modes: - Replay: Similarly to the current smoke cache, which bakes on-the-fly during replay. - Final: Which just bakes the current state of the settings with a single button click. - Fractional Obstacles: Liquid simulations where suffering from stepping effects at inclined obstacles. The new "Fractional" option fixes this problem (it can be thought of as an "anti-aliasing" at the fluid-obstacle interface). - Code structure: - Mantaflow files have moved to extern/ and are clang-formatted (the Mantaflow updater script (also in extern/) handles this). - There are only Mantaflow TBB source files now (having the OMP as well gave no real advantage). - New options: Several parameters, that I feel are very useful for artists, have been added to the UI (e.g. FLIP ratio, timestep min/max). - Bug fixes: I counted a total of 16 bug fixes since the last diff. The only feature that's still missing is the cache color indicator in the timeline. I still might be able to add it before the official release though (I am currently working on the patch for that). The diffs have been updated too (same state as fluid-mantaflow 6b7b619f06af). So all in all, I would say the branch is ready for master!

zebus3d commented

2019-11-30 21:53:11 +01:00

Added subscriber: @zebus3dream

AR commented

2019-12-01 22:53:09 +01:00

Added subscriber: @arc4g-1

Vitor Boschi commented

2019-12-03 15:30:45 +01:00

Added subscriber: @vitorboschi

Tyler Furby commented

2019-12-03 20:02:11 +01:00

Added subscriber: @tylerfurby

Tyler Furby commented

2019-12-03 20:23:06 +01:00

Will this by chance bring in OpenVDB integration? According to your website, it stated OpenVDB export (still a bit experimental, though), wasn't sure if that was within the scope of your current branch that you're hoping to get approved into master. And by OpenVDB I presume you mean by the spec of OpenVDB 4.0 so engines like Arnold can directly render them and are directly importable into a DCC application such as Houdini? Also, would this entail any work on some sort of VDB import system to get VDBs imported from Houdini or some other DCC application as well?

Will this by chance bring in OpenVDB integration? According to your website, it stated `OpenVDB export (still a bit experimental, though)`, wasn't sure if that was within the scope of your current branch that you're hoping to get approved into master. And by `OpenVDB` I presume you mean by the spec of OpenVDB 4.0 so engines like Arnold can directly render them and are directly importable into a DCC application such as Houdini? Also, would this entail any work on some sort of VDB import system to get VDBs imported from Houdini or some other DCC application as well?

Maciej Jutrzenka commented

2019-12-03 21:43:52 +01:00

Added subscriber: @MaciejJutrzenka

Tyler Furby commented

2019-12-04 04:45:33 +01:00

Well I got excited and tried out your branch, oh yeah, it's definitely working. That's your OpenVDB cache from MantaFlow rendering right within arnold, why the density channel is called density_s6 -- I don't know. But this is beautiful. Really great work so far.

![unknown (7).png](https://archive.blender.org/developer/F8188916/unknown__7_.png) Well I got excited and tried out your branch, oh yeah, it's definitely working. That's your OpenVDB cache from MantaFlow rendering right within arnold, why the density channel is called `density_s6` -- I don't know. But this is beautiful. Really great work so far.

Sebastián Barschkis commented

2019-12-04 19:16:02 +01:00

Yes, a proper OpenVDB setup where you can import from other DCCs is planned (just not in the 1st release of Manta). For now, the OpenVDB cache option will just save each grid on its own with the name of its parent solver appended (that's why it's "density" and "_s4").

Maciej Jutrzenka commented

2019-12-04 19:20:54 +01:00

can't wait when blender will be able to import openvdb files from houdini :O once this happens Blender will become a true DCC that u can use in big VFX!

Alistair Sealy commented

2019-12-05 03:55:23 +01:00

Added subscriber: @alisealy

Dalai Felinto commented

2019-12-12 15:33:07 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2019-12-12 15:33:07 +01:00

@sebbas +1 for mantaflow to be in master replacing the old system. Important note though, we need to document (in the release notes and the manual) what are the known issues and limitations of mantaflow.

The old system is no longer maintained. People requiring working simulations can always go back to old versions of Blender.

@sebbas +1 for mantaflow to be in master replacing the old system. Important note though, we need to document (in the release notes and the manual) what are the known issues and limitations of mantaflow. The old system is no longer maintained. People requiring working simulations can always go back to old versions of Blender.

Sebastián Barschkis commented

2019-12-13 00:15:28 +01:00

@dfelinto Okay, great! I will take care of the issues / limitations part.

@Sergey All patches are now up-to-date. The last two patches D3852 and D3858 have the changes as we discussed them earlier. That is, the renaming from manta to fluid in both DNA structs, RNA and in the Python UI files. Once those two "go green" we can land everything in master.

@dfelinto Okay, great! I will take care of the issues / limitations part. @Sergey All patches are now up-to-date. The last two patches [D3852](https://archive.blender.org/developer/D3852) and [D3858](https://archive.blender.org/developer/D3858) have the changes as we discussed them earlier. That is, the renaming from `manta` to `fluid` in both DNA structs, RNA and in the Python UI files. Once those two "go green" we can land everything in master.

Sebastián Barschkis commented

2019-12-16 19:20:08 +01:00

So the patches are now in the master branch - big thank you to the reviewers!

Here is a short summary of what I plan to do next:

Move run-time variables out of existing DNA structs. Was mentioned at the end of D3860.
Update documentation for smoke and write new documentation for the liquid simulation system
Explain limitations / current issues of the solver in the Wiki. Some of them will also be marked as ToDo for 2.82 and receive higher priority.
Take care of all the new fluid bugs in the bugtracker

So the patches are now in the master branch - big thank you to the reviewers! Here is a short summary of what I plan to do next: - Move run-time variables out of existing DNA structs. Was mentioned at the end of [D3860](https://archive.blender.org/developer/D3860). - Update documentation for smoke and write new documentation for the liquid simulation system - Explain limitations / current issues of the solver in the Wiki. Some of them will also be marked as *ToDo* for 2.82 and receive higher priority. - Take care of all the new fluid bugs in the bugtracker

Konstantins Visnevskis commented

2019-12-16 21:48:02 +01:00

Added subscriber: @KonstantinsVisnevskis

Sebastián Barschkis was unassigned by Dalai Felinto

2019-12-23 16:42:36 +01:00

Dalai Felinto commented

2019-12-23 16:42:36 +01:00

Added subscriber: @sebbas

Aaron Carlisle commented

2019-12-28 20:24:38 +01:00

Added subscriber: @Blendify

Aaron Carlisle commented

2019-12-28 20:24:38 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Aaron Carlisle closed this issue

2019-12-28 20:24:38 +01:00

Aaron Carlisle self-assigned this 2019-12-28 20:24:38 +01:00

Aaron Carlisle commented

2019-12-28 20:24:38 +01:00

Hi thank you for submitting a patch, unfortunately, we no longer use the task subtype "Patch" please submit new patches through the differential tool: https://developer.blender.org/differential/

Thomas Dinges added this to the 2.82 milestone 2023-02-08 16:43:11 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mantaflow Review #59995

Results looks great!

Usage is less 'user friendly' than with previous sims

Showstoppers

Cache Handling

No Versioning & Crash

Misc

Code Wise