[x3d-public] Material textures and "mapping" field
Andreas Plesch
andreasplesch at gmail.com
Fri Sep 25 13:47:47 PDT 2020
> Date: Fri, 25 Sep 2020 10:53:17 -0700
> From: Don Brutzman <brutzman at nps.edu>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: [x3d-public] X3D minutes 25 SEP 2020: conference, https
> DOCTYPE, X3D4 PBR Material textures and "mapping" field
> Message-ID: <1ad54bc7-c78f-5c09-73ef-236fce1fc004 at nps.edu>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
Thanks for sharing these notes.
> 3. Resolution of X3D4 node signature changes for advanced Material texturing techniques
>
> Special thanks to Michalis Kamburelis and Andreas Plesch for steady efforts on this challenge. Looks like we are close to resolution.
>
> [3.1] [x3d-public] wondering about Texture mapping specified in material nodes,
> X3D4 usage tradeoffs and draft meeting agenda
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013651.html
>
> [3.2] [x3d-public] wondering about Texture mapping specified in material nodes,
> X3D4 usage tradeoffs and draft meeting agenda (review summary)
> http://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013658.html
>
> [3.3] Proposal: Change mapping concept into a number of xxxTexCoord fields in geometry
> https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-Change-mapping-concept-into-a-number-of-xxxTexCoord-fields-in-geometry
>
> [3.4] Proposal: wrap index values in a new node
> https://github.com/michaliskambi/x3d-tests/wiki/Proposal:-wrap-index-values-in-a-new-node
>
> [3.5] X3D4 Working Draft 2 (WD2) Shape Component
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html
>
> We started with confirmation that we all share the same goals, to get best alignment with X3D Specification.
>
> a. Review of tradeoffs.
>
> Michalis did a masterful and thorough job leading our exploration expedition through the many alternatives on the screen with Dick and I. An exhilarating 2-hour journey! Certainly with much much much scrutiny and applause for Andreas' work along the way.
>
> We essentially have 2 feasible choices before us:
>
> - "mapping" approach to identify multiple nodes with common relationship, and
> - Andreas refactoring of strictly typed field relationships, distributed into geometry nodes (rather than all in Material as I had posed earlier).
I would not claim this as my proposal, rather it was a joint effort.
> Several priorities emerged from this "deep dive" exploration.
>
> - Modifying geometry nodes with many fields is technically feasible (and not dissimilar to what we did with Shader attrib fields), but
> - Keeping geometry design pristine is appealing.
The main motivation for targeting geometry was that it already has a
texCoord field. There are other options if geometry should stay
pristine. One which was not discussed sofar (and perhaps never will
be) is to add another field to Shape, say a SFNode "texMappings'' with
xxxTexCoord fields, ad xxxtextureTransform fields. This would probably
allow for reuse of both Appearance( and Material) and geometry. Such a
design may actually fit better the role of texCoords and transforms as
linking material textures and geometry.
> - Strictly typing the different node relationships is consistent with X3D3 design conventions, but
> - Using a "mapping" approach keeps the door open for most conceivable possible evolutions in glTF (fuzzyMaterial, psychedelicMaterial, whatever).
Indeed, there are probably plans to go beyond PBR. But that would
require more substantial additions to X3D than just allowing for
additional texture coordinate mappings which would be easy to add in
both scenarios.
> No problems were found regarding backwards compatibility in either approach, existing X3D3 content Will Just Work.
>
> Both approaches are functionally equivalent. Some variations in editor/browser work are necessary to implement, but everything is do-able.
The mapping approach has the big advantage that it is already
implemented in castle engine.
> We all agreed (drum roll please...) that *the "mapping" approach is the best way forward* for X3D4.
>
> Since this is an endorsement of WD2, and since all comments to date have been reviewed: consensus is achieved. So say we all! 8)
This is good news. Sounds like earlier objections were (largely?) withdrawn.
> TODO
> - need to better (more strictly) define relationships in X3D4 draft spec,
> - need to check "edge cases" and soft-fail default conditions in each case of potentially missing content,
> - emphasis on checking consistent matching and validation of content needed (Don will work on that),
> - interesting compatibility with glTF attribute "TEXCOORD_1" technique lets import and conversions of glTF-to-X3D4 be relatively simple.
I guess that question for implementers is then if these TODOs are
expected to lead to changes in signatures (and functionality) in the
current draft ?
I think x3dom may only support two sets of texCoords once this gets
implemented, eg. two possible names for the mapping (perhaps just
"TEXCOORD_0" and "TEXCOORD_1" will be supported as names first).
Actually, the spec. should probably spell out the minimum number of
texCoord sets a browser needs to support to be compliant (currently,
the number is "as many as possible"). Perhaps the number should be 2
as in glTF.
The existing PhysicalMaterial in x3dom may be renamed to GltfMaterial.
Not sure if it will be easier to implement Physical Material from
scratch or to try to map it to GltfMaterial.
Cheers,
-Andreas
> b. identify next changes to X3D4 spec.
>
> Noted necessary improvements already posted, we will meet 09-100 pacific on Tuesday to apply to specification.
>
> c. identify remaining technical design and implementation issues, if any.
>
> We will look closely at everything Andreas has posted to make sure that no feasible refinements are overlooked.
>
> No gaps noted. Onward we go!
>
> ---
>
> 4. TwoSidedMaterial and X3DOneSidedMaterial node.
>
> "Bonus round" discussion: what are the long-term implications of deprecating (and eventually removing) TwoSidedMaterial?
>
> In this context, we reviewed prior suggestion to explicitly define handling of TwoSidedMaterial to avoid need for changing the interface hierarchy:
>
> [4.0] [x3d-public] TwoSidedMaterial and X3DOneSidedMaterial
> https://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013605.html
>
> ================================================================
> Example cases for front, back, two-sided materials:
>
> a. Appearance
> material Material # active (simplest case)
> backMaterial NULL # default material values
>
> b. Appearance
> material Material # active (common case)
> backMaterial Material # active
>
> c. Appearance
> material NULL # default material values
> backMaterial Material # active
>
> d. Appearance
> material NULL # default material values
> backMaterial NULL # default material values
>
> e. Appearance
> material TwoSidedMaterial # all fields active
> backMaterial NULL # (values obtained from TwoSidedMaterial)
>
> f. Appearance
> material TwoSidedMaterial # only front fields active
> backMaterial Material # active
>
> g. Appearance
> material Material # active
> backMaterial TwoSidedMaterial # only back fields active for backMaterial
>
> h. Appearance
> material TwoSidedMaterial # only front fields active for front
> backMaterial TwoSidedMaterial # only back fields active for backMaterial
>
> i. Appearance
> material NULL # default material values for front
> backMaterial TwoSidedMaterial # back fields active for backMaterial
>
> ================================================================
>
> (includes minor indexing correction from prior table)
>
> Some of the preceding cases might well be simplified: for example, cases (g) (h) and (i) might simply be forbidden.
>
> In essence, we would simply be defining how TwoSidedMaterial acts as a single-sided texture when used as such.
>
> For PBR usage (X3D4 Material, PhysicalMaterial etc.) TwoSidedMaterial simply doesn't work.
>
> Of interest is that since TwoSidedMaterial is part of X3D3, some form of support might always be need in future version of X3D since they will want to be able to load X3D3 models. So removing a "deprecated" node might be possible in X3D4.1 but browsers will still need to support it's possible presence somehow.
>
> Given such a reconciliation, maybe we wouldn't need X3DSingleSidedMaterial and wouldn't needed to deprecate TwoSidedMaterial? Why does a browser need to change if version 4.1 (removal of a deprecated node and removal of added abstract type) would just try to take us back to the same place as X3D3?
>
> Footnote considerations:
> - Of note is the only other X3D node to ever be deprecated, GeoOrigin, ended up as un-deprecated anyway.
> - Keeping TwoSidedMaterial deprecated certainly discourages usage (which is a primary goal) and retain X3DOneSidedMaterial.
> - KISS principle is helpful: Keep It Simple Smartypants!
>
> Presented as food for thought while we lock down the entire Appearance/X3DMaterialNode design for X3D4.
>
> ---
>
> Wow what a marathon session - and totally productive. Thank you Michalis and Dick.
>
> Have fun with X3D4 Physically Based Rendering! 8)
>
> 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
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 138, Issue 77
> *******************************************
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list