[x3d-public] X3D minutes 5 June 2020: Web3D 2020 papers deadline, mantis issues, refining some field names
Don Brutzman
brutzman at nps.edu
Sat Jun 6 16:36:54 PDT 2020
Here some decision followup actions, making continued progress.
On 6/5/2020 11:33 AM, Don Brutzman wrote:
> [...]
> -----
>
> 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.
Renamed issue to "Define rendering quality for Geometry3D primitives" for clarity.
Applied prose and style changes to specification, committed to github.
Dick and I will review during next week's editors meeting and likely accept it then.
Meanwhile John C., you added a comment there which is out of place since the issue only relates to Cone Cylinder Sphere. Here it is - if you think it belongs elsewhere then let's figure that out and apply to another issue, if relevant.
"You may want to say something about the mesh being modified in the vertex shader, which is what I am doing. Instead of restricting to a radius, allow the shader to modify position and normal. Or just go with a mathematical expression is OK with me, as long as I can achieve sufficient quality."
In general we are very sparing in use of Mantis, only reflecting distillation of mail list discussions. That way spec editors have a clear record of issues and resolution. Thanks, but... mail list is best place to work out pros/cons/alternatives. We do everything openly in order to work towards consensus.
> ---
>
> [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.
Applied change to X3D XML schema, DOCTYPE, X3DUOM, tooltips, etc.
Applied change to github specification.
Updated Mantis.
> [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.
Interesting, we hadn't thought of this before. Wondering though, does that add value to authors from a component perspective, however? There are always variations in support among implementations. Current Navigation component says
* Table 23.2 — Navigation component support levels
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#t-supportlevels
Level 1 - NavigationInfo: type support for at least "ANY", "FLY", "EXAMINE", and "NONE".
Level 2 - NavigationInfo: type support for at least "ANY", "FLY", "EXAMINE", "WALK", "LOOKAT", and "NONE".
Level 3 - All Level 2 Navigation nodes: All fields fully supported.
So it looks like any optional characteristics are already handled pretty well already. Thus don't expect to designate any navigation types as optional.
> 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?
_that_ was the crucial insight and understanding of the problem, which emerged thanks to group dialog. hooray!
>> 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.
Am really liking the SFBool viewAll field as the simplest and most comprehensive solution we have considered to date. It can meet all functional requirements. It exactly fits into existing X3DViewpointNode requirements without requiring complex changes in implementations.
The mantis issue already describes the algorithm. Am ready to add prose to specification...
Proposal added to Mantis 1194:
SFBool [in out] viewAll FALSE
"When viewAll is set TRUE or a viewpoint is bound with viewAll TRUE, the current view is modified to change centerOfRotation to match center of bounding box for entire visible scene, change orientation to aim at that point, change type to EXAMINE, and then zooms position in or out until the scene is fully within the current viewing window. Changing navigation type resets viewAll to FALSE."
Subject to confirmation/denial, am ready to add to specification and validation assets.
> ----
>
> 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.
Still makes sense. Implementable today via single ROUTE as shown above - thus easily implemented by X3D players. This design-pattern relationship becomes even more reliable/unbreakable by associating NavigationInfo with a Viewpoint as an SFNode field.
Proposed specification addition:
23.3.1 X3DViewpointNode
23.4.5 OrthoViewpoint
23.4.6 Viewpoint
SFNode [in,out] navigation NULL [NavigationInfo]
"The navigation field defines a dedicated NavigationInfo node for this X3DViewpointNode which remains independent of the NavigationInfo binding stack."
Entered as new issue
* Mantis 1305: add Viewpoint field for dedicated NavigationInfo
https://www.web3d.org/member-only/mantis/view.php?id=1305
Subject to confirmation/denial, am ready to add to specification and validation assets.
> Another approach, more programmatically,
>
> Browser.getBoundViewpoint.whatever
> Browser.getBoundNavigationInfo.whatever
>
> TODO: search for prior Mantis issue, also Nicholas write it up please.
Not finding Mantis issue. Ready to add once written up. These two approaches together hold major promise for simplifying navigation designs by authors.
> -----
>
> [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.
Stand by for action, will tackle all of these this month as part of X3DUOM normalization.
Please holler if you have any objections, warnings or concerns.
> 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.
Didn't find specific minutes on this topic in 2020, believe it actually came up several times in context of XML containerField (i.e. field) names.
* [x3d-public] X3D minutes 6 MAR 2020: X3D4 special meeting on PBR, issue progress,
Metadata containerFIeld defaults for XML encoding
https://web3d.org/pipermail/x3d-public_web3d.org/2020-March/011863.html
* [x3d-public] X3D Working Group agenda 31 JAN 2020: X3Dv4 issues, XML Metadata containerField,
consolidating mismatched field names
https://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011744.html
* [x3d-public] X3D minutes 24 JAN 2020: X3Dv4 Interchange-profile Text, visible, displayBBox,
XML Metadata* default containerField
https://web3d.org/pipermail/x3d-public_web3d.org/2020-January/011710.html
> 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