[x3d-public] X3D Working Group meeting 23 SEP 2022: X3D Application Stack Layers Alternatives diagram refinement

[John Carlson]

No worries.  We remember when OpenSim (open SecondLife) was going to take
over.

The difference this time is we are getting consumer-grade XR devices that
are cheaper than phones and computers.

What makes the web work is secure openness (the network effect).

What I’m trying to do is figure out what the main classes we may see in the
Metaverse.  More nouns and verbs:  Humanoid, Humanoid animations.

John

On Sat, Sep 24, 2022 at 1:42 PM Christoph Valentin <
christoph.valentin at gmx.at> wrote:

> Matthew 6:24
>
> If "the Metaverse" really makes the run for the commonly accepted term for
> what-I-call "Integrated 3D Collaboration" (in a more humble way), AND if
> the vendors for "the Metaverse" really understand the necessity to employ
> commonly accepted, open standards, then they will select and support X3D
> automatically.
>
> Stay who you are. Do good things and talk about it. You don't have to
> pander to the Metaverse (translation from German language by
> translate.google.at).
>
> Just my opinion
>
> *Gesendet:* Samstag, 24. September 2022 um 20:25 Uhr
> *Von:* "John Carlson" <yottzumm at gmail.com>
> *An:* "Christoph Valentin" <christoph.valentin at gmx.at>
> *Cc:* "Don Brutzman" <brutzman at nps.edu>, "X3D Public Mailing List (
> x3d-public at web3d.org)" <x3d-public at web3d.org>
> *Betreff:* Re: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022:
> X3D Application Stack Layers Alternatives diagram refinement
> Personally, I think we’re all trying to figure out how X3D fits into the
> Metaverse, which was why i was trying to come up with things we might want
> to do in the Metaverse, and what might appear in the Metaverse.
>
> For me, i may want to show the X3D standard in the Metaverse.
>
> John
>
> On Sat, Sep 24, 2022 at 1:16 PM Christoph Valentin <
> christoph.valentin at gmx.at> wrote:
>
>> Hi all together,
>>
>> May I ask one question?
>>
>> What is the purpose of the diagram?
>>
>> I understood the diagram as a help for decision, if someone likes to
>> implement an "X3D Application" and wants to know, which kind of expertise
>> they will need.
>>
>> True?
>>
>> Kr,
>> CP/V
>>
>> P.S.: on the other hand, the diagram I suggested earlier this week, was
>> just a "rough overview for starters", about how X3D fits into any computer
>> system.
>>
>>
>> *Gesendet:* Samstag, 24. September 2022 um 20:05 Uhr
>> *Von:* "John Carlson" <yottzumm at gmail.com>
>> *An:* "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
>> *Cc:* "X3D Public Mailing List (x3d-public at web3d.org)" <
>> x3d-public at web3d.org>
>> *Betreff:* Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: X3D
>> Application Stack Layers Alternatives diagram refinement
>> More verbs:
>>
>> Require, Design, Implement, Release/Produce/Emit, Consume/Collect.
>>
>> More nouns:
>>
>> Source, Sink
>>
>> On Sat, Sep 24, 2022 at 1:00 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>>> Perhaps we should focus on Author/Creator, Read/View,
>>> Manipulate/Update/Edit/Transform/Convert, Debug/Test, Secure,
>>>  Compress/Decompress, Publish/Evangelize, Buy/Browse, Sell/Purvey, more
>>> verbs. … Archive
>>>
>>> On all our main classes:
>>>
>>> Standards, Object Models, Conversion Programs, Worlds, Scenes, Models,
>>> Examples, Renderings, Bindings, Encodings, Schemas, Files,
>>> Tools/Browsers/Apps/Libraries
>>>
>>> So on one axis we put verbs, and on other axis we put nouns/classes.
>>>
>>> I’m not really pushing my way.  I think it better demonstrates where
>>> work needs to be done.
>>>
>>> In particular, our standards don’t refer to monetization at all.  GNU at
>>> least advocates selling support, there’s Patreon, Odysee and 3D model
>>> stores.
>>>
>>> Thanks, Don, for helping get beyond simple CRUD-GR!
>>>
>>> Woohoo!
>>>
>>> John
>>>
>>> On Sat, Sep 24, 2022 at 10:12 AM Brutzman, Donald (Don) (CIV) <
>>> brutzman at nps.edu> wrote:
>>>
>>>> John wrote:
>>>>
>>>>    - “Looked at layers and alternative attachment.  I’m wondering why
>>>>    there’s two boxes for converting?“
>>>>
>>>>
>>>>
>>>> Good point.  There are two similar concepts I’m trying to distinguish:
>>>>
>>>> (a) 3D models can be converted for reuse offline,
>>>>
>>>> (b) translator libraries offer programming-library options for
>>>> applications.
>>>>
>>>>
>>>>
>>>> Attached please find this morning’s update.  Added a caption for
>>>> further explanation:
>>>>
>>>>
>>>>
>>>>    - “X3D is interoperable with diverse technologies, providing
>>>>    multiple choices to developers.”
>>>>
>>>>
>>>>
>>>> Complicated territory – does this help describe the many options
>>>> available with X3D?  Am striving for clarity and simplicity, if possible.
>>>> Hopefully this diagram continues to improve, and might help us show the X3D
>>>> value propositions more widely, including to Metaverse Standards Forum
>>>> participants.
>>>>
>>>>
>>>>
>>>> Further review and comment by all is welcome.
>>>>
>>>>
>>>>
>>>> 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:* Brutzman, Donald (Don) (CIV)
>>>> *Sent:* Friday, September 23, 2022 11:43 AM
>>>> *To:* X3D Public Mailing List (x3d-public at web3d.org) <
>>>> x3d-public at web3d.org>
>>>> *Cc:* brutzman at nps.edu
>>>> *Subject:* X3D Working Group meeting 23 SEP 2022: Mantis issues
>>>> review, ballot deadlines, X3D Application Stack Layer Examples diagram
>>>>
>>>>
>>>>
>>>> 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
>>>
>>> _______________________________________________ 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/ed084a0e/attachment-0001.html>