Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec makes no mention of ALPHA_TO_COVERAGE #1668

Closed
prideout opened this issue Aug 28, 2019 · 12 comments · Fixed by #2067
Closed

Spec makes no mention of ALPHA_TO_COVERAGE #1668

prideout opened this issue Aug 28, 2019 · 12 comments · Fixed by #2067
Milestone

Comments

@prideout
Copy link

If a glTF renderer enables ALPHA_TO_COVERGE (e.g. for leaf foliage) then it will fail to render the AlphaBlendModeTest sample model in the expected way.

Does this mean that engines should always disable ALPHA_TO_COVERAGE? If so, it should be stated in the specification.

More info at:
KhronosGroup/glTF-Sample-Models#221

@pjcozzi
Copy link
Member

pjcozzi commented Sep 11, 2019

@lexaknyazev any thoughts here?

@lexaknyazev
Copy link
Member

My understanding is that the test in the issue covers an important implementation detail but at the same time does not reflect real-world use case of cutout alpha mode.

So I'd update the spec to suggest enabling A2C when cutout is used. Before that, we need to come up with a new sample model that would meet both requirements.

@prideout
Copy link
Author

Yes I think those two action items make sense. To restate: (a) the test should allow A2C rendering to pass and (b) the spec should advise enabling A2C when MSAA is enabled.

@donmccurdy donmccurdy added this to the PBR Next milestone Dec 5, 2019
@prideout
Copy link
Author

@donmccurdy Has this issue been discussed in PBR Next meetings?

@donmccurdy
Copy link
Contributor

Is there a question here that needs to be discussed? From the comments above it sounds like this is waiting for someone to open a PR on the spec, adding the suggestion above as an implementation note. Would that be targeted at implementations on the web?

@emackey
Copy link
Member

emackey commented Aug 18, 2020

We'd need a change to the spec, and some sort of change to the AlphaBlendModeTest model and/or its documentation.

The spec has this to say, currently:

  • MASK - The rendered output is either fully opaque or fully transparent depending on the alpha value and the specified alpha cutoff value. This mode is used to simulate geometry such as tree leaves or wire fences.

These two sentences don't play nice together. The first sentence is quite clear in its call for "fully opaque" rendering of areas that pass the mask test. But the next sentence mentions some intended uses (tree leaves, wire fences) where ALPHA_TO_COVERAGE + MSAA is known to reduce aliasing artifacts. But if a renderer enables A2C + MSAA, they don't get "fully opaque" rendering as a result.

The test model rigidly tests for translucent parts of the MASK and fails them, for not being "fully opaque". This consistency check has helped fix many engines using BLEND mode in inappropriate ways over the years. But I built the test with no understanding of A2C at the time, so it doesn't allow for that. I'm struggling now to figure out how to adjust the test to allow for A2C while still forbidding use of a BLEND mode (assuming it's still important to us to forbid that here...?).

Ideally, both the spec and the test model should be relaxed to allow A2C + MSAA, as that looks nicer for the real-world use cases that typically use this mode in the first place. But we should understand whether or not we're introducing a new visual inconsistency to the ecosystem, and how to protect against that.

@emackey
Copy link
Member

emackey commented Aug 30, 2020

Should glTF have an extension that specifically asks for ALPHA_TO_COVERAGE, using either MASK or BLEND as a fallback value?

Like, let's say a material would be marked as MASK, but there would be an extension saying "Hey we really meant A2C, not fully opaque masking"...?

@donmccurdy
Copy link
Contributor

Should glTF have an extension that specifically asks for ALPHA_TO_COVERAGE

A material specifying A2C feels too technically prescriptive to me... Do any authoring tools have this as a material option? Perhaps Blender's Alpha Hash mode is close, but it isn't the same thing. Alpha dithering was requested somewhere in #1442 as well. Perhaps it'd be possible to generalize those things as a material setting, and let the renderer choose an appropriate technique?

@lexaknyazev
Copy link
Member

@emackey @donmccurdy
Could we try to resolve this with a spec clarification?

@lexaknyazev
Copy link
Member

@echadwick-artist
Copy link
Contributor

While in there updating the spec, can this misspelling of "gauze" also be fixed?

BLEND - The rendered output is combined with the background using the “over” operator as described in Compositing digital images.
Note
This mode is used to simulate geometry such as guaze cloth or animal fur.

@emackey
Copy link
Member

emackey commented Oct 4, 2021

Suggestion:

  • MASK - The material exists where the alpha value is above the alphaCutoff, elsewhere the material does not exist. (Implementation note?) This mode is used to simulate geometry such as tree leaves or wire fences, and the exact appearance of the edges may be subject to implementation-specific techniques such as Alpha-to-Coverage.

or

  • MASK - The rendered output is either fully opaque or fully transparent depending on the alpha value and the specified alpha cutoff value. (Implementation note?) This mode is used to simulate geometry such as tree leaves or wire fences, and the exact appearance of the edges may be subject to implementation-specific techniques such as Alpha-to-Coverage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants