-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
@lexaknyazev any thoughts here? |
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. |
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 Has this issue been discussed in PBR Next meetings? |
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? |
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:
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 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. |
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"...? |
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? |
@emackey @donmccurdy |
Relevant read for the cutoff use case: https://bgolus.medium.com/anti-aliased-alpha-test-the-esoteric-alpha-to-coverage-8b177335ae4f. |
While in there updating the spec, can this misspelling of "gauze" also be fixed?
|
Suggestion:
or
|
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
The text was updated successfully, but these errors were encountered: