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

[John Carlson]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220924/48e4ee86/attachment-0001.html>