Changing the Alpha Mode of an Image in Cycles doesn't have expected effect. #53672
Images with non-color data such as normal maps that also have an alpha channel containing other data such as a bump map have the color data affected by the alpha channel, even when the Alpha Mode is set to Straight.
When the alpha channel on the image is disabled or when the image file has the alpha channel removed the texture behaves as expected, but this prevents using the data in the alpha channel.
Using Blender 2.79 Cycles renderer.
I can confirm this behaviour and would also expect 'straight' alpha mode to not affect color data.
Maybe @Sergey can have a look?
I'll fix it so we don't premultiply alpha for non-color data. For the OSL / OIIO texture cache case this might be complicated.
Until this is fixed, there is a workaround:
- create two image texture nodes, referencing both the same image (note: this is not the same as duplicating the texture node).
- check 'Use Alpha' for the first, uncheck it for the second
- use the first node to connect RGB, the second to connect alpha.
Didn't check, though, whether this will double memory usage.
If I could have a note: it would be great to make it work properly both for 'Color' and 'Non-Color' data as very specific usage could happen sometimes. Thanks.
It can only work for Non-Color, as alpha must be premultiplied for correct texture filtering of colors and alpha.
In Unity an RGBA image could be imported with some extra settings; on of it that 'how to use the alpha'. When transparency needed, it acts like alpha, when it is an additional data channel, it acts as a greyscale channel.
Sorry for citing Unity; it is because of the flawless workflow in the pipeline.
BTW Marmoset works similarly.
This issue was referenced by blender/cycles@f8b3f970d2
This issue was referenced by
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?