[x3d-public] [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0; add Appearance alpha channel for consistency with glTF

Sun Jan 24 11:28:37 PST 2021

Don (Brutzman),

Thank you -- all good. I'll work on it this week. I will try to have a
ready version (as PR in GitHub, that can be then accepted by me or you
by a single-click "Merge") on the nearest Friday, and I'll join the
regular Friday Web3D teleconference to show/synchronize it. So, if we
will all agree that it looks cool, it can be merged and closed on the
nearest Friday.

As for your note in the last minutes """Needed clarification: default
value "AUTO" means that other requirements in the specification are
handled without change.""" -- yes, exactly. The default "AUTO" means
that browsers auto-detect the alpha channel treatment (blending, alpha
test, opaque) just as they did in X3D 3. So we keep perfect backward
compatibility here. And browsers that import glTF can always set it to
something non-AUTO (because in glTF, there is no option to
auto-detect, this value is always explicitly stated).

To all X3D browser implementors: please take a look at CGE
"Appearance.alphaChannel" extension, as my addition to spec will
closely follow it. At least in spirit (I may do some renames to be
even more consistent with glTF). It is documented here:
https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
. The field is useful "by itself" (the capability to specify this is
useful to all X3D authors, I believe), and it is also useful if you
import glTF (to express similar glTF parameter, as documented on
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#alphamode
).

Regards,
Michalis

niedz., 24 sty 2021 o 16:07 Don Brutzman <brutzman at nps.edu> napisał(a):
>
> Issue and progress dialog shifted to public access.
>
> Issue summary:  add Appearance alpha channel for consistency with glTF capabilities.
>
> [1]     Specify alpha channel treatment (field alphaChannel for Appearance)
>         https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
>
> I believe that the corresponding glTF reference follows (please confirm).
>
> [2]     GL Transmission Format (glTF) version 2.0, Alpha Coverage
>         https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#alpha-coverage
>
> This issue is being tracked as
>
> [3]     Mantis 1340: add Appearance alpha channel for consistency with glTF
>         https://www.web3d.org/member-only/mantis/view.php?id=1340
>
> Michalis, please make X3D4 WD3 changes so that they can be applied directly in the github archive.  Please update first.
>
> Last week Dick and I confirmed that CSS styles "approved" and "approvedDeletion" so we will use those together.  Have added initial section there, please modify as appropriate.
>
>
> On 1/22/2021 11:56 AM, Michalis Kamburelis wrote:
> >
> >
> > Cool. I can work on it next week.
> >
> > It will be based on
> > https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
> > . So a question goes to all browser implementors, how do you feel
> > about this extension to X3D -- Appearance.alphaChannel?
> >
> > I may think about renaming the field name and constants to be more
> > consistent with glTF. The field is in Appearance -- as it overrides an
> > auto-detection that normally takes into account both materials and
> > textures.
> >
> > ( If we can move this to x3d-public, please let's do so. More eyes
> > spot more bugs. )
> >
> > Should I write the prose on wiki page, or immediately make a pull
> > request on GitHub?
> >
> > Regards,
> > Michalis
> >
> > pt., 22 sty 2021 o 17:46 Don Brutzman <brutzman at nps.edu> napisał(a):
> >>
> >> This all sounds great.  Thank you.
> >>
> >> Our weekly X3D working group meeting occurs soon.  Michalis, I'll propose that if we can craft draft specification prose for review, over the next week or so, then this is an important response to the recent member specification review.
> >>
> >> Am further happy to report that Wednesday's meeting of Web3D Board of Directors approved submission of the current Working Draft 3, plus comment resolutions, as initial Committee Draft (CD) for ISO/IEC submission.  Completion of responses for this particular issue was already flagged as pending, so we are cleared to "do the right thing" here.
> >>
> >> Our meeting starts shortly, 9-10 pacific time, you are each welcome to join if you like.
> >>
> >> * X3D Teleconference
> >>     https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
> >>
> >> Having fun with X3D and glTF!  8)
> >>
> >> On 1/21/2021 2:23 AM, Michalis Kamburelis wrote:
> >>>
> >>> Thank you!
> >>>
> >>> As for x3d-public mention -- sorry, that was my mistake, I initially
> >>> thought that the spec comment (and thus my answer, and entire thread)
> >>> are on x3d-public mailing list. Only later I realized they are on
> >>> closed x3d mailing list. I'll happily move the discussion to public
> >>> mailing list, x3d-public.
> >>>
> >>> I'll wait for Don Brutzman whether we can squeeze it in X3D 4.0 or it
> >>> should wait for 4.1. If everyone is happy with my existing extension
> >>> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
> >>> , then it is straightforward to add. This extension is also already
> >>> used in Castle Game Engine when we import glTF models, and it allows
> >>> to exactly express the equivalent glTF value.
> >>>
> >>> As for the testcases proving that it is useful -- I already have some
> >>> even in pure X3D :) Indeed auto-detection just cannot work in
> >>> complicated cases (e.g. multiple textures with different alpha
> >>> channels in MultiTexture, combined with material transparency).
> >>>
> >>> Regards,
> >>> Michalis
> >>>
> >>> śr., 20 sty 2021 o 23:49 Don McCurdy <don.r.mccurdy at gmail.com> napisał(a):
> >>>>
> >>>> Thanks Michalis!
> >>>>
> >>>> I think I've managed to join the x3d-public mailing list correctly (here?), but didn't find a thread for this topic — is this the right place to reply, or did I miss a thread?
> >>>>
> >>>> In terms of use cases I often see from three.js and Blender users, the distinction between OPAQUE, BLEND, and MASK is an important one. As an engine implementor I am not confident in my own ability to guess what the intended alpha mode should be for a given material, even if I were to implement a (slow) scan of the texture pixel data. Arguably there is some additional value in other alpha modes, such as BLEND+MASK, or additive or multiplicative blending, but these are currently not within the scope of the glTF specification.
> >>>>
> >>>> All that to say I believe it's valuable information, and I could probably share some examples of glTF assets that might be difficult to render correctly without it, but I understand your interest in limiting increases to the scope of X3D 4.0 and I have no particular recommendation on targeting 4.0 or 4.1.
> >>>>
> >>>> Best,
> >>>> Don
> >>>>
> >>>> On Fri, Jan 15, 2021 at 12:05 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
> >>>>>
> >>>>> ( I'm answering a spec feedback comment, adding also submitter (Don
> >>>>> McCurdy) to recipients. I don't know if you're a member of x3d-public
> >>>>> mailing list, but It happens that I know your email :) ).
> >>>>>
> >>>>> The explicit information about whether to use blending or alpha
> >>>>> testing is indeed not present anywhere in the X3D nodes. The browsers
> >>>>> have to detect it themselves, this was the case in X3D 3 and remains
> >>>>> in X3D 4 for now.
> >>>>>
> >>>>> I fully agree with the submitter that it is an important feature
> >>>>> missing. Indeed automatic detection of it (blending vs alpha testing)
> >>>>> is "tricky" in non-trivial setups. Castle Game Engine does it, all X3D
> >>>>> browsers do it, but in some cases it is an "uncertain heuristic"
> >>>>> and/or requires analyzing the texture contents (thus, not efficient).
> >>>>>
> >>>>> I do have a solution, implemented as X3D extension in Castle Game
> >>>>> Engine now: "Appearance.alphaChannel" field. It allows to explicitly
> >>>>> request treatment as opaque, blending, or alpha test. See the CGE
> >>>>> documentation for details:
> >>>>> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
> >>>>> .
> >>>>>
> >>>>> And see my "glTF -> X3D" page where I document this:
> >>>>> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
> >>>>> .
> >>>>>
> >>>>> I didn't push it for including it in X3D 4.0, as we already have a lot
> >>>>> of stuff in X3D 4. I hoped to talk about it for X3D 4.1. That being
> >>>>> said, if the consensus is that we should amend the existing X3D 4.0
> >>>>> and add it -- I am more than happy to make it :) As said, the prose
> >>>>> and the implementation in CGE is already working and tested. If Don
> >>>>> Brutzman agrees, I am ready to work on it, it is a relatively
> >>>>> straightforward addition to the spec (assuming that my extension on
> >>>>> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
> >>>>> looks reasonable to you all).
> >>>>>
> >>>>> Regards,
> >>>>> Michalis
> >>>>>
> >>>>> pt., 15 sty 2021 o 20:14 Spec Feedback <spec-comment at web3d.org> napisał(a):
> >>>>>>
> >>>>>> -- Submitter indicates that this comment may be public: *Yes* --
> >>>>>>
> >>>>>> Comment on 19775-1: X3D Architecture - V4.0
> >>>>>> 12.4.6 PhysicalMaterial
> >>>>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/ballot/Part01/components/shape.html#PhysicalMaterial
> >>>>>>
> >>>>>> -----------------
> >>>>>> Physical Materials include a "transparency" field, which combines with alpha
> >>>>>> from the baseColorTexture to create a per-fragment alpha color, "used for
> >>>>>> blending or alpha-testing". I was not able to see where or if the material
> >>>>>> specifies its alpha mode. In glTF the possible alpha modes are "OPAQUE",
> >>>>>> "BLEND", or "MASK" (alpha test). I'm assuming I've just missed it elsewhere
> >>>>>> in the spec, but if not, that is critical information for the renderer in
> >>>>>> many cases, and I do believe it should be included. Without this information
> >>>>>> a renderer may need to check the texture for transparent pixels, or may run
> >>>>>> into tricky sorting issues trying to do blending on materials that would have
> >>>>>> been better served by alpha test. Thanks!
> >>>>>> -----------------
> >>>>>>
> >>>>>> Submitted on Friday, 2021,  January 15 - 11:14am
> >>>>>> by  (Don McCurdy )
> >>>>>> IP: 73.70.160.63
> >>>>>>
> >>>>>> See: https://www.web3d.org/node/1694/submission/4448
> >>>>>> _______________________________________________
> >>>>>> x3d mailing list
> >>>>>> x3d at web3d.org
> >>>>>> http://web3d.org/mailman/listinfo/x3d_web3d.org
> >>>>
> >>>> --
> >>>> Don McCurdy
> >>>> donmccurdy.com | 573.480.4115
> >>> _______________________________________________
> >>> x3d mailing list
> >>> x3d at web3d.org
> >>> http://web3d.org/mailman/listinfo/x3d_web3d.org
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman