[x3d-public] X3Dv4 specification structure discussion regarding glTF, advanced lighting, PBR

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Tue Oct 29 10:26:44 PDT 2019


Attendees: Michalis Kamburelis, Dick Puk, Don Brutzman.

---

1. *X3Dv4 Components*  Brief discussions on specification structure of expected changes.

a. Physically Based Rendering (PBR) in ways that match glTF rendering.
    12 Shape component
    PhysicalMaterial alongside Material and TwoSidedMaterial

    18  Texturing component likely needs modifications
    MultiTexture needs special consideration, several difficulties in rendering interactions appear to arise.

    33  Texturing3D component - likely no functional change.
    34  Cube map environmental texturing component - likely no functional change.

b. Corresponding advanced lighting model.

    17 Lighting Component
    need 2 lighting models

    need EnvironmentLight for image-based lighting

    need to specify concurrent use of original and improved lighting models for various objects in same scene.

    24 Environmental effects component (Background Fog TextureBackground etc.) probably no changes

    need to ensure that all glTF parameters are included, also defining expected defaults (for consistent rendering everywhere).

c. glTF model loading
   implement X3DUrlObject
   likely in 9 Networking component, though ExternalShape might go in 12 Shape component

---

d. Recent discussion on greyscale versus RGB interactions of material and texture properties is separate discussion (progressing well, nearly resolved) and does not affect the advanced rendering considerations here.  No confounding issues.

https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent

---

2. *Shape conversions and representations*

a. Conversion of glTF models compatibly to X3D structures: looking for good mappings between glTF and X3D structures.  Likely recommended/example, not strict requirements.

b. Are IMPORT/EXPORT statements possible for connecting events into a model?  These would require some correspondences to be exact
- for example transform translation and rotation.
- ID/DEF name mappings and potential links to unnamed nodes inside a glTF mode, if allowed

---

4. *Additional issues and considerations*

a. Might X3Dv4 combine Material and TwoSidedMaterial into a single Material node?  One is superset of the other so proper handling and compatibility can be adequately defined.  Something to think about, several use cases to consider, adding an SFBool twoSided might work.  Debatable whether identical functionality is best addressed this way... we should probably create a Mantis issue to document discussion and resolution.

b. meanwhile: Michalis is considering GenericTwoSidedMaterial
https://github.com/michaliskambi/x3d-tests/wiki/Specification-changes,-to-include-PBR-and-related-features#new-generictwosidedmaterial

Wondering if merging Material/TwoSidedMaterial might have similar motivations to GenericTwoSidedMaterial?  Interesting possibilities.

c. Further possibilities: X3DOneSidedMaterialNode and X3DSingleTextureNode
https://github.com/michaliskambi/x3d-tests/wiki/Specification-changes,-to-include-PBR-and-related-features#new-prose-in-the-texturing-component-choosing-texture-coordinates--transformations-how-the-xxxtexturechannel-works

d. Discussed how some component names are not accurate descriptions of their purpose.

11 Rendering:  discusses polygonal geometry
13 Geometry3D: discusses tessellated geometry
12 Shape:      discusses rendering and presentation

Cats/dogs:  Quad nodes now seem a better fit with other 13 Geometry3D nodes, rather than CAD component

Renaming components should only be done with great care in order to avoid confusion.  Coming up with completely different (more descriptive) names for same numbered components might add clarity without introducing confounding concepts... might remain confusing nevertheless, especially from historical usage in VRML, GL, X3Dv3, etc.  We should consider tradeoffs with care.

---

5. *Next steps*

Our next goals are to organize the proposed changes in ways that fold into and improve the emerging X3Dv4 Architecture Specification.  Today's structural discussion helped.  These changes have fundamental importance for everyone.

We will continue to increase emphasis on entering and improving Mantis issues.  Several points in this email deserve integration.

Michalis will continue working on next draft of suggested specification prose.  He will create a pull request that we can review independently so that full "due diligence" occurs before integrating into the primary draft.

Next specification editors meeting on this topic: tentatively scheduled for 11 NOV 09-1030 Pacific.

All feedback remains welcome.  Thanks for considering X3Dv4 possibilities!  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