[x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis issues review SvgTexture, X3D Application Stack

John Carlson yottzumm at gmail.com
Sat Sep 24 17:45:33 PDT 2022


Understood.  I thought i made it clear that there’s no “feedback (infinite)
loop” in X3D3 that allows behavior not unlike playing Sims 1 inside Sims 2.
  I am more trying to incorporate textures from other running applications,
similar to what Zoom, etc. do.

Ideally, one could see through a “magic mirror” or “portal” (Croquet) from
one Scene to an independent scene.   Similar to a hyperjump, but the target
scene is “live” in the source scene.  Feel free to replace scene with
virtual world.

The reason to go through a MovieTexture instead of only an Inline is for
security purposes and to stop infinite propagation, especially of audio.
There would probably be a requirement to disallow intersecting textures.

Red-pill warning.

One could consider dragging a Stargate through a Stargate.  What happens
when i have a virtual world in my inventory (an inline, for example)?

One might consider viewing XMLSpy inside the Metaverse.

I believe this kind of stuff is called “embedding” as popularized by Office.

So things like audio feedback should definitely be disallowed for X3D4.

On Sat, Sep 24, 2022 at 6:44 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Please be advised that X3D absolutely allows loading more X3D within a
> parent X3D model via the Inline node.
>
>
>
> Also worthy of note is that recursive reloading is expressly forbidden
> wherever it might occur, in order to preclude infinite loops and security
> flaws.
>
>
>
> 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
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Saturday, September 24, 2022 12:08 PM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc:* GPU Group <gpugroup at gmail.com>; X3D Public Mailing List (
> x3d-public at web3d.org) <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis
> issues review SvgTexture, X3D Application Stack
>
>
>
> NPS WARNING: *external sender* verify before acting.
>
>
>
> Agreed on most points.  SVG renders to an image or canvas, so I’m guessing
> that one can capture image frames to place in a MovieTexture.
>
>
>
> I recognized that X3D does not provide X3D in X3D.  I understand that one
> may wish to avoid feedback loops.  Many tools successfully handle them.
>
>
>
> HTML5 also avoids HTML5 in HTML5,  AFAIK.
>
>
>
> There are probably workarounds!
>
>
>
> I guess I’m just seeking a way to include external application’s windows
> (read-only) within X3D.
>
>
>
> Say a use case or user story is capturing a Java/Swing application window
> for inclusion in a MovieTexture.   I create a static movie texture in X3D.
>   I’m asking for a dynamic movie texture (live), similar to WebRTC.   Since
> the web already supports live video, i suggest someone (me or Christoph
> Valentin) look into how webapps do it.
>
>
>
> John
>
>
>
> On Sat, Sep 24, 2022 at 1:00 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> Hi Doug.  Regarding WebAssembly, I think it fits as one of many many
> technologies available to Web authors, represented in the *X3D
> Application Stack – Layers and Alternatives* diagram in the row *Programming
> Libraries, Web authoring tools and 3D translators*.
>
>
>
>    - https://webassembly.org
>    <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebassembly.org%2F&data=05%7C01%7Cbrutzman%40nps.edu%7C7b39d12b82984d1d2ad108da9e6019d9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637996432852179194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=LslKNB5PeJpKExq6%2B%2B5tbiZg%2F6xw92C1wrqGqep%2BrVw%3D&reserved=0>
>
>
>
> Hi John.  glTF is a format for 3D models, and that is why you find
> multiple ways to use glTF2 as a 3D model in the X3D Specification.  glTF
> itself is not suitable as any kind of format to provide an image texture.
>
>
>
>    1. *First: glTF models can be loaded via Inline*
>
>
>
> ·     X3D Part 1: Architecture and base components, 9 Networking
> component, 9.4.2 Inline
>
> ·
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/networking.html#Inline
>
>
>
> *The run-time system can support any number of 3D model resource types as
> long as those follow the abstract model definition (see 2.[RFC2077]),
> provide a registered content type ( e.g., model/x3d-xml, model/gltf-bin,
> model/stl, etc.), and can be determined with some form of content
> negotiation (see 2.[RFC2616]). The run-time system must support at least
> one X3D type ( e.g., model/x3d-xml) but can also support and negotiate any
> number of X3D encodings and (optionally) non-X3D representation formats.
> Support for loading glTF assets (see 2.[GLTF]) also requires support for
> Shape component level 2 and Lighting component level 4.*
>
>
>
> ·     Table 9.3 — Networking component support levels
>
> ·
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/networking.html#t-supportLevels
>
> ·     Level 5, Model support
>
>
>
> *Support for glTF models in Inline nodes, in .gltf (**model/gltf+json**)
> and .glb (**model/gltf-binary**) formats.*
>
> *Requires support for Shape component level 2 and Lighting component level
> 3.*
>
> *Minimum required glTF support:*
>
> o  *transformation hierarchy,*
>
> o  *meshes,*
>
> o  *physical materials,*
>
> o  *loading of external binary data referenced from .gltf files ( e.g.,
> for vertex coordinates).*
>
>
>
>    1. *Second: glTF2 rendering techniques are fully integrated into
>    native X3D4 lighting and rendering models, thus encouraging compatible
>    modeling and conversion of glTF models in X3D*.
>
>
>
> ·     X3D Part 1: Architecture and base components, 12 Shape component,
> 12.4.6 PhysicalMaterial
>
> ·
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/shape.html#PhysicalMaterial
>
>
>
> *The PhysicalMaterial node specifies surface material properties for
> associated geometry nodes. It indicates that a physical lighting model
> should be used for the computation. 17 Lighting component contains a
> detailed description of the X3D lighting model equations.*
>
>
>
> *Physical interpretation of the material parameters follows. These
> parameter descriptions closely follow the glTF specification (see [glTF]).*
>
>
>
> *NOTE   The physical material properties of X3D are also deliberately
> consistent with the glTF 2.0 material definition. Effectively, converting
> (in either direction) between X3D PhysicalMaterial and glTF 2.0 material
> definitions is equivalent.*
>
>
>
> ·     also 12.4.10 UnlitMaterial
>
> ·
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/components/shape.html#UnlitMaterial
>
>
>
> Also please be aware that we are not pursuing a specific design for
> SvgTexture or related new-node possibilities at this time.  Rather we are
> performing our “final final” review of X3D4 issues in Mantis.  Thaat issue
> asks whether SVG ought to be included among allowed url file types for
> ImageTexture.   Currently the rationale appears to be no, continuing
> comment welcome.  The X3D Working Group will finalize resolution of Web3D
> Consortium comments on X3D4 Draft International Standard Ballot on Friday
> October 7.
>
>
>
> ·     Mantis 1400: add Scalable Vector Graphics (SVG) to recommended
> image formats for ImageTexture
>
> ·     https://www.web3d.org/member-only/mantis/view.php?id=1400
>
>
>
> More documentation about glTF and X3D correspondences is found in recent
> spreadsheet-comparison efforts by X3D Working Group.  I have moved both of
> these documents from other locations into our central Web3D sourceforge
> repository.
>
>
>
> ·     X3D Application Stack - Layers and Alternatives
>
> ·
> https://www.web3d.org/specifications/X3dApplicationStackLayersAlternatives.png
>
>
>
> ·     Features Comparison X3D4 glTF2 spreadsheet
>
> ·     https://www.web3d.org/specifications/FeaturesComparisonX3D4glTF2.pdf
>
>
>
> and now highlighted at
>
>
>
> ·     X3D Specifications: Schema and DOCTYPE Validation
>
> ·     https://www.web3d.org/specifications
>
>
>
> Ongoing scrutiny and insights are always welcome.  Have fun building X3D
> Applications!  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 https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Saturday, September 24, 2022 8:41 AM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Subject:* Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis
> issues review, SvgTexture
>
>
>
> Perhaps we should generalize to GraphicsTexture and include glTF in the
> FULL profile, and SVG in a simpler profile.
>
>
>
> At this point, it seems like Inline would be a required child of
> GraphicsTexture, with animation, encoding and navigation options.
>
>
>
> I realize I should be checking the ticket and standard.
>
>
>
> Yes, I recognize “portals” from Squeak here.  Seeing into another scene.
> I think Anchors are okay here.   There’s no HTML5 within HTML5, so there’s
> no precedent.
>
>
>
> John
>
>
>
> On Sat, Sep 24, 2022 at 9:55 AM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> John, there is a bit more in the issue and the references.
>
> SVG produces animatable interactive 2D images through vector graphics.  So
> it has characteristics of both ImageTexture and MovieTexture (and
> interpolators and scriptable event models).
>
> Dick’s point yesterday was that implementing such a combination is
> different and bigger than ImageTexture or MovieTexture.  The ways that an
> author might use an SVG model are similar, but when you think of how a
> browser might do it and then add computation, user interaction, security,
> etc. etc. then the design perspective is quite different.  This leads us to
> the tried-and-true approach of implementing and testing further, most
> likely as a new node.
>
> So I think that is an interesting and important justification that he
> made.  We offer it back to the group for review and discussion – thanks for
> your points.
>
> 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
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Friday, September 23, 2022 5:33 PM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc:* X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org
> >
> *Subject:* Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: Mantis
> issues review, ballot deadlines, X3D Application Stack Layer Examples
> diagram
>
> Recommendation:  SvgTexture should be a single frame MovieTexture for now,
> with possible extensions to animation with ROUTEs and ECMAscript, if
> animation is enabled on SvgTexture node.  I don’t know if MovieTexture
> enables/disables animation, but my guess is, yes.
>
> Disabling/enabling animation of SVGs should be in more inclusive profiles.
>
> Is that simple enough?
>
>
>
> On Fri, Sep 23, 2022 at 7:23 PM John Carlson <yottzumm at gmail.com> wrote:
>
> 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
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG&data=05%7C01%7Cbrutzman%40nps.edu%7C7b39d12b82984d1d2ad108da9e6019d9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637996432852179194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=UmnAGECEoVx1N3BEnfcG1Wz9waRdHai%2Bo2q6Jak7Du4%3D&reserved=0>
> * "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/20220924/901dee51/attachment-0001.html>


More information about the x3d-public mailing list