Page MenuHome

Mantaflow Gas domain: 'use adaptive time steps' doesn't seem to adapt.
Closed, ResolvedPublic


System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86

Blender Version
Broken: version: 2.83 (sub 4), branch: master, commit date: 2020-02-20 12:28, hash: rBd95e9c7cf80a
Worked: (optional)

Short description of error
['Use Adaptive Time Steps' setting in the Domain settings only seems to change when the minimum value is raised, as in it does not seem to 'adapt' between the set minimum and maximum values entered.]

Exact steps for others to reproduce the error
[Bake the attached blend with 'Use Adaptive Time Steps' disabled, then again with it enabled and set to minimum=1, maximum=8, it will look the same, with visible steps in the smoke/fire trail every frame, then bake again with 'Use Adaptive Time Steps' minimum increased to 2, you should see the 2 steps in the smoke every frame.
Then again with the minimum set to 3, looks useable by then, and not much different from using a minimum of 4 for this sim.
It looks like this-

And here's the blend-

I put the maximum time steps down to a more reasonable 8, but it still only seems to use the minimum number of time steps regardless.
So it looks to me like the solver is not 'adapting' much, definitely not in this instance anyway.]
[Based on the default startup or an attached .blend file (as simple as possible)]

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Feb 21 2020, 8:26 PM

Glad to see this, explains why I haven't had any luck with that feature yet.

SlyNine (SlyNine) added a comment.EditedFeb 22 2020, 6:13 PM

Another issue is, when time steps are set to a value greater than one and adding noise up-res I get this in *both* smoke and Smoke+fire in the latest alpha 2.83

Mark Spink (marks) added a comment.EditedFeb 23 2020, 12:57 AM

@SlyNine (SlyNine) I'm not seeing that in 2.83Alpha-

This build-

This is baked with minimum=3 'adaptive time steps' and noise baked on top. Are you using 2.82 release version?

