# How to properly render smoke on a transparent background?

When rendering volumes with Film > Transparent enabled, the alpha appears to be the wrong type (premultiplied/straight). In the 3D view it works as expected:

This is a known bug.

Is there any way to work around this?

• Green/Blue screen? Should be easy to chroma key as it can all be the exact same shade. – VRM Jun 24 '15 at 0:51

It's a viewer issue only. Try compositing over a gray background using the alpha-over node. If the result is correct, then your file output (without the gray background, of course) will be correct as long as you store it as EXR or any other format with associated (premultiplied) alpha channel, as it's the only way to store pixels that are both transparent and emissive (which is what fire is). The resulting EXR will be fine to be composited over any background, and fire should look ok.

• can you make explaining with images for how to doing that ? – shar May 7 '18 at 20:55
• But this is not practical in a context where you simply can't handle EXR images, e.g. using the image in a game, where you just want a simple PNG with simple transparency. What is the easiest way to work around that? – Ignatiamus Jan 19 '19 at 14:58
• Alright, after some more digging I found out that there's a "Convert Alpha" compositor node in Blender for exactly that purpose: Converting from Premultiplied to Straight Alpha. This poses a minimal loss in image data (which is not noticeable anyway), but it works and you can easily export as PNG. – Ignatiamus Jan 21 '19 at 6:21
• @ignatiamus Unassociated alpha (straight) can't reproduce luminous transparent effects like fire. You need an alpha format that allows you to put emissions where alpha is zero (transparent) and associated (premultiplied) is the only way to do it right.. That can't be done with a PNG as it only supports unassociated alpha. – Gez Jan 23 '19 at 0:45

It looks like alpha simply isn't modelled for emissive volumes in the render. This makes sense because it's an addition rather than an absorption. If the final image is treated as pre-multiplied then alpha simply multiplies the background colour and it works. Perhaps this is what's intended in the current implementation? Otherwise I guess it could be faked by dividing the emission component by the final alpha value, although as colour is clamped this would break the hue for bright emissive volumes. Maybe tone mapping could lessen the effect.

Anyway, I'll try to get some positive alpha value for the emissive volume parts of a render...

Here's my test scene with two intersecting cubes. One with an emissive volume and the other with absorption:

A screenshot from (left) the 3D view and (right) the render.

### Attempt 1

I first tried to reconstruct the alpha for the emissive cube. I figured I'd guess the emissive colour is close to one and the alpha value is then close to the average colour value. Then merge the emissive alpha and real alpha with a maximum node. The gamma node is there because this didn't work so well and needed tweaking:

yes, I found the "set alpha" node but it was too late

### Attempt 2

The second approach was to render with a white background and then black. The difference should indicate any transparent parts of the scene. I'm still not entirely sure why but until I clamped the white background render (with the mix node) the subtraction gave no difference even though it was visually different. The result doesn't look as good as the previous method even though I thought it'd be more accurate.

### Attempt 3

The key here is multiplying the final image by alpha and taking the difference in colour to get just the emissive intensity in the transparent parts. Then adding that amount of alpha to the original.

Comparing this to the 3D view render below shows some colour issues. This is caused by alpha scaling the colour when its meant to be pre-multiplied. I tried a few tricks like the division I mentioned earlier but couldn't get anything that looked any better. The emissive cube looks pretty good, without alpha continuity issues in the previous attempts, although a little darker and more transparent.

Unfortunately, (as you mentionned), this issue is a bug.

There is a workaround however (as @NoviceInDisguise mentioned), which isn't ideal or 100% polished, but its a quick and dirty method to get the job done.

1. As you can see in the screenshot, I have the same issue (Note: This bug only applies to the 'Fire' flow type, the 'Fire & Smoke' type renders without issues).

2. Begin by ensuring that Transparent is checked under Film in the Render Properties Panel, and also that the PNG Type is set to RGBA in Output.

3. Next add a large plane behind the fire object. Ensure that it is wider than the bounds of the camera and is far enough back from the fire object as not to cast light onto it. Give it a simple deep blue emission shader, with strength set to 1. (Note: I've noticed a bug here in 2.74 whereby if there is an object behind the viewport display of the smoke and fire, it wont dispay properly. Don't worry though, this doesn't seem to affect the renders.)

4. Render the image and jump on into the Compositing Screen Layout. Check the Use Nodes, Free Unused, and Backdrop boxes below the Node Editor, and add in a Viewer node.

5. Hit Shift+A and go Matte>Keying, add this to the Node tree.

6. In the Key Colour setting, use the Eye Dropper tool to sample the blue from the original render, this will mask out all hues from the render which display the selected colour. If the blue appears black, it's likely that you don't have the Use Alpha check-box ticked on the Viewer and Composite nodes.

7. This should update the render automatically in the bottom left Image Editor. If it has simply hover over the transparent render and hit F3. If not just give it another render, ensuring that the Compositing check-box is ticked under the Post Processing tab in the Render Properties Panel, and it should display the composite fine.

Et Voila, the final render! :) As I mentioned it's not a perfect solution, and where the blue was subtracted from the edge of the flame it has become slightly pink tinted, but for all intensive purposes it works okay, and colour correction could be applied either in Blender or in Photoshop/Gimp. Finger's crossed the bugs'll be fixed in the next release.

Note: I also posted this workaround in the following thread... Smoke+fire wispy and transparent in render, but fine in render preview

• please do cot copy and paste the same answer. These two questions are duplicities. – David Jun 25 '15 at 14:27
• Regarding "This bug only applies to the 'Fire' flow type, the 'Fire & Smoke' type renders without issues", this doesn't seem to be the case? The problem seems quite apparent even in your screenshot.. – gandalf3 Jun 25 '15 at 17:47
• @gandalf3 I haven't actually included a screenshot for the 'fire & smoke' flow type, the screenshot in Step 1 is only for the fire type. I'll add a 'fire & smoke' screenshot test when I'm home if it would be helpful? :) – Hexbob6 Jun 25 '15 at 20:37
• @David my bad, the 2 questions seemed to require the same solution, what should I do in future in this scenario? – Hexbob6 Jun 25 '15 at 20:38
• The two questions are duplicates, and could be merged. In the future, just vote to close the question as a duplicate. – David Jun 26 '15 at 13:45