Export: export material's "Alpha Hashed" blend mode as BLEND #1195
Conversation
This previously exported as OPAQUE.
|
Should this really be BLEND as opposed to MASK? |
|
Why would it be MASK? |
Well... It's a long story, but the short version is that I suspect Blender's Alpha Hash mode is the same as (or has the same intended use as) the ALPHA_TO_COVERAGE mode talked about by the Filament team. Basically it's a blend via dithering, rather than by fragment blending, and that allows realtime renderers to continue using the depth buffer the normal way (anyone can feel free to correct me if I'm misrepresenting here). I suspect the "real" answer (if there is such a thing) is that glTF should have an actual hashing or A2C kind of mode, separate from both MASK and BLEND, that does something like what Eevee is doing with hashing. I guess for now, BLEND is closer to Eevee's results here. |
|
Let me first check if I understand correctly: the linked issue suggests changing the definition of MASK to behave like BLEND+cutoff? Precisely how that BLEND is implemented (with alpha-to-coverage in this case) appears to be irrelevant. |
|
Alpha Hash is a pretty flexible thing in Blender, neither MASK nor BLEND are perfect analogs, but I do think it's closer to BLEND for most uses. This change looks good to me. |
|
My understanding is glTF's BLEND's ideal result is a perfectly blended output (ie. as if you used the painter's algorithm on the individual fragments). "Alpha Blend", "Alpha Hashed", and alpha-to-coverage are all approximations to this same ideal result. The ideal result for MASK however is different. It also depends on a cutoff value, unlike the others. |
|
In general I agree, and I think that's the right logic to use for this exporter. But "Alpha Hash" can also give a less pixelated cutoff for cases where the end result is actually more like "Alpha Mask." Similarly, users sometimes want both MASK and BLEND to be enabled, which glTF doesn't currently allow. |
This previously exported as OPAQUE.