I've just run into a similar issue. I've not figured out why it's happening yet, but there seems to be a bug report out. Will update if I find out what's causing it.
Update 2020-02-13:
As Cristopher Kawell mentions, this does indeed seem to have been fixed in the most recent (post-2.81?) versions of Blender - thanks Chris for pointing this out!
Update 2019-02-13:
Haven't found the exact underlying cause but I've had a few minutes to test out a few things. It seems like blender is using the base colour's R channel as both the Red colour and an inverse Alpha channel value if the R value is anything other than 1.0 or 0, ignoring the Alpha channel completely, and keeping G and B channels as the values they should be.
Some examples:
All of the below assume a basic model (a cube, say), and no modifications to anything other than the Base Color property of the singular material applied to that model.
RGBA(1,1,1,1)
in blender, Opaque RGBA(1,1,1,1)
in Unity
RGBA(1,1,1,0)
in blender, Opaque RGBA(1,1,1,1)
in Unity
RGBA(0.9,1,1,1)
in blender, Transparent RGBA(0.9,1,1,0.1)
in Unity
RGBA(0.1,1,1,1)
in blender, Transparent RGBA(0.1,1,1,0.9)
in Unity
RGBA(0.1,0,0.1,1)
in blender, Transparent RGBA(0.1,0,0.1,0.9)
in Unity
RGBA(0,1,1,1)
in blender, Opaque RGBA(0,1,1,1)
in Unity
So, to reiterate:
- changing Alpha has no effect on transparency for imported models.
- R values of 0 or 1 equate to an Alpha value of 1
- R values between 0 and 1 equate to an Alpha value of
1 - R
- B and G values do not affect transparency
Hope this helps!