I want preview some game assets via Cycles for the game Space Engineers. The game uses packed .dds textures where the color and alpha channels store unrelated information: diffuse color + metallness, normal map + glossiness (roughness, inverted).

I think my problem is this documented behavior of image-texture nodes:

Color output: RGB color from image. If the image has alpha, the color is premultiplied with alpha if the Alpha output is used, and unpremultiplied or straight if the Alpha output is not used.

The result is that my shader nodes produce some strange artifacts when I use both image-texture outputs:

rendering artifacts when using both, color- and alpha-output

If I extract the alpha-channel of the textures into separate files and plug those in, the problem goes away. But I don't like doing that because it introduces an otherwise unnecessary conversion step to my workflow.

enter image description here

Here is what I already tried:

  • Making sure Alpha is set to Straight for each image. I think that only affects how Blender treats the data it reads from file, though.
  • Load the .dds into two separate image-datablocks. The first image has Use Alpha disabled and provides the RGB channels. The second one has Use Alpha enabled and provides the Alpha channel. This resulted in largely the same problem because it seems Blender optimizes internally and loads the same file only really once. I think that because toggling Use Alpha seems to affect the image-data of both images (without reflecting that in the UI).
  • Use a MixRGB node: Add the color (0,0,0,1) to the color output and clamp the result. This shouldn't change the color (because adding black does nothing) and remove any transparency (because 1 + anything is 1 when clamped). Sadly, that didn't do anything.

Am I out of luck and using the alpha output simply cannot be done without affecting the color output?

  • $\begingroup$ Can't you just devide by the alpha to undo the premultiplication (use math nodes) $\endgroup$ Jun 14, 2015 at 15:36
  • $\begingroup$ Hm, now that you mention that, I wonder if what I'm seeing is the automatic reversal of premultiplication. Although the red parts are non-metallic, i.e. the alpha-channel is completely black (0.0) in those places and should destroy all color information. $\endgroup$
    – Harag
    Jun 14, 2015 at 16:50
  • $\begingroup$ Workaround: Duplicate each Texture Input node and get the RBG value from one, and the Alpha value from the other input. Yes, suboptimal, I'm discussing it at irc://irc.freenode.net#blender currently $\endgroup$ Jun 14, 2015 at 17:47

1 Answer 1


The workaround WorldSEnder mentioned above is the only solution:

Duplicate each Texture Input node and get the RBG value from one, and the Alpha value from the other input.

The stance here seems to be that texture-files are simply not expected to contain unrelated information. The optimization to pack several unrelated channels into one texture-file to improve memory-locality on the GPU is just not that relevant to Blender to warrant a change to the behavior of Texture Input nodes.

  • $\begingroup$ That's strange, I get the exact opposite behavior here. Unrelated data stored in the alpha channel only works when both color and alpha are connected, otherwise the premul kicks in. Take a look at this file, it renders correctly here, but will get weird colors if you disconnect the alpha>roughness noodle: pasteall.org/blend/36709 $\endgroup$
    – JtheNinja
    Jun 24, 2015 at 5:09
  • $\begingroup$ I've had a look and I can see your problem. I can't be certain that this is the same issue, though. At least what I'm experiencing is in line with the documentation. Your issue is the exact opposite of what the documentation says. Maybe it would be best to avoid using this kind of textures with Blender entirely. $\endgroup$
    – Harag
    Jul 5, 2015 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .