@Troy Sobotka (sobotka) I do understand, and totally get the argument, but for my two pennies worth-

I've been told that this is a 'technically correct' behaviour in T56280 and I do get the argument, but I'd still say it should be a check box- 'technically correct' alpha channel or one that works y/n.

I get what you're saying, and though it may well be technically correct...
If I create an image with an element that is completely non-transparent in places as shown in Blender's GUI, as in no 'checkerboard' can be seen through it, and if there were geometry or background behind it then they would also not be seen through it, then the alpha channel should respect this.
I mean this is for creating imagery, and I'm fairly sure most of the planet treats the alpha as describing transparency for compositing - regardless of if it's technically correct or not.
So do I now have to save an emission pass and bolt that onto the alpha or something- how elegant, you must be kidding- this should be a check-box! Do you want 'technically correct' alpha channel or the one that works properly y/n...

It renders to a proper alpha channel, encoded correctly. The Image Viewer is broken when using the transparent background checkerboard.

Marked as resolved by mistake! Sorry! Can't change it back to 'open'...

It renders to a proper alpha channel, encoded correctly. The Image Viewer is broken when using the transparent background checkerboard.

Obviously, I know you can pretend Blender is not a piece of 3D software and treat it as a camera shooting green screen footage, which also obviously is somewhat of a massive pain-in-the-arse.
What I meant is: are there any work-arounds that make the software behave like it ought to, and be capable of rendering with a proper alpha channel?

So basically, as you've closed T78314, that would appear to mean Blender is completely incapable of rendering fire without smoke properly at all with transparency in both EEVEE and Cycles (and flakey at rendering fire & smoke with transparency), and so is unusable for compositing as it stands: is that what is being said here?
That doesn't strike me as terribly useful for production...

Hello all; I tried the above file in 2.83 release version and 2.9 Alpha (version: 2.90.0 Alpha, branch: master, commit date: 2020-06-24 21:51, hash: rBec776f18ff70).
In 2.83 it behaves the same as my previous test.
In 2.9 Alpha baking the noise makes the smoke completely disappear, as shown below-

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.

@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.

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.

Hello, it looks like this might be fixed in the March 2nd build, but with a load of 'new' issues...

Hello, this still seems to be an issue with the March 2nd 2.83 build, but there now seem to be bigger issues in general with this build:

Hello, this still happens in the Feb21 build-
Without Noise:

Hello, this still happens in the Feb21 build-

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

I see what you mean @SlyNine (SlyNine) ! In that case, it looks like the 'use adaptive time steps' setting in the domain is not terribly adaptive! As in, it only does the 'minimum time steps' value in this instance, it does not seem to 'adapt'.

User error! It's the steps in the object properties (idiot!)...

In T70511#792393, @Mark Spink (marks) wrote:

User error (me that is!).

I'd say it's not even working 'properly' for smoke, now you've made me look at it again-

Hello, this still happens in the Feb 18 build of 2.83alpha

Hello, still happens in the 18th Feb build of 2.83alpha-

Interestingly, there's a visible difference between 2.82 release and 2.83 Alpha-

@SlyNine (SlyNine) Agreed that looks nasty.

This looks OK in 2.82 as well-

Looks OK in 2.82 to me-

Particle emitter in foreground, mesh in background, both with 200 subframes set in emitter settings.

Hello, this still happens in the 2.82 release build-

Hello, this still happens in the 2.82 release build-

@Sebastián Barschkis (sebbas) Thanks! I shall be going dark until I install 2.82 release by the way (can't be arsed to download any more betas!)

Shall do, I'm going dark somewhat till 2.82 is released (can't be arsed to download another beta if I can wait a day!)...

Additionally: this still happens in the 5th Feb 2.82Beta build-

I don't get your question really, here's a screen capture of exactly what I've shown above in still images-

Hello. this issue still exists in the Feb 4th Build.

Hello, still an issue in the Feb 4th build.

Hello. this issue still exists in the Feb 3rd Build.

Hello, still an issue in the Feb 3rd build.

Hello All, unfortunately this still happens in the Jan 23rd build-

This still happens in version: 2.82 (sub 6), branch: master, commit date: 2020-01-23 15:59, hash: rB517870a4a11f I'm afraid-

