Page MenuHome

EEVEE: Add support for extracting alpha channels from a color
Confirmed, NormalPublicTO DO


I mistakenly filed a bug report --> T72856 EEVEE transparency problem with mtpaint PNG

I didn't fully understand the bug and attached a blender file that didn't show the bug properly.
Packing the image file with blender command 'Pack' makes the image
opaque so it is worthless to include a blender document. I will
include a mtpaint PNG image instead and you can load it into
blender 2.81 yourself and see how it renders in EEVEE versus cycles.

I noticed that your forum converts the image to opaque if I try to attach to this post
so I'll use a shareable link that preserves the transparency:

Here is how I created the mtpaint image to reproduce the problem...

  1. Launch GIMP -->new gimp document -no alpha channel - paint with brush
  2. save as PNG format with no alpha channel
  3. Launch mtpaint ---> open the PNG document
  4. 'Save as' to output the document - one color chosen to be transparent - PNG format
  5. Launch blender 2.81 (linux) - images > Images as planes

EEVEE rendering doesn't respect the transparent region.
Cycles rendering does respect the transparent region.

Not a high priorty.

Event Timeline

Jeroen Bakker (jbakker) renamed this task from mtpaint transparency problem in EEVEE render to EEVEE: Add support for extracting alpha channels from a color.Jan 7 2020, 9:37 AM
Jeroen Bakker (jbakker) changed the task status from Needs Triage to Confirmed.
Jeroen Bakker (jbakker) changed the subtype of this task from "Design" to "To Do".

Hi @Don (don570)

I have to file this as a To Do. EEVEE currently does not support alpha extraction from a color. This can be added, but that is adding a new feature, and not a bug.
I see two ways how to implement this.

  1. when preparing textures for viewport rendering add the alpha channel and fill this based on the alpha color.
  2. when the shader is compiled and a texture with an alpha color is used, compile it differently.

I expect that the shader compilation would be preferred (performance & memory).

I disagree, this is a bug.

The problem is rather that ImBuf does not correctly read the tRNS chunk for RGB images (although it already does for grayscale and palette images).
Solving this should be as easy as adding another png_set_expand call.

It has nothing to do with EEVEE, the same problem occurs in all other areas of Blender.
It's just a coincidence that Cycles implemented its image loading separately.

As for implementing this with a separate shader:
Please don't: It's not worth the time and added complexity, considering that such files are rare.

The developer of mtpaint (wjaguar)
contacted me, and here is what he wrote...

The bug is in blender.
Image format specs, when we lucked to have them, are meant to be read. Test suites, when we have such, are meant to be used. Image loaders written by left hind appendage without engaging the brain, are meant to be fixed.
Let whoever is responsible for PNG loader in EEVEE, avail himself of this snippet of information:
Apparently, color key transparency got ignored, instead of being converted into an alpha plane. Which is a bug.

Hey guys, I don't disagree that it is an issue. According to the rules of the bug-tracker we decided upon the next rules

From now on the Blender Foundation is going to adhere to a strict definition of what a bug is.

    It is only a bug if the code was intended to work and it fails, or when a an issue used to work and it fails.
    It is only a bug if the module is in active maintenance. Otherwise it might be registered as known issue.
    If a bug fix takes more than a day, it is not a bug, it is a development task (if parts of the module plans) or a feature request (which is not supported at the moment).
    If a bug won’t be worked on for the upcoming 6 months, it is not a bug, it is a known issue that needs to be documented.

code was not intended to work as expected by the reporters. Issue is in ImBuf what needs a large overhaul as it has many issues. We can hack something, but that would lead to more maintenance. Doing it once good will reduce maintenance, but will need a new design. Hence I filed it as a todo.