Page MenuHome

Alpha in image texture node broken in Eevee
Closed, InvalidPublicBUG

Description

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

Blender Version
Broken: version: 2.82 (sub 6), branch: master, commit date: 2020-02-11 14:45, hash: rBc939b4df18e9
Worked: (optional)

Short description of error
Using Eevee, if an RGBA image is added into the image texture node in a shader network then the alpha does not display.
If a separate image texture node is used with an alpha only input file the alpha can be added in, suggesting that the alpha output of the image texture node isn't working.
To illustrate, image textures have been added to two mesh emitters, one with one texture node with an RGBA image (left), one with two texture nodes, one for the RGB and one for the alpha (right). Below the rendered views of the two emitters are shown in Eevee rendered view with blend mode set to 'Alpha Hashed'

Below is what the emitters looks like in Cycles:

Here is the shader network for the emitter on the left:

and the emitter on the right:

I have also attached the blend file used to show this bug and the two image files used.



Exact steps for others to reproduce the error

  1. Load the attached blend file and add the attached image files to the image texture nodes in the shader networks for the materials of the two planes (as shown in the screenshots above).
  2. Ensure the renderer is set to Eevee and Blend Mode of the materials on the mesh emitters is set to 'Alpha Hashed/Blend/Clip'
  3. Change Viewport Shading to 'Rendered' in the 3D viewport.

Event Timeline

Aaron Carlisle (Blendify) changed the task status from Needs Triage to Needs Information from User.Wed, Feb 12, 5:35 PM

This doesn't solve the issue for me

Aaron Carlisle (Blendify) changed the task status from Needs Information from User to Needs Triage.Wed, Feb 12, 6:28 PM
Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Thu, Feb 13, 6:49 PM
Germano Cavalcante (mano-wii) changed the subtype of this task from "Report" to "Bug".

Thansk for the report, I was able to reproduce the problem.
But I think the report can be simplified to "Alpha Channel of a Texture is not displayed in Eevee"

Here is the simplified file:

Is there anything I ignored or can I update the report description?

For this EXR rgba.exr blender as a whole doesnt seem to be able to read alpha. (not sure yet whether this is correct or not)

Image metadata tells the following:

  • was created by oiiotool.exe some.tif someother.tif -chappend -o rgba.exr
  • that -chappend option documents the following:

Replaces the top two images on the stack with a new image comprised of the channels of both images appended together

it now has the following layers in the EXR:

  • Color.RGB
  • Y.Y ?

Not exactly sure why Cycles can interpret that Y.Ylayer as alpha [this might be correct though -- cycles uses oiio as well, maybe that is on that side of the puzzle, needs more investigation...]

If you provide Eevee an EXR that has the Alpha in the A of the Color.RGBA layer, Eevee can do that without problems...

Natron doesnt recognize the Y.Y channel as Alpha by default either...

Looking at this doesnt help (me at least) much either
If it is just luminace, should this always be read as Alpha?
Maybe @Brecht Van Lommel (brecht) knows?

File rgba.exr opened in gimp has no alpha channel, in krita it does.
Not working in 2.79 as well

Files created with blender doesn't seem to have this problem.

This channel layout is nonsensical, how to interpret it is probably not defined anywhere.

My advice is to close this as not a bug, it's not worth spending time to support OpenEXR images that don't follow the standard, created with a command line tool.

Philipp Oeser (lichtwerk) claimed this task.

This channel layout is nonsensical, how to interpret it is probably not defined anywhere.
My advice is to close this as not a bug, it's not worth spending time to support OpenEXR images that don't follow the standard, created with a command line tool.

OK, will close then
@Lexie Lodge (lexielodge): feel free to comment again if you can provide further information about this specific EXR channel layout (and/or its usecase, standard etc)

Have confirmed was issue with the test image file - hadn't realised that the oiiotool had generated the image with incorrectly labelled channels. Thanks.