[x3d-public] X3D minutes 25 SEP 2020: conference, https DOCTYPE, X3D4 PBR Material textures and "mapping" field
Don Brutzman
brutzman at nps.edu
Fri Sep 25 10:53:17 PDT 2020
Attendees: Anita Havele, Michalis Kamburelis, Vince Marchetti, Dick Puk, Don Brutzman.
Agenda for today. The first two items proceeded rapidly to focus on critical-path challenge.
---
1. Conference preparations
[1] Web3D 2020 Conference
https://web3d.siggraph.org
Building out program for accepted content. Registration open: No Cost!
---
2. Change reference urls for X3D DOCTYPE, XML Schema to https
[2.1] X3D Scene Authoring Hints, Validation of X3D Scenes using DTD and XML Schema
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#Validation
[2.2] [x3d-public] X3D DOCTYPE problem; X3D Validator has workaround, necessary path forward confirmed;
fixed, upgrade path proposed
https://web3d.org/pipermail/x3d-public_web3d.org/2020-September/013622.html
URI vs. URL: XML specifications point out that these are URI label identifiers; mapping to actual URL locations is a good practice.
Both addresses work, so backwards compatibility with X3D3 XML encoding and default content is supported.
As before: any objections? None noted.
We will now apply the change across the Web3D suite of tools and examples, hopefully report test results next week.
Thanks once again to Vince for diagnosis and correction of recent server problem, that today led to this improvement.
---
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).
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.
- 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).
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.
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)
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.
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
More information about the x3d-public
mailing list