Re the Feb 21 build of 2.83Alpha:
I also get a lot (most times I try in fact) of crash-on-load crashes in this build, trying to load previous build Mantaflow scenes.
I had to append all the objects into a new scene to actually load this scene, I could not load the scene without an instant crash. It loaded fine into the previous build. (I didn't test 'adaptive time steps' with this build yet)

SlyNine (SlyNine) added a comment.EditedFeb 23 2020, 5:00 AM

Both 2.82 (if I import a scene baked in 2.83) and 2.83

Its a bit different than the other issue. In that it can take a lot more spread between frames to make it appear sometimes. I'll try to get a few more examples when I get a chance.

Mark Spink (marks) added a comment.EditedMar 3 2020, 2:17 AM

Hello, it looks like this issue has, very nearly, been fixed in the March 2nd build. The smoke looks smooth (almost completely) with time steps appearing to adapt between 1 & 8, and without the bake time being very slow.

I say 'very nearly' fixed, as you can still see a small gap/change in the smoke/fire, at the actual position of the mesh on each frame.
This scene was ok crash-wise for 'free data' & re-bake, but, as you can see at the end, this scene gives you a total crash when you attempt to playback in 'rendered' view mode. (see my comments in T73232 & T72214 re crashes and other issues with this (March 3rd) build.

SlyNine (SlyNine) added a comment.EditedMar 4 2020, 9:26 AM

Sorry it took me so long to get back to this. With March 4th version I'm still getting the same issues. Looking at your picture it doesn't look like you had the minimum set above one in the domain. I've attached more pictures.

Mark Spink (marks) added a comment.EditedMar 6 2020, 1:16 AM

@SlyNine (SlyNine) Agreed, if you set the minimum above 1 now it's broken with noise, but what I'm saying is that with the recent builds you don't see the huge stairsteps between frames anymore with minimum steps, like the image in my original report above, so something is definitely better. As in min=1 max=whatever, now looks better than min=2 or 3 used to. But I agree completely that if you raise the minimum it doesn't look too clever.

Here's min=1 with the March 3rd build-

You can still 'see' where the sphere is on every frame, and the fire trail is noticeably brighter/thicker for the last frame throughout the frame range, but it's nowhere near as bad as it was initially.

Ohh it's a bug! That explains why setting CFL to a low value creates chaos: it wasn't increasing the steps automatically!

This is a really important bug to fix. Can't make a decent explosion without it.

I can confirm the original issue in blender-2.83-f06a6e92bc5e-linux64.

Im having the issue in 2.83 (sub 9), branch: master, commit date: 2020-03-17 20:42, hash: rBdc2df8307f41

Though it seems we can get better results using sub stepping on the emitter object than adjusting the timesteps

Sub steps 4 with time step min 1 - max 1, Very quick simulation

Sub steps 0 with time step min 1 - max 1

Sub steps 0 with time step min 4 - max 4 : Takes forever to simulate, You can see the turbulence force is much more apparent in this one though i'm not sure its behaving properly

Subframe handling has been improved with D7256. Can this be closed?

Sorry guys: I'm up to my neck with a promo & a music promo at the moment (50 clips to key and match-move for the music promo!) hopefully in a week or so I'll be back in Blender for the background plates so I'll be able to look at Mantaflow etc.

Subframe handling has been improved with D7256. Can this be closed?

Sorry to say, but it seems even more broken for me. This is today's (April 2nd) release. Can you please confirm you have it working?

The buildbot version does not have Jacques's fix. You either need to build yourself or wait ~7 more hours from now for a new daily build. Please always include your build hash when commenting about a particular build as I'm only guessing you're using the buildbot right now.

The buildbot version does not have Jacques's fix. You either need to build yourself or wait ~7 more hours from now for a new daily build. Please always include your build hash when commenting about a particular build as I'm only guessing you're using the buildbot right now.

Got it, you're correct. Thanks.

blender-2.83-d0d20de183f1-windows64 - I just want to make sure that (d0d20de183f1) is the hash. Sorry for the noob question.

I'm still getting an issue when adding noise.

Without noise

With noise

I see, I can reproduce the issue when activating noise.

Ah, I know what the issue is. It's a bit difficult to explain: The emission for noise is only happening with the inflow from the last adaptive frame of the base simulation. That's why toward the end of the frame there is correct noise smoke/fire.

I'll commit a fix for this very soon.

Ahhh. Just as I expected. It's something to do with the flux capacitor.

In any case. Thank you! 🎉 🎉 🎉

c2cb87f8976b should fix the issue with the noise. ff2c67d7e8ed makes sure that there is no simulation before the first frame (was happening when using a high value in the "Adaptive Time-steps Minimum").


That seems to have fixed that issue.

I'm not sure if this is an issue or not. I assumed turning the CFL up would make them blender together more.

CFL at 4

CFL at 8

That's correct behavior: A lower CFL value will make the solver perform more simulation steps per frame. And thus the flow in between frames will be more smooth.


The only other odd behavior i've noticed is the speed of simulation. It seems some aspects of the simulation are fixed (so much per step)

Here I set the time scale to 0.01 and changed the minimum domain time-steps to 1 and 20 to exaggerate the effect as much as possible.

This is with the time steps set to 1

This is with the time steps set to 20

Sebastián Barschkis (sebbas) changed the task status from Confirmed to Needs Information from User.Apr 9 2020, 4:39 PM

I see, can confirm the behavior. It looks like that issue is similar to T73837.

In your example, the global vorticity is disabled (set to 0.0) but there is some "Flame vorticity". Can you try setting that to 0.0 too? Doing so should make the results look more alike.
With more timesteps the vorticity forces seem to accumulate resulting in more turbulent smoke/fire.

It seems all problems around this issue have been resolved, so closing the report. Thanks everyone!

Nice! Thanks Sebastian. I'm yet to test it myself, but good to see another one marked as resolved.

Thank you Sebastian! I never did get around to testing that last bit. But the main issues seem resolved.