Bugger! This one still twitches-

Just baking the scene I put in T72214 as that had a decent twitch in it - have zeroed all transforms on that as well... I think you may well have found the culprit (namely me by the looks of it!).
I'll throw it on here once it's rendered.

@Sebastián Barschkis (sebbas) Sorry, was busy throwing an animatic together for a job (you've got to love Eevee for that!), I just re baked after resetting all transforms (position was not zeroed out) and it didn't twitch!

I was getting my congratulations speech ready; but unfortunately not...

Same frame as with the 'xxx4a11f' build I grabbed today, re-baked obviously. Sorry...

You sir; have absolutely nailed the bastard! Blender did bake-bake-freedata 40+ times in a row without a twitch (poor choice of words maybe, I'm just about to try T69870 with this build).
No video this time, just this-

@Sebastián Barschkis (sebbas) Let me know when it's in the blender.org 2.82Beta download & I'll happily (not-really) bake it to death (till I get bored again anyway).

Further to my last; I think the current 'xxxeda527' build is LOADS more solid than the previous 2.82Beta builds. And I'm starting to think the the bake - bake - free-bake, bake - bake - free-bake, bake - bake - free-bake, etc. thing I'm doing with a 'simple' scene is not really the best test for this. As in; I've been using this build for some fairly 'heavy' sims this last day, and it's as least as solid as the Nov26-2019-Experimental build which I keep comparing the newer builds to.
But - it still does crash randomly repeatedly baking and re-baking the 'simple' scene, so it's not 100% solid, but then again what is?! (certainly not the software on the Boeing 737 Max!)

Sorry! But yes here's what I'm seeing-

Hopefully you can see the 'xxxeda527' from the splash screen, speeded up the dull baking bit (such a shame you can't do this in real life!)...
Did this on my laptop (I'm still ever so slightly paranoid about my Threadripper), so an Iniel i7 box / GTX 1060 6Gb.

Sorry mate! When I couldn't recreate the bug (quick smoke on cube, sit bottom of domain Z=0, throw a plane at z=0) - I thought 'bugger' it's only in this scene...
So just uploaded the one it definitely showed up in (lazy!).

Just tested in this version: 2.82 (sub 6), branch: master, commit date: 2020-01-20 22:06, hash: rB902209eda527
Still happening.

Just tested in this version: 2.82 (sub 6), branch: master, commit date: 2020-01-20 22:06, hash: rB902209eda527, Odd!
I was trying to bake the file used in T69870 to test it in the new version, and got a crash straight away in the sim bake, re-ran blender and it baked OK.
then, ran Blender after a reboot-
Baked sim and noise successfully once, then crashed on the sim bake after freeing data (in the sim).
Re-ran Blender, baked both successfully once, then baked sim OK and crashed on the Noise bake.
Re-ran Blender again, and It must have baked about 20-25 times flawlessly, then finally crashed on the Noise bake.
This bug is more like an angry, hormonal teenager: very unpredictable mood wise.

Just tried it in version: 2.82 (sub 6), branch: master, commit date: 2020-01-20 22:06, hash: rB902209eda527
Still the same - but noticed a new issue-

Hello, I downloaded version: 2.82 (sub 6), branch: master, commit date: 2020-01-20 22:06, hash: rB902209eda527 and rendered-

No cigar I'm afraid! It 'twitches' between frames 116 & 117, looking in the viewport the whole domain drops about 7cm (measure tool).
The domain stays the same size, but it's at it's full original dimensions by then in the sim anyway.
I tried on another system (laptop) and got the same result, on the same frames. I did notice that, when viewed from the side view, the smoke passes beyond the collision plane after the 'twitch' and stays below it to the end..
When noise is disabled the smoke respects the collision plane throughout the sim.

Thanks Ted! What does that token actually mean though?...

Here's what I get in 2.82 (sub 6), branch: master, commit date: 2020-01-19 22:44, hash: rB81b7f8efaf7a version. I didn't even have to bake the noise to see it.

Shall do Boss: I'm still seeing this on blender.org at about 11AM Sydney time:
Main Branch-

Just tried it in today's build- version: 2.82 (sub 6), branch: master, commit date: 2020-01-19 22:44, hash: rB81b7f8efaf7a
Still the same.

Not grumpy, just tired (05:30 odd here)...
Final straw that broke the camels back type deal...

Further to my previous comment (again), it does crash on Intel hardware as well: I was baking the scene for my latest (and last ever) bug report T73232: Mantaflow: Adaptive Domain breaks Dissolve, on my old HP Z800, using the SSD stripe set on my Threadripper for the cache files via Gig ethernet, when I realised the Z800 had a spare SSD on it- when I swapped to it for the cache and tried to bake the sim uploaded on T73232 Blender died (completely disappeared type crash as usual when baking) 3 times in a row.
I then started thinking it might be an I/O issue...

And in case you were wondering...

Further to my previous comment, I downloaded the latest build of 2.82Beta and 2.83Alpha (version: 2.82 (sub 6), branch: master, commit date: 2020-01-17 18:59, hash: rB5472ae6fdff6 and ersion: 2.83 (sub 0), branch: master, commit date: 2020-01-17 19:09, hash: rB1f92e9903fb7), and for want of a better description- it's a shit-load more reliable!
I baked the above scene in 2.82Beta and it baked both sim and noise about 8 or 9 times all the way through before a 'blender disappears up it's own arse' crash on the noise bake, then another 5 or 6 times all the way before another complete crash, on the noise bake again. 2.83Alpha managed 5 or so complete bakes before crashing blender on the sim bake and I can't be arsed to keep baking and re-baking any more.

Both my report and my comment show the version: Broken: version: 2.82 (sub 6), branch: master, commit date: 2020-01-15 21:07, hash: rB689a873029b9, and

I tried again in today's build: not good news I'm afraid...

So, even more crash-prone, and then as well 4 completed bakes, both sim & noise, so more inconsistent. Bummer!
The above was using this build-

Hello again
this (motion blur badly broken with 'constant' keyframes) still exists in Blender 2.81a
here's the .blend

This issue still exists in the 15th January build of 2.82Beta-

Here you go-

In T71269#815751, @Mark Spink (marks) wrote:

• Hello, all rendering issues fixed as far as I can see, looks like pause & resume works (or at least doesn't start again from first frame when resumed). Thanks!** But the smoke seems to ignore the pre-roll in the scene, from frame -15 to frame 0, or maybe now a 16 frame pre-roll is not long enough perhaps. It looks like T69870 still exists as well-

Just FYI: this bug is not consistent- as in it definitely shows in the .blend I uploaded, but not in every sim I make.
And one very important question- is / should Mantaflow be exactly the same iteration in both 2.82Beta and 2.83Alpha? As in should I mainly be using and reporting bugs from 2.82 or 2.83?

Hello all

See above.

See above.

Hello again

Interestingly... I just downloaded 2.83 Alpha, and it behaves like you are seeing, nothing happens when the particle emitter is enabled (apart from crashing the first time I baked, but not the second: WTF?!), I assume this means that the Mantaflow branch download is now effectively out of date (too bloody confusing! do I use 2.82 beta, 2.83 alpha or Mantaflow experimental to do/test smoke?!?).
I notice that the particle system is ghosted when the scene is opened, and show no 'cache' in the particle panel.
I shall try re-making the particle system afresh and see what happens...

Curios-er and curios-er!!!
I'm getting closer to giving up on Mantaflow for smoke all together!...

The build I reported this bug from: commit date: 2019-12-16 14:05, hash: rBed32db06c124 is the current build AFAIK (I keep looking for a new one, with hopefully some fixes, but the blender.org page still shows 16th December build as the download).
I only use builds downloaded from blender.org since they became available there: trying to keep some consistency, and less multiple installations of Blender!

@Jacques Lucke (JacquesLucke) I'm guessing you are/were using the 16 December build to test this, if you read the report 'Broken Version' section, then you will see this has been generated/reported using the 26 November build, as I report a bug where I find it version wise. Therefore the lack of Fluid on all the objects is because you are not using the same build (as in the 16 December build won't 'see' the fluid system modifiers from the 26 November build and vice versa). I just tried the 16 December build and as you found this bug exists with that build as well.

You've got me! The video above is (rendered) exactly the result of the simulation in the .blend file I uploaded, without and with the second emitter enabled.