Transparent/CutOff Loses Transparency

I have a “Timer” created by the adjustment of the cutoff setting. My timer works wonderfully in the Unity Editor. However, on the iPhone device, whenever the cutoff value reaches 1 (which means fully transparent) and then resets back to 0, my entire texture loses its transparency for a brief millisecond and shows a white background (which is the portion that is supposed to be transparent). Again this only happens on the iPhone device. Can someone shed some light on this matter, I have struggling with this for hours.

start not from zero but from 0.011
alpha test is slow for iDevices so there is a little optimization that will skip alpha test completely if ref value is not greater then 0.01
in code:
if( alpha_ref_value <= 0.01 )
skip alpha test

Thanks so much! This fixed my problem!! I was terribly worried that nobody would even know what I was talking about!

That’s terrible. I didn’t think about what the implications of the change with alpha test were; I hate this. It’s just needless complication for those of us who only use Unity iOS.

Thanks for the info, though, Alexey. I’d report a bug about this not being in the manual, but I never got email response about reporting any of the other iOS-specific GPU quirks that exist.

Actually that is not that terrible 8). Sounds more like bug somewhere in combination of render states (or on our end), because alpha test for alpha greater then 0 should always pass, right? Also think of it from another end - it is far easier to write your logic like marklennartprice did - and we try optimize what we can for that case (alpha test is too expensive on gpu). Anyway, i really believe there is bug somewhere on our end anyway, so don’t panic 8)))

I don’t think this is a bug; it sounds like expected behaviour using the Unity 3.0 hack you mentioned.*

For a static use of AlphaTest, or a mix of alpha testing and blending, I understand the logic behind doing what has been done with that hack. It saves lazy people from having to spend a few seconds learning a ShaderLab command, and it stops UT from having to create proper documentation about how to deal with the hardware. So, it makes Unity easier to most users, but it also screws around with the only proper use of AlphaTest Greater 0 on iOS I can think of. That is, when you have animated alpha, and no blending, which is what this thread seems to be about.

  • (If the shader is also blending, then yes, it’s a Unity bug, but the problem would still exist with alpha test-only shaders.)

Sure, it’s best to look at your graphics and decide what the best lower value is to make the effect look best; it’s probably not pure black. However, when designing these graphics, you’re going to use pure black for the parts that you always want invisible, and you should expect AlphaTest Greater 0 to reflect this. Now, we’re forced to deal with some arbitrary number, instead of zero – a number that isn’t even in the documentation.

I like the idea of being able to skip the alpha test when desired, but if that’s possible, and it obviously is, then it needs to be part of ShaderLab and the scripting API, not something that gets redefined willy-nilly by Unity developers who can’t possibly know the intent of everybody using Unity. Making ShaderLab more interactive will probably take a lot more work than the Greater .01 hack, though, so for the time being, just put it in the docs; the current situation is unacceptable.

I agree with Jessy. That’s terrible, and the current situation is unacceptable. Although, apparently, the situation has been accepted, since it’s almost three years later - and I just wound up wasting a bit of time on this same “feature”, which landed me here.

@Alexey: If that’s a bug on the Unity end, then it’s still there.