[x3d-public] X3D minutes 5 June 2020: Web3D 2020 papers deadline, mantis issues, refining some field names
Don Brutzman
brutzman at nps.edu
Fri Jun 5 11:33:26 PDT 2020
Call planned this week will be in the new Web3D Zoom room.
Attendees: Anita Havele, Vince Marchetti, Nicholas Polys, Dick Puk, Don Brutzman.
Confirmed: no member-only information is included in these minutes.
[1] Web3D Teleconference Information
https://www.web3d.org/member/teleconference-information
> Please use the following link for all Web3D Consortium Meetings.
>
> Join URL: https://us02web.zoom.us/j/81634670698?pwd=a1VPeU5tN01rc21Oa3hScUlHK0Rxdz09
>
> Meeting ID: 816 3467 0698 Meeting Password: 483805
>
> One tap mobile
>
> US (New York) +1 929 205 6099,,(nine-digit number from Join URL above)#
> US (San Jose) +1 669 900 6833,,(nine-digit number from Join URL above)#
Topics follow.
-----
1. Web3D 2020 Conference forecast.
Web3D 2020, The 25th International Conference on 3D Web Technology
9-13 November 2020, Virtual Conference, "3D for a Hyperconnected World"
https://2020.web3dconference.org
Papers and proposals due *5 July 2020* - real soon now, get hot!!
-----
2. X3D4 draft specification publication: request all active input efforts are complete this month.
a. We last published an X3D4 public draft one year ago, in support of SIGGRAPH 2019.
X3Dv4 Draft Specification available to public now!
Release reviewed satisfactorily by X3D Working Group, 19 July 2019.
https://www.web3d.org/news-story/x3dv4-draft-specification-available-public-now
Web3D at SIGGRAPH 2019
https://www.web3d.org/event/siggraph-2019
b. We are now nearing the planned milestone for public release, again prior to (virtual) SIGGRAPH 2020.
SIGGRAPH 2020
https://s2020.siggraph.org
https://s2020.siggraph.org/attend/health-and-safety
X3D Version 4 Overview
https://www.web3d.org/x3d4
c. All contributors are asked to have their inputs complete and reflected in the spec.
https://github.com/Web3DConsortium (public)
https://github.com/Web3DConsortium/X3D (working group, member only)
Mantis Issue tracker: View Issues
https://www.web3d.org/member-only/mantis/view_all_bug_page.php
As specification editors, Dick and I request that everything be sorted out and complete this month *deadline 30 June* no really! That will enable us to confirm readiness for publication, so that X3D Working Group can recommend draft publication to Web3D Board of Directors.
-----
3. Mantis issues
As discussed in several email threads on x3d-public, we will be reviewing and resolving multiple issues today.
[2.0] Mantis Issue Tracker
https://www.web3d.org/member-only/mantis/my_view_page.php
Today's added discussion at
https://www.web3d.org/member-only/mantis/view.php?id=1280#c2587
[2.1] Mantis 1280: Add quality parameter for Geometry3D primitives
https://www.web3d.org/member-only/mantis/view.php?id=1280
> If we go general, can we effectively encourage satisfactory engine implementation?
>
> Defining tessellation parameters (e.g. 24 24 indicates 24 divisions laterally and vertically) gives knowledgeable authors some control - but only when displaying base cases.
>
> Handling silhouettes and shading without roughness artifacts leads to mathematical representations, at any resolution and any proximity.
>
> There is no requirement for mesh implementation, for example parametric surfaces are allowed.
>
> If a Sphere is accompanied by a TouchSensor, for another example, the author is expecting the selection point to be a sufficiently close approximation to the geometry's surface, not necessarily a point on the initially computed tessellation (which may have been far away at low resolution). Once again this leads us towards appropriate refinement for the rendering, and mathematical representation of the primitive.
>
> If we go for mathematical representations, no further improvements will be needed to X3D specification (perhaps forever) when such artifacts are found in future scenes.
>
> We agreed to add no quality parameter, and encourage each implement to consider how the present best-quality geometric rendering in all cases.
>
> Suggested specification prose:
> "This geometry node is fundamentally a mathematical representation. Displayed geometry shall have sufficient rendering quality that surface and silhouette edges appear smooth, including when textures are applied."
Accepted. Dick and Don will apply changes, then change status to Resolved.
---
[2.2] Mantis 1304: allowing animation of Cone, Cylinder bottom/side/top
https://www.web3d.org/member-only/mantis/view.php?id=1304
Discussion:
> The initializeOnly accessType might be considered a vestige of early rendering difficulty.
>
> This parameter variability is commonly implemented in modern rendering engines.
Accepted.
[2.3] Mantis 1264: NavigationInfo type TURNTABLE HELICOPTER GAME FREEFLY
https://www.web3d.org/member-only/mantis/view.php?id=1264
We discussed how these issues are being considered in Web3DUX Working Group. It looks like most or all have potential value for the specification and X3D authors.
An added possibility is that certain modes might be considered optional, lowering barriers to compliance.
A survey of these types and general support for all NavigationInfo type support is appropriate.
Noted related issue:
[2.4] Mantis 1301: check geospatial navigation to see if NavigationInfo modes are sufficient
https://www.web3d.org/member-only/mantis/view.php?id=1301
> Geospatial navigation is special in that it has to work in proximity to the surface of the Earth, at high altitudes, and in outer space.
>
> Further consideration is definitely needed for how geospatial navigation types are consistent - or consistently extending - other NavigationInfo type definitions. Related issues identified.
> Looking at and comparing how Cesium and Google Earth handle these cases is appropriate.
Wishing best of success to Web3DUX Working Group in continuing efforts.
-----
[2.5] Mantis 1194: 23.4.4 NavigationInfo - VIEWALL should be a required navigation behaviour
https://www.web3d.org/member-only/mantis/view.php?id=1194
> 16
> VIEWALL is curious in comparison to other navigation modes in that it is a one-time action.
>
> Perhaps this functionality is more appropriate as part of Viewpoint?
>
> Perhaps this functionality is best implemented as a builtin Viewpoint, similar to default Viewpoint (at position 0 0 10). How might an author bind and unbind this?
>
> Perhaps there might be a ViewAll node, which an author can bind via Browser object or similar mechanisms. Perhaps even multiple nodes:
> <ViewAll description="North side of island"/>
> <ViewAll description="South side of island"/>
Note that we would need this capability in OrthoViewpoint as well.
From 3.3 spec:
23.4.6 Viewpoint
Viewpoint : X3DViewpointNode {
SFBool [in] set_bind
SFVec3f [in,out] centerOfRotation 0 0 0 (-∞,∞)
SFString [in,out] description ""
SFFloat [in,out] fieldOfView π/4 (0,π)
SFBool [in,out] jump TRUE
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-∞,∞)
SFVec3f [in,out] position 0 0 10 (-∞,∞)
SFBool [in,out] retainUserOffsets FALSE
SFTime [out] bindTime
SFBool [out] isBound
}
Possible addition:
SFString [in,out] scope "" [as defined, or "VIEWALL"]
Functionality is to zoom position back/in towards center of world's bounding box until everything is within display bounds.
What about:
SFBool [in out] viewAll FALSE
Same functionality to zoom position back/in. For non-orthographic Viewpoint, orientation changes to point at center of scene; OrthoViewpoint orientation remains unchanged. Other fields remain the same.
----
Nicholas described the great and numerous difficulties that arise from Viewpoint and NavigationInfo being separate. A major long-term challenge is whether we might unify this functionality.
Note that the two nodes can be tied together as follows:
<Viewpoint DEF="view23" description="A beautiful spinning sneaker"/>
<NavigationInfo DEF="nav23" type='"EXAMINE"'/>
<ROUTE fromNode="view23" toNode="nav23" fromField="isBound" toField="set_bind"/>
Perhaps there is a syntactically way to say in a functionally equivalent way
<Viewpoint DEF="view23" description="A beautiful spinning sneaker">
<NavigationInfo DEF="nav23" type='"EXAMINE"' containerField='navigation'/>
</ViewPoint>
and also
<Viewpoint DEF="view24" description="An unfashionable untied sneaker">
<NavigationInfo USE="nav23"/>
</ViewPoint>
... which provides unambiguous unchangeable navigation fields for this viewpoint.
Note that binding + unbinding a Viewpoint equivalently binds/unbinds the associated NavigationInfo, reverting simultaneously to previous Viewpoint and also previous NavigationInfo.
Another approach, more programmatically,
Browser.getBoundViewpoint.whatever
Browser.getBoundNavigationInfo.whatever
TODO: search for prior Mantis issue, also Nicholas write it up please.
-----
[2.5] Mantis 904: ShaderPart, ShaderProgram: incorrect value list for type field
https://www.web3d.org/member-only/mantis/view.php?id=904
Deferred.
-----
5. Refamiliarization discussion: will soon retackle the following issues, driving towards closure on potential field-name changes for X3DUOM in X3D4.
Any red flags or suggestions/precautions are worth considering. We aim to improve X3D4 internal consistency.
=============================================================================
[3.0] X3D Scene Authoring Hints: Potential future changes for improved consistency of field names
https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
Ongoing work for X3D Version 4 and X3D Unified Object Model (X3DUOM) makes a number of candidate optimizations possible and (in most cases) desirable. Consistent X3D scene-graph architecture across multiple file encodings and programming-language bindings is important.
The following consistency changes to SFNode/MFNode field names in X3Dv4 might reduce the number of containerField variations by more than half. Further simplification benefits are foreseen for X3D4 implementations, X3D authors, and X3D Ontology field disambiguation.
a. CADFace issue Mantis 1234 to change unnecessarily different containerField='shape' and rename as containerField='children' instead.
b. Collision: content model definitions for contained nodes are insufficiently strict. See issue Mantis 1149.
c. DISEntityTypeMapping: enter Mantis issue to change unnecessarily different containerField='mapping' and rename as containerField='children' instead.
d. CollidableShape: enter Mantis issue to change unnecessarily different field name containerField='shape' and rename as containerField='children' instead.
e. ComposedCubeMapTexture, TextureBackground: enter Mantis issue to make six sets of field names identical for contained textures, e.g. backTexture becomes back etc.
f. GeoLOD: see issue Mantis 920 to change unnecessarily different field name containerField='rootNode' and rename as containerField='children' instead. Also enter Mantis issue to implement object interface X3DUrlObject.
g. GeoMetadata: enter Mantis issue to implement object interface X3DUrlObject.
h. LoadSensor: enter Mantis issue to change unnecessarily different field name containerField='watchList' and rename as containerField='children' instead. Child node restrictions can achieve a functionally equivalent effect and improve the object-oriented design.
i. ParticleSystem: enter Mantis issue to change unnecessarily different field names colorRamp, texCoordRamp and rename as regular defaults color, texCoord instead. Also allow TextureCoordinateGenerator as an alternative to TextureCoordinate for that child node.
j. Nodes in the Programmable shader component all field names deserve a further close look. While everything works correctly, node naming is confusing and clarity is certainly improvable.
These changes will be considered by Web3D Consortium members with subsequent review by the X3D Community. Companies, institutions, agencies and individuals are invited to Join Web3D Consortium to participate and influence this important continuing evolution of X3D.
=============================================================================
TODO: link past X3D Working Group minutes on this topic. Tradeoff is extra-descriptive naming versus consistent naming - not any changes in functionality.
Backwards compatibility remains an important concern to ensure that we don't break existing content. Some changes (for relatively rare occurrences) will be listed when converting X3D3 content (or implementations) to X3D4. So all naming refinements need to be well documented for authors, implementers, content and tools.
Subject to ongoing discussion, I expect to begin applying changes to X3D Schema/DTD/X3DUOM on an issue-by-issue bases for further testing. You've been warned... 8)
Thanks in advance for all insights and help.
-----
The topics may have seemed obscure, but we accomplished some fundamentally valuable progress together.
I have a few TODO items to confirm close correlation and good consistency between minutes, email record and Mantis issues.
Next week: glTF and Physically Based Rendering update by Michalis Kamburelis, hopefully recording and publishing this briefing.
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