Mantaflow FLIP particles not working correctly #80088

New Issue

Ervin Weber · 2020-08-24T22:13:43+02:00

Ervin Weber commented

2020-08-24 22:13:43 +02:00

System Information
Operating system: Linux-5.4.0-7642-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100

Blender Version
Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-21 15:35, hash: ebf10b72b0
Worked: 2.83.5

Short description of error
FLIP particles jump around and behave erratically. They seem to over-react to collisions.

But also note that:

in the first frame the particles have already moved outside of the fluid flow object. I think that instead they should have stayed still since gravity wouldn't have had the time to affect them?
in the second frame the particles drop outside of the domain! Is this supposed to happen?
in the third they're back in! but still traveling down!

Exact steps for others to reproduce the error
crazy-particles-290.blend

Open file
Play animation

**System Information** Operating system: Linux-5.4.0-7642-generic-x86_64-with-debian-bullseye-sid 64 Bits Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.100 **Blender Version** Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-21 15:35, hash: `ebf10b72b0` Worked: 2.83.5 **Short description of error** FLIP particles jump around and behave erratically. They seem to over-react to collisions. But also note that: - in the first frame the particles have already moved outside of the fluid flow object. I think that instead they should have stayed still since gravity wouldn't have had the time to affect them? - in the second frame the particles drop outside of the domain! Is this supposed to happen? - in the third they're back in! but still traveling down! **Exact steps for others to reproduce the error** [crazy-particles-290.blend](https://archive.blender.org/developer/F8817797/crazy-particles-290.blend) - Open file - Play animation

Ervin Weber commented

2020-08-24 22:13:43 +02:00

Added subscriber: @ErvinWeber

Raimund Klink commented

2020-08-25 11:18:20 +02:00

Added subscriber: @Raimund58

Raimund Klink commented

2020-08-25 11:28:07 +02:00

Funny what happens if you load the fluid-290.blend into 2.83.5 :D

Funny what happens if you load the fluid-290.blend into 2.83.5 :D ![2020-08-25 11_26_55-Window.png](https://archive.blender.org/developer/F8810148/2020-08-25_11_26_55-Window.png)

Richard Antalik commented

2020-08-26 07:53:56 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-08-26 07:53:56 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2020-08-26 07:53:56 +02:00

I can't reproduce difference when looking at fluid-285.blend in 2.83 or 2.90 or 2.91. You can not compare behavior of 2 files in 2 versions.
fluid-290.blend looks broken in both versions. Perhaps there is some bug in this file, I am not sure. You can change report or create new one to report issue in that file.

So my issue with report is that there are too many files to cross check. it should be possible to use one file to demonstrate bug. I think steps to create such file could help.

I can't reproduce difference when looking at `fluid-285.blend` in 2.83 or 2.90 or 2.91. You can not compare behavior of 2 files in 2 versions. `fluid-290.blend` looks broken in both versions. Perhaps there is some bug in this file, I am not sure. You can change report or create new one to report issue in that file. So my issue with report is that there are too many files to cross check. it should be possible to use one file to demonstrate bug. I think steps to create such file could help.

Ervin Weber commented

2020-08-26 09:11:07 +02:00

Hi Richard, you're right, let me explain better.
I did the tests starting from the same file and then saving the results as new files in 2.83.5 and 2.90.
If the fuild-290.blend seems broken, I think maybe it's because blender 290 broke it. I don't know either.
Here are the steps I used to reproduce the behavior.

Open the attached setup.blend (done in 2.83.5). It contains 2 cubes and an animated cylinder, no fluid enabled.

enable fluid domain on the bigger cube, type liquid, default settings, just change the cache to frames 1-120 (Also you may want to change particle size to 0.001m to see them better)
enable fluid flow on the little cube, type liquid, default settings

enable fluid effector on the cylinder, type collision, default settings

If you repeat the test in both 2.83.5 and 2.90 you'll see the results are similar to the videos I posted above.
At least that's what's happening to me.

To reproduce the slow-motion video I did the following:

changed the animation end frame to 1200
scaled the cylinder keyframes 10 times with the cursor on frame 1
changed the domain time scale to 0.1
changed the fluid cache to 1200

Let me know if you need any more info

setup.blend

Hi Richard, you're right, let me explain better. I did the tests starting from the same file and then saving the results as new files in 2.83.5 and 2.90. If the fuild-290.blend seems broken, I think maybe it's because blender 290 broke it. I don't know either. Here are the steps I used to reproduce the behavior. Open the attached setup.blend (done in 2.83.5). It contains 2 cubes and an animated cylinder, no fluid enabled. - enable fluid domain on the bigger cube, type liquid, default settings, just change the cache to frames 1-120 (Also you may want to change particle size to 0.001m to see them better) - enable fluid flow on the little cube, type liquid, default settings # enable fluid effector on the cylinder, type collision, default settings If you repeat the test in both 2.83.5 and 2.90 you'll see the results are similar to the videos I posted above. At least that's what's happening to me. To reproduce the slow-motion video I did the following: - changed the animation end frame to 1200 - scaled the cylinder keyframes 10 times with the cursor on frame 1 - changed the domain time scale to 0.1 - changed the fluid cache to 1200 Let me know if you need any more info [setup.blend](https://archive.blender.org/developer/F8811633/setup.blend)

Raimund Klink commented

2020-08-26 11:17:08 +02:00

I could not create a simulation in 2.90. The particles were not visible. No idea what is happening...
But I followed your steps with success in 2.83. Either I am doing something wrong or 21cb6f09ff is broken...
success_2_83_5.blend

no_success_2_90.blend

I could not create a simulation in 2.90. The particles were not visible. No idea what is happening... But I followed your steps with success in 2.83. Either I am doing something wrong or 21cb6f09ffa8 is broken... [success_2_83_5.blend](https://archive.blender.org/developer/F8811792/success_2_83_5.blend) [no_success_2_90.blend](https://archive.blender.org/developer/F8811793/no_success_2_90.blend)

Raimund Klink commented

2020-08-26 13:08:28 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Raimund Klink commented

2020-08-26 15:21:15 +02:00

Now I could reproduce it in 2.91 (396d39c6b9). But still not in 2.90. The particles are only visible to me if I open the .blend saved from 2.91. Super weird...
2_91.blend

Blender_2_91.mp4

Blender_2_83_5.mp4

Now I could reproduce it in 2.91 (396d39c6b904). But still not in 2.90. The particles are only visible to me if I open the .blend saved from 2.91. Super weird... [2_91.blend](https://archive.blender.org/developer/F8812205/2_91.blend) [Blender_2_91.mp4](https://archive.blender.org/developer/F8812188/Blender_2_91.mp4) [Blender_2_83_5.mp4](https://archive.blender.org/developer/F8812187/Blender_2_83_5.mp4)

Ervin Weber commented

2020-08-26 17:39:00 +02:00

Sorry Raimund, I forgot to mention that that's also happening to me.
The particles don't appear in 2.90.

But I saw that by changing one of the domain parameters (eg. resolution) makes them appear.
I guess it triggers an update in the fluid sim?

Sorry Raimund, I forgot to mention that that's also happening to me. The particles don't appear in 2.90. But I saw that by changing one of the domain parameters (eg. resolution) makes them appear. I guess it triggers an update in the fluid sim?

Raimund Klink commented

2020-08-26 20:19:02 +02:00

@ErvinWeber Can you tag the report as Blender 2.90?

Could it also be related to OpenVDB somehow?

@ErvinWeber Can you tag the report as Blender 2.90? Could it also be related to OpenVDB somehow?

Ervin Weber commented

2020-08-27 08:25:46 +02:00

Maybe it's particle-related.
It looks like the particles are 1 frame ahead in respect of where they should be.

Eg. in the first frame they should be still inside the emitter. Instead they've already fallen out of it.

Maybe it's particle-related. It looks like the particles are 1 frame ahead in respect of where they should be. Eg. in the first frame they should be still inside the emitter. Instead they've already fallen out of it.

Raimund Klink commented

2020-08-28 00:22:04 +02:00

Added subscriber: @sebbas

Raimund Klink commented

2020-08-28 00:22:04 +02:00

Any chance to get @sebbas on the boat?

Richard Antalik commented

2020-08-28 05:01:06 +02:00

In #80088#1002926, @ErvinWeber wrote:
Open the attached setup.blend (done in 2.83.5). It contains 2 cubes and an animated cylinder, no fluid enabled.

enable fluid domain on the bigger cube, type liquid, default settings, just change the cache to frames 1-120 (Also you may want to change particle size to 0.001m to see them better)

enable fluid flow on the little cube, type liquid, default settings

enable fluid effector on the cylinder, type collision, default settings

If you repeat the test in both 2.83.5 and 2.90 you'll see the results are similar to the videos I posted above.
At least that's what's happening to me.

I was looking at this file yesterday, but I had trouble producing output from setup.blend even in 2.83.4 version. So I started to download 2.83.5 just to be 100% sure there is not any bugfix and return to report later.

So I am testing this file with 2.83.5 now and I am not able to produce output still. Even if I make sure cache folder is fresh or even if I bake cache. Am I missing something?

> In #80088#1002926, @ErvinWeber wrote: > Open the attached setup.blend (done in 2.83.5). It contains 2 cubes and an animated cylinder, no fluid enabled. > # enable fluid domain on the bigger cube, type liquid, default settings, just change the cache to frames 1-120 (Also you may want to change particle size to 0.001m to see them better) > # enable fluid flow on the little cube, type liquid, default settings > # enable fluid effector on the cylinder, type collision, default settings > > If you repeat the test in both 2.83.5 and 2.90 you'll see the results are similar to the videos I posted above. > At least that's what's happening to me. I was looking at this file yesterday, but I had trouble producing output from setup.blend even in 2.83.4 version. So I started to download 2.83.5 just to be 100% sure there is not any bugfix and return to report later. So I am testing this file with 2.83.5 now and I am not able to produce output still. Even if I make sure cache folder is fresh or even if I bake cache. Am I missing something?

Raimund Klink commented

2020-08-28 10:19:24 +02:00

In #80088#1004005, @iss wrote:

I was looking at this file yesterday, but I had trouble producing output from setup.blend even in 2.83.4 version. So I started to download 2.83.5 just to be 100% sure there is not any bugfix and return to report later.

So I am testing this file with 2.83.5 now and I am not able to produce output still. Even if I make sure cache folder is fresh or even if I bake cache. Am I missing something?

For some reason, and I didn't notice it the first times I tried this, you need to update one setting and then the particles are visible. Looks like we found another bug. :)
See attached video
Desktop 2020.08.28 - 10.14.46.04.mp4
PS: Sorry, Shadowplay didn't record my mouse :(

> In #80088#1004005, @iss wrote: > > I was looking at this file yesterday, but I had trouble producing output from setup.blend even in 2.83.4 version. So I started to download 2.83.5 just to be 100% sure there is not any bugfix and return to report later. > > So I am testing this file with 2.83.5 now and I am not able to produce output still. Even if I make sure cache folder is fresh or even if I bake cache. Am I missing something? For some reason, and I didn't notice it the first times I tried this, you need to update one setting and then the particles are visible. Looks like we found another bug. :) See attached video [Desktop 2020.08.28 - 10.14.46.04.mp4](https://archive.blender.org/developer/F8816832/Desktop_2020.08.28_-_10.14.46.04.mp4) PS: Sorry, Shadowplay didn't record my mouse :(

Richard Antalik commented

2020-08-28 12:15:32 +02:00

In #80088#1004135, @Raimund58 wrote:
For some reason, and I didn't notice it the first times I tried this, you need to update one setting and then the particles are visible. Looks like we found another bug. :)

I am aware of this bug - it is already reported. I did exactly same thing as you, but I still can't see particles.

I don't have any problem when I apply quick liquid on default cube or when I create simulation myself. Even if I scale things down to similar scale things are working.
I have looked at flow mesh in edit mode to check if it is watertight, and things started working. So I am not sure what's going on there. At least I can reproduce the issue now.

I will change the file a bit and also subject of report to fluid effector not working correctly, because that's the problem here with this case.

> In #80088#1004135, @Raimund58 wrote: > For some reason, and I didn't notice it the first times I tried this, you need to update one setting and then the particles are visible. Looks like we found another bug. :) I am aware of this bug - it is already reported. I did exactly same thing as you, but I still can't see particles. I don't have any problem when I apply quick liquid on default cube or when I create simulation myself. Even if I scale things down to similar scale things are working. I have looked at flow mesh in edit mode to check if it is watertight, and things started working. So I am not sure what's going on there. At least I can reproduce the issue now. I will change the file a bit and also subject of report to fluid effector not working correctly, because that's the problem here with this case.

Richard Antalik changed title from ~~strange behaviour in mantaflow for blender 2.90 beta~~ to Mantaflow liquid effector not working correctly

2020-08-28 12:21:06 +02:00

Richard Antalik commented

2020-08-28 12:21:06 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Raimund Klink commented

2020-08-28 12:48:47 +02:00

@iss Great to hear that you were able to reproduce the issue. But why did you remove the 2.90 tag? I mean, it is in 2.90 and in 2.91.

Richard Antalik commented

2020-08-28 13:14:12 +02:00

In #80088#1004253, @Raimund58 wrote:
@iss Great to hear that you were able to reproduce the issue. But why did you remove the 2.90 tag? I mean, it is in 2.90 and in 2.91.

Tag is used to indicate in which version issue should be fixed. it is up to developer to assign it.

> In #80088#1004253, @Raimund58 wrote: > @iss Great to hear that you were able to reproduce the issue. But why did you remove the 2.90 tag? I mean, it is in 2.90 and in 2.91. Tag is used to indicate in which version issue should be fixed. it is up to developer to assign it.

Ervin Weber commented

2020-08-28 22:42:39 +02:00

In #80088#1004234, @iss wrote:
I will change the file a bit and also subject of report to fluid effector not working correctly, because that's the problem here with this case.

I don't think it's the effector at fault here.
In my tests:

in the first frame the particles have already moved outside of the fluid flow object. Instead they should have stayed still since gravity wouldn't have had the time to affect them.
in the second frame the particles drop outside of the domain!!! That should never happen!
in the third they're back in! but still traveling down!
Also, in the slow-motion example, the particles gain too much energy when they collide with the domain borders. At the end they became a tornado.

I can only guess here, but I think that the particles are out of synch with the rest of the simulation.
It looks like they are 1 frame ahead of where they should be.
Another possibility is that the gravity gets applied two times per simulation step.

I will download the latest 2.90 beta and check again. In case the particles are still behaving as above I will change the subject of the report and the file.

> In #80088#1004234, @iss wrote: > I will change the file a bit and also subject of report to fluid effector not working correctly, because that's the problem here with this case. I don't think it's the effector at fault here. In my tests: - in the first frame the particles have already moved outside of the fluid flow object. Instead they should have stayed still since gravity wouldn't have had the time to affect them. - in the second frame the particles drop outside of the domain!!! That should never happen! - in the third they're back in! but still traveling down! - Also, in the slow-motion example, the particles gain too much energy when they collide with the domain borders. At the end they became a tornado. I can only guess here, but I think that the particles are out of synch with the rest of the simulation. It looks like they are 1 frame ahead of where they should be. Another possibility is that the gravity gets applied two times per simulation step. I will download the latest 2.90 beta and check again. In case the particles are still behaving as above I will change the subject of the report and the file.

Ervin Weber changed title from ~~Mantaflow liquid effector not working correctly~~ to Mantaflow FLIP particles not working correctly

2020-08-28 23:16:51 +02:00

Raimund Klink commented

2020-08-29 08:42:49 +02:00

Please keep the discussion in the comment section and not in the description...

Ervin Weber commented

2020-08-29 12:41:00 +02:00

Sorry, didn't know was against the rules

Raimund Klink commented

2020-08-29 18:16:39 +02:00

It is not a rule per se as far as I know but a bad practice in my honest opinion.

Sebastián Barschkis commented

2020-09-10 19:05:53 +02:00

It seems this bug is caused by the (relatively small) size of the geometry. If you scale everything up then things start to look normal again.

Will investigate this further.

It seems this bug is caused by the (relatively small) size of the geometry. If you scale everything up then things start to look normal again. Will investigate this further.

Raimund Klink commented

2020-09-11 01:20:01 +02:00

Well, then what is the recommended size of a simulation?
Do I now need to do one meter wine glasses and scale them down after simulating? :D

Well, then what is the recommended size of a simulation? Do I now need to do one meter wine glasses and scale them down after simulating? :D

Ervin Weber commented

2020-09-20 00:46:20 +02:00

I did a few more tests with the same setup: an inflow object and a moving glass.
This time for each simulation I've changed the domain size, AND the domain resolution accordingly, to keep the same cell dimension.
Inflow and glass are the same dimension in each simulation.

domain size	domain resolution	cell size
20 cm	32	6.25 mm
40 cm	64	6.25 mm
80 cm	128	6.25 mm
160 cm	256	6.25 mm

I've attached the blends in a zip file.
test-domain-size.zip

From the results it looks like the problem is not the "scale of the simulation" but just the "size of the domain".
Please look at the image, in each row you can see various frames of the same simulation.

frame 1: the smaller the domain the higher the particles initial velocity (gravity)
frame 2: the smaller the domain size the more particles overshoot (but in fr.3 they go back)
frame 3 & 4: identical result at each domain size
frame 30: the smaller the domain the wilder the particles reaction

My question is: why the results are so different while the cell sizes are the same?
It is my understanding that, everything else being equal, the stability and realism of a simulation depend basically on the particles velocities in relation to the cell size (that's why we use adaptive timesteps). So, if the cell size are the same, the particles should behave the same regardless of the domain size.

Is there something I'm not aware of that explains this behaviour or is it a bug?

I did a few more tests with the same setup: an inflow object and a moving glass. This time for each simulation I've changed the domain size, AND the domain resolution accordingly, to keep the same cell dimension. Inflow and glass are the same dimension in each simulation. | domain size | domain resolution | cell size | | -- | -- | -- | | 20 cm | 32 | 6.25 mm | | 40 cm | 64 | 6.25 mm | | 80 cm | 128 | 6.25 mm | |160 cm | 256 | 6.25 mm | I've attached the blends in a zip file. [test-domain-size.zip](https://archive.blender.org/developer/F8900725/test-domain-size.zip) From the results it looks like the problem is not the "scale of the simulation" but just the "size of the domain". Please look at the image, in each row you can see various frames of the same simulation. - frame 1: the smaller the domain the higher the particles initial velocity (gravity) - frame 2: the smaller the domain size the more particles overshoot (but in fr.3 they go back) - frame 3 & 4: identical result at each domain size - frame 30: the smaller the domain the wilder the particles reaction ![test-domain-size.jpg](https://archive.blender.org/developer/F8900724/test-domain-size.jpg) My question is: **why the results are so different while the cell sizes are the same?** It is my understanding that, everything else being equal, the stability and realism of a simulation depend basically on the particles velocities in relation to the cell size (that's why we use adaptive timesteps). So, if the cell size are the same, the particles should behave the same regardless of the domain size. Is there something I'm not aware of that explains this behaviour or is it a bug?

Jacques Lucke commented

2020-10-14 11:53:10 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2020-10-14 11:53:10 +02:00

I can reproduce the issue and think this behavior should either be fixed or documented by @sebbas. I don't really know what is happening here.

Sebastián Barschkis commented

2020-10-14 22:06:03 +02:00

Thanks for the detailed test @ErvinWeber! Looked into it a bit and it seems there are 2 bugs in this report.
For the 1st one I just committed a fix (11a8a6d0e6). This should make sure that particles never leave the domain bounds. Particles at frame 1 should now also be at the correct position (inside inflow object).

Another fix will follow!

Thanks for the detailed test @ErvinWeber! Looked into it a bit and it seems there are 2 bugs in this report. For the 1st one I just committed a fix (11a8a6d0e6). This should make sure that particles never leave the domain bounds. Particles at frame 1 should now also be at the correct position (inside inflow object). Another fix will follow!

Sebastián Barschkis commented

2020-10-18 20:56:57 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sebastián Barschkis closed this issue

2020-10-18 20:56:57 +02:00

Sebastián Barschkis self-assigned this 2020-10-18 20:56:57 +02:00

Sebastián Barschkis commented

2020-10-18 20:56:57 +02:00

Added two more commits:

Some versioning so that the previous 1st fix (11a8a6d0e6) will also work with older files (1f046e05b6)
Adjustments to external forces: The moving cup from the example scenes should no longer blow up the liquid inside of it (663e047102)

There is still some fine-tuning that can to be done as right now especially the smaller scenes seem to lose liquid once the surrounding obstacle is raised. This is a tricky use-case and would need to be investigated separately.

So in my view this report can be closed. @ErvinWeber if you can, please check if the latest version works better for you and reopen if find things that seems to be off.

Added two more commits: - Some versioning so that the previous 1st fix (11a8a6d0e6) will also work with older files (1f046e05b6) - Adjustments to external forces: The moving cup from the example scenes should no longer blow up the liquid inside of it (663e047102) There is still some fine-tuning that can to be done as right now especially the smaller scenes seem to lose liquid once the surrounding obstacle is raised. This is a tricky use-case and would need to be investigated separately. So in my view this report can be closed. @ErvinWeber if you can, please check if the latest version works better for you and reopen if find things that seems to be off.

Ervin Weber commented

2020-10-18 21:33:25 +02:00

Wonderful! Thanks a lot @sebbas :-) I'm a little busy now, but I will check for sure when possible

Sebastián Barschkis commented

2020-10-18 21:49:36 +02:00

Great, thx!

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 FLIP particles not working correctly #80088

enable fluid effector on the cylinder, type collision, default settings

enable fluid domain on the bigger cube, type liquid, default settings, just change the cache to frames 1-120 (Also you may want to change particle size to 0.001m to see them better)

enable fluid flow on the little cube, type liquid, default settings

enable fluid effector on the cylinder, type collision, default settings