[x3d-public] X3D Working Group minutes 28 OCT 2019: X3Dv4 issues review, editor comments

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Wed Oct 23 16:57:19 PDT 2019


Minutes of specification editors call today, Dick Puk and myself.  Several improvements following last week's working-group call.

On 10/18/2019 10:03 AM, Brutzman, Donald (Don) (CIV) wrote:
> [...]
> 
> Recent minutes:
> 
> [1] [x3d-public] X3D minutes 11 OCT 2019: Web3DUX, semantics progress, implementations status, mantis issues, texture/material, X3D-Edit
>          http://web3d.org/pipermail/x3d-public_web3d.org/2019-October/011347.html
> 
> [2] [x3d-public] X3D minutes 4 OCT 2019: X3D-glTF review, defer Annotations, Layout component, #X3Dv4 implementations/issues update
>          http://web3d.org/pipermail/x3d-public_web3d.org/2019-October/011315.html
> 
> ==================================
> 
> 2. *Carryover issue: material, textures, lighting*>
>> a. Good discussion on interplay between materials and textures is occurring on both the X3DOM and X_ITE mailing lists.  [...]
>>
>> * X3DOM conversation
>>     https://github.com/x3dom/x3dom/issues/993
>>
>> * X_ITE conversation
>>     https://github.com/create3000/x_ite/issues/50
> 
> Is this driving to closure satisfactorily? Are precise changes expected for X3Dv4?
> 
> The X3D Architecture Specification must have consistent rendering well defined.  This is critical path forward, the X3D Working Group will refine or amend the X3Dv4 specification as needed to ensure consistent results.  This is a primary feature of X3D, especially for archival publication and sharing of models.
> 
> Getting X3D Appearance of materials and texture unambiguously defined and consistently implemented is very important, especially in preparation for addition of Physically Based Rendering (PBR) and correspondingly advanced lighting model to X3Dv4.

Hi *Michalis* are you ready for an editing session together?  Hope so...

(We sent a tentative invite for next Tuesday 0900 Pacific but can adjust to fit your schedule)

> ==================================
> 
> 3. *Carryover issue: features and nodes*>
>> b. X3DOM and X_ITE have added some navigation types and other special features.  Some features will also be part of SAI, for example getting screen-space coordinates.  We need to expose these inside any X3D model so that authors work to best effect with HTML5.  These need to be considered and proposed publicly to get on the X3D Working Group agenda prior to 16 DEC 2019.
>>
>> The community has to live with the results... the community should *Step Up to Help* !!  This is a real opportunity for authors and implementers to speak out, helping to elevate important new candidate capabilities.
> 
> Nobody has stepped up yet.  Navigation types and other geometry nodes sure seem like low-hanging fruit.
> 
> Seems like a real opportunity for someone to unlock major latent improvements for future authors and users.
> 
> Am willing to spend meeting time to review once a suggestion list has been posted publicly
We entered a placeholder issue for TURNTABLE and will add detail from mailing list discussions.

Mantis 1264: NavigationInfo type TURNTABLE
https://www.web3d.org/member-only/mantis/view.php?id=1264

23.4.4 NavigationInfo
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#NavigationInfo

> ==================================
> 
> 4. *X3Dv4 Issues Review*
> 
> We will go though the Mantis issues tracker to assign tags to issues that need to be tracked as part of X3Dv4 efforts.
> 
> [3] Mantis Issue Tracker (requires 2 sets of member login)
>        https://www.web3d.org/member-only/mantis/view_all_bug_page.php
> 
> [4] X3D Version 4 Overview
>        https://www.web3d.org/x3dv4>
> [5] X3Dv4 Highlights
>        http://www.web3d.org/x3dv4-highlights
> 
> [6] X3Dv4 Implementations Status
>        http://www.web3d.org/x3dv4-implementations

added row there for Navigation
> Mantis issues:  performed triage, made some changes.
> 
> You can now quickly see all X3Dv4 issues (with tag V4.0) by selecting the filter "X3Dv4" within mantis.  Screenshot attached.
> 
> Here is the current list.  What is missing?  CSV output attached.  No doubt some more issues also need to be marked.
> 
> --------------------------
> Id	  	Summary
> 407	  	37.4.11 RigidBodyCollection -- Missing Definition
> 744	  	9.4.2 Inline - Security precaution
> 920	  	25.3.4 GeoLOD - child nodes require containerField='rootNode' which is uncommon

We discussed whether normalization of field names (e.g. all "children" as "children") might simply require that synonyms be honored.  This applies to perhaps 15 cases... Requiring synonym support is unusual for us, but interesting because it maximizes forwards/backwards compatibility among X3D versions. Validation might not always work, but rendering could.

(Will work on more words to follow, putting them in the mantis issue.)

> 1092	  	7 Core component - MetadataSet or Metadata* node(s) as root nodes
> 1103	  	5.3.15 SFTime and MFTime - Describe two usages

issue renamed for clarity: 5.3.15 SFTime and MFTime - Describe two usages, absolute time and duration period

> 1149	  	23.4.2 Collision - Child content insufficiently strict

Likely solution: [X3DGroupingNode | Shape]

... along with prose that "If an X3DGroupingNode is provided, it must contain one or more Shape nodes with geometry."

Conceptually could also allow simple geometry (Box etc.) but that appears to be problematic, especially for proper validation... so no to that.

VRML97 is instructive:
======================
https://www.web3d.org/documents/specifications/14772/V2.0/part1/nodesRef.html#Collision
6.8 Collision
"The collision proxy, defined in the proxy field, is any legal children node as described in 4.6.5, Grouping and children nodes, that is used as a substitute for the Collision node's children during collision detection. The proxy is used strictly for collision detection; it is not drawn."
======================

Note how VRML allowed children nodes... which led to our omitting grouping nodes when crafting X3D, since grouping nodes are also children nodes.  That was an error, since many children nodes have nothing to do with geometry.  So the [X3DGroupingNode | Shape] solution above appears best.

Any objections or improvements?

> 1151	  	9.4.2 Inline - Inline is silent about head, component, unit, and meta statements
> 1234	  	CADFace field 'shape' has unusual name and causes unnecessary complexity, similar for CollidableShape
> 1242	  	3D texture formats listed in wrong location
> 1252	  	PointProperties node specification
> 1255	  	Projective Texture Mapping Component (PTM)
> 1257	  	Inline allowed to load additional model types
> 1258	  	Layout component needs to be consistently implemented
> 1259	  	Scanning profile needed?
> 1260	  	use of custom elements (x3d- prefix) for X3Dv4 in HTML5
> 1261	  	PointSet field for Normal node
> 1262	  	new field /refresh/ for Inline, ImageTexture etc.
> 1263	  	Logger capability
> --------------------------
> 
> *Please let us know if your key issue is not present!*

December 16 approacheth... have fun with X3D!  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