With both DX11 0.7.1 and 1.0.1, all .BMP files that have alpha transparency load with no transparency. Loading a .PNG file exported with a graphics program from that same .BMP file does show transparency. Pipet confirms the alpha value is seen as 1 over the whole image. See attached patch and sample files. Oh and this is with both 34.2_x64 and 35.2_x64. I can’t believe I’ve never noticed this before, but it happens on multiple systems.
(And yes I reported this on @vux github, but it won’t let me attach the .zip file there…)
now i was confused… the bmp in your zip does NOT contain transparency. so i thought your bmp exporter might be to blame. but then i converted the PNG to a new BMP with transparency and it looks the same. so alpha channel is indeed not loaded by the FileTexture node.
@tonfilm when I load that BMP in xnview, it shows with a clear background, and that PNG is exported from that same BMP and it contains a wokring alpha layer so it has to be in there in the BMP. And Info (DX11 Texture 2d) shows the BMP as having an alpha just like the PNG.
@antokhio I’ve always used BMPs for things with alpha masks to prevent compression artifacts on the edges. Noticed some of my old DX9 things I converted to DX11 did not look right, thought it was something I was doing wrong with layer priority or some such and this was the last thing I looked at - after telling an art class to save their stuff as BMP of course. I thought for sure someone would have noticed by now!
At least there is the work-around of converting them to PNG.
Note for 16-bit and 32-bit Windows BMP files, the BMP codec ignores any alpha channel, as many legacy image files contain invalid data in this extra channel. Starting with Windows 8, 32-bit Windows BMP files written using the BITMAPV5HEADER with valid alpha channel content are read as WICPixelFormat32bppBGRA
Maybe this explains it, don’t know if Filetexture uses Wic though.
