[x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis issues review, ballot deadlines, X3D Application Stack Layer Examples diagram

Fri Sep 23 17:23:38 PDT 2022

Consider:   SVG is a manipulation language for inserting 2D graphics into a
scene.   Definition languages are more closely related to schemas, or
possibly for manipulating schema.  After insertion into a scene, ECMAscript
is typically used for manipulation.   ROUTEs should be allowed to as well.
SVGs should be considered animations with popular packages being D3.js.

Otherwise,  SVG is a declarative language, similar to X3D and HTML.   Last
I heard, there was no official schema for SVG.

If the SVG is animated by ECMAscript, wouldn’t it more properly be used to
texture surfaces and volumes with a MovieTexture?  Are MovieTextures 2D or
3D?   What textures are used for VolumeRendering?

On Fri, Sep 23, 2022 at 1:44 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Attendees: Dick Puk, Don Brutzman
>
>
>
>
>
> 1. We first reviewed the two recently posted Mantis issues regarding SVG
> and QIF.  We also looked at a Mantis issue posted earlier this year
> relating to scalable composition of really large X3D worlds.  Selected
> details follow.
>
>
>
>    1. Mantis 1400: add Scalable Vector Graphics (SVG) to recommended
>    image formats for ImageTexture
>
> https://www.web3d.org/member-only/mantis/view.php?id=1400
>
>
>
> SVG references:
>
> * https://www.w3.org/Graphics/SVG
> * "SVG is a markup language for describing two-dimensional graphics
> applications and images, and a set of related graphics script interfaces."
>
> Dick estimation: thinks SVG is a 2D scene-graph definition language. It
> can result as an image, though so can X3D.
>
> This issue suggests that SVG be listed as a recommended (optional) format
> that can be rendered as an ImageTexture, using the default presentation
> settings of the SVG model.
>
> Of note is that browsers are not forbidden from implementing SVG as an
> ImageTexture format, and also that SVG-to-PNG converters are commonplace.
>
> Of further note is that the DPS minutes already showed a use case for SVG
> as ImageTexture, namely conversion of metadata information as a carefully
> laid-out annotation image that is billboarded in context. Having direct SVG
> rendering would eliminate the offscreen conversion step, permitting direct
> integration of X3D models with other HTML/SVG web graphics.
>
> Concern: don't want to overcomplicate the existing ImageTexture
> functionality as a 2D array of pixels. Once generation of pixels becomes a
> computational process, this is different functionality for the ImageTexture
> node. This might raise further concerns about impact of ImageTexture
> computational complexity in various profiles (such as Interchange Profile).
>
> Possible alternate: define SvgTexture node? What fields would it have?
>
> Suggested possible resolution:
>
> a. Browsers are welcome to implement ImageTexture as an allowed url format
> if they see fit,
> b. SvgTexture ought to be designed and considered as a possible new node,
> c. ComposedImageTexture (or somesuch) might be designed and considered as
> an even-more general possibility for comuputational 2D imagery,
> d. Following further practical experience, defer any specification-change
> recommendations to future X3D4.1.
>
>
>
>
>
>    1. Mantis 1401: aligning X3D4 LineProperties with Quality Information
>    Framework (QIF) specification
>
> https://www.web3d.org/member-only/mantis/view.php?id=1401
>
>
>
> Suggested resolution:
>
> a. The concepts are directly aligned and overlapping, with some additions
> by QIF.
> b. This ISO standard does not appear to have been considered by SC24 or
> JTC1.
> c. Close scrutiny of both terms and definitions needs to be performed
> before any changes might be recommended.
> d. If changes are indeed warranted and acceptable, then they likely need
> to first considered as part of the Registry of Items, specifically entries
> for linestyle and hatchstyle.
> e. At that point, amendment of X3D to stay aligned with Registry of Items
> (or possibly add further styles independently) can be considered.
> f. Defer to X3D 4.1.
>
> Meanwhile note in Web3D current ballot comments the need to fix the table
> erratum previously noted.
>
>
>
>
>
>    1. Mantis 1192: 07.2.2 Bindable children nodes - Undefined results if
>    bindable node is under Switch or LOD is problematic
>
> https://www.web3d.org/member-only/mantis/view.php?id=1192#bugnotes
>
>
>
> Comment on 19775-1: Abstract X3D Definitions - V3.3
> 7.2.2 Bindable children nodes
>
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#BindableChildrenNodes
>
> -----------------
> Subject: Undefined results if bindable node is under Switch or LOD is
> problematic
>
> Spec sayeth:
> "The results are undefined if a bindable node is bound and is the child of
> an LOD, Switch, or any node or prototype that disables its children."
>
> This leads to all manner of inconsistent problems among scenes. It also
> means that Inline node (which may or may not include bindable nodes) has
> undefined behavior under LOD/Switch/etc.
>
> As a result, in addition to indeterminate X3D browser behavior, it means
> that X3D scenes are not fully composable. That is contrary to X3D design
> objectives.
>
> Different prose and deterministic guidelines is needed in this section
> that provides clear rules for binding/unbinding nodes when they become
> active within LOD/Switch/etc. Small adaptations to current binding rules
> can likely address this problem satisfactorily.
>
> Related: Mantis issue 749
>
>
>
> April 29:
>
> Analysis during X3D Working Group call:
>
> a. Switch would keep each binding stack aligned with whichever child was
> active, thereby binding and unbinding nodes whenever the Switch level is
> modified.
>
> b. LOD would have all of its child bindable nodes on the binding stack
> throughout, so that user experience was consistent. For example, it would
> make no sense for Viewpoints to get arbitrarily unbound and bound, based on
> range to viewer, as a user independently navigated through a scene.
>
> c. LOD attempting to maintain author intent has access to all Viewpoint
> nodes on binding stack, and range-to-viewer LOD transitions are either
> flexible suggestions (browser-optimization control) or rigidly enforced
> (forceTransitions field is TRUE). Thus if a node is subsequently bound by
> user in a different inactive LOD child branch, then that binding event is
> honored and that LOD child branch becomes the active child branch. This
> binding event (and changed LOD child branch selection) takes precedence
> over browser range/performance considerations, and also takes precedence
> over whatever value is provided in forceTransitions field. (Example:
> selecting a room Viewpoint while in a large building model).
>
> d. NavigationInfo, Background and Fog binding stacks and responses to
> binding events should behave identically to Viewpoint. Variations would be
> exceedingly complex and not understandable. Consistency means that author
> intent and user action always take precedence, for Switch and LOD response.
>
> Spec editors work on integrating these principles as specification prose
> (we are close already) and report back recommended changes to X3D working
> group.
>
> Don's opinion: this will significantly help user-sensible scalability of
> huge (perhaps Metaverse-scale) models using many Inline and prototype
> nodes, enabling predictable and performant navigation and traversal
> throughout.
>
>
>
> Today’s session.
>
>
>
> Alternatives deserving working-review consensus:
>
> a. Recommending this clarification of undefined prior specification prose
> might add important value, or might be construed as a technical change to
> X3D4.0 that possibly requires future re-balloting as another X3D 4.0 DIS
> (which is not an acceptable outcome).
>
> b. If not balloted then this becomes an X3D4.1 issue.
>
> c. Web3D might consider some alternative approach to strongly encourage
> adoption of this clarified approach in order to further encourage greater
> scalability of multi-world environments, and better alignment with shared
> Metaverse design imperatives. For example, are we creating a Best Practices
> Pending X3D 4.1 Approval document of some sort?
>
>
>
>
>
>
>
> 2. We only have 4 total issues to review as planned Web3D comments.  This
> will occur during a single working-group meeting, 7 OCT.
>
>
>
> Deadline for X3D Ballot comments:
>
>    - OCT, Web3D comments to INCITS (U.S. National Standards Body
>    - TBD OCT, INCITS comments to SC24
>    - 4 NOV, SC24 comments to ISO
>
>
>
> No meeting currently planned for 30 SEP.
>
>
>
> 3. Bonus round: we worked on the “layer” diagram from recent meetings a
> bit more.  Latest X3dApplicationStackLayerExamples is attached, all
> comments welcome.
>
>
>
> Have fun with X3D!
>
>
>
> 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 https://
> faculty.nps.edu/brutzman
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220923/a249085d/attachment-0001.html>