Additional restrictions on alpha modes usage

[lexaknyazev]

From https://github.com/BabylonJS/Babylon.js/issues/3155

shouldn't the 1.0 alpha in baseColor (absent either diffuse texture or vertex colour) essentially make BLEND meaningless?

Let's specify all valid combinations of material.alphaMode and alpha channel in

• material.pbrMetallicRoughness.baseColorFactor
• material.pbrMetallicRoughness.baseColorTexture
• KHR_materials_pbrSpecularGlossiness.diffuseFactor
• KHR_materials_pbrSpecularGlossiness.diffuseTexture

---

Proposal

• OPAQUE: Texture shouldn't contain alpha channel and factor's alpha value should be 1.0.
• MASK & BLEND: Texture should contain alpha channel or factor's alpha value shouldn't be 1.0.

Questions

• When reporting on invalid assets, what should issue's pointer be? Whole material, material.alphaMode, or specific textures/factors?
• What if MR material is OK, but SG isn't (or vice-versa)?
• What about vertex color's alpha channel?

/cc @bghgary @zellski @sebavan

[bghgary]

OPAQUE: Texture shouldn't contain alpha channel and factor's alpha value should be 1.0

If there is an extension that uses the alpha channel of the texture for something else, then this isn't an issue. Do we think these will be warnings or errors or something else?

MASK & BLEND: Texture should contain alpha channel or factor's alpha value shouldn't be 1.0.

Using only alpha value for MASK is strange. Maybe check that also.

what should issue's pointer be?

I vote the whole material.

What if MR material is OK, but SG isn't (or vice-versa)?

Does the validator currently validate extensions?

What about vertex color's alpha channel?

Not sure about this one. Ideally, it needs to be taken into account, but it's trickier as it's a mesh primitive attribute.

[bghgary]

I just realized this is not on the validator repo. Do we actually want to tighten the spec for this?

[lexaknyazev]

If there is an extension that uses the alpha channel of the texture for something else, then this isn't an issue. Do we think these will be warnings or errors or something else?

Could extensions redefine channel meaning for existing textures? I'd call RGBA texture with OPAQUE mode a Hint or an Info.

Using only alpha value for MASK is strange. Maybe check that also.

Not a strong opinion, but I remember cases for that when an object is intentionally hidden at load (because of alphaOffset).

Does the validator currently validate extensions?

It supports SpecGloss schema and texture bindings, but it doesn't compare SG with MR in any way.

I just realized this is not on the validator repo. Do we actually want to tighten the spec for this?

We may want to add an implementation / informative note. Also this repo has bigger outreach.

[bghgary]

Could extensions redefine channel meaning for existing textures?

I don't see why not if they are not being used (i.e. being ignore).

It supports SpecGloss schema

Then I think we should do the same for spec gloss.

+1 to everything else.

[zellski]

I'm happy with where you guys are going with this. I do think vertex alpha should be tested, in much the same way as textures and factors. If ||alpha-1||>epsilon for any vertex, mode must not be OPAQUE. Are there compelling reasons not to check this that I am not thinking of?

[bghgary]

Are there compelling reasons not to check this that I am not thinking of?

@sebavan and I discussed this a bit. One possible issue is if we supported animating alpha values. Not sure how to handle that properly.

[donmccurdy]

Adding hint- or info-level messages from the validator would be helpful. I'm not sure what note we would want to put in the spec though, as there are some valid edge cases like animation as others have mentioned.

[lexaknyazev]

How about:

• Mode should be OPAQUE when vertexColor.a * baseColorTexture.a * baseColorFactor.a equals 1.0 for all vertices / texels.
• Mode should be MASK or BLEND otherwise.

Possible false positive / corner case is when one texture is being used by different materials with different UV data.

[donmccurdy]

Summarizing my offline comments — @lexaknyazev I think both of the rules you describe are good feedback for the validator to provide as hint or info-level messages. For easier implementation it may be reasonable to just check that the texture has an alpha channel, and if so assume some pixels may have opacity < 1.0.

For updating the spec itself, I would suggest some non-normative wording like this:

Implementation note: Setting BLEND or MASK mode on a material with full opacity in baseColorTexture and baseColorFactor may still have side effects in client implementations, such as affecting transparency sorting. Authoring tools should always use OPAQUE mode when no transparency is present, except in special cases, to ensure widest compatibility.

[donmccurdy]

@lexaknyazev does the suggested approach above sound OK?

[lexaknyazev]

I think yes.

Here're action items:

• [ ] Add an impl. note to the spec.
• [ ] Add a validation hint when BLEND or MASK mode is used with opaque material.
• [ ] Add a validation hint when OPAQUE mode is used with non-opaque material.

For validation purposes, opaqueness is defined by baseColorFactor (diffuseFactor), vertex colors, and baseColorTexture (diffuseTexture) alpha channel presence (ignoring actual texel values).

Since vertex colors affect the "definition" of opaqueness, the validator cannot say for sure that a material has one of these issues. Thus it will have to flag the mesh.