[x3d-public] RE: Re: X3D Working Group meeting 23 SEP 2022: X3D Application Stack Layers Alternatives diagram refinement
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Sep 25 15:52:41 PDT 2022
Helpful feedback, again thanks Christoph. Responses:
1. Definitely not trying to introduce new concepts. Describing the art
of the possible, emphasizing standards for repeatability wherever possible.
2. Concepts used in Stack Layers Alternatives diagram
* X3D scene is an X3D model that may inline other internal
models/media and interact with external resources.
* X3D Application is whatever application you might put together that
includes X3D model(s).
This seems like a good match to your expression of the same ideas.
3. Agreed with your point; not trying to define a best-practice
approach with this, rather trying to illustrate possibilities.
4. Actually, server can provide any of the content identified and is
especially useful for production/dissemination of Web-based content (HTML5
CSS JavaScript X3D) in any combination. Such deployment can add server-side
mediation or shared state provided via HTML or X3D url calls. So
server-side activities might lay behind several of the blocks shown, adding
richness.
5. Yes these diagrams are both shared
the working group Stack Layers
Alternatives diagram is attempting to show typical design choices available
in this fairly complex domain.
These combinations are all so rich and laden with information-driven
potential that User Experience (UX) concepts seem appropriate for the most
expressive layer at top
am hoping this will also someday inform efforts by
Web3D User Experience (Web3DUX) Working Group.
* Web3D User Experience (Web3DUX) Working Group
* https://www.web3d.org/working-groups/web3d-user-experience
* The Web3DUX working group develops and demonstrates best practices
for X3D support of rich user experiences using a variety of Web3D
technologies and content-delivery platforms.
Onward we go – 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 https://
faculty.nps.edu/brutzman
From: Christoph Valentin <christoph.valentin at gmx.at>
Sent: Sunday, September 25, 2022 2:05 AM
To: John Carlson <yottzumm at gmail.com>; Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu>
Cc: X3D Public Mailing List (x3d-public at web3d.org) <x3d-public at web3d.org>;
Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Kevin <klw71 at yahoo.com>
Subject: Re: RE: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: X3D
Application Stack Layers Alternatives diagram refinement
Good morning,
Thank you for your feed back.
Yes, I agree, while "your"*) diagram is a thoroughly compiled list of
technologies that are used together with X3D, "my"*) diagram is a rough
overview about the possibilities we have at the client implementation of X3D
applications.
May I add a few notes?
1) I tried to introduce the term "Web3D Browser", which is not (yet)
commonly accepted
2) we should really make a difference between "X3D Scene" and "X3D
Application". While X3D scenes should be completely independent of
underlying technologies, the X3D application may be "native", "portable" or
"web based" (or any combination, depending on which type(s) of Web3D
Browsers is/are used/supported by the X3D application)
3) "My" diagram is a "potential" stack. As far as I know, we don't yet have
Web3D Browsers that are (partially) implemented in WASM or based on Node.js
<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnode.js%2F
&data=05%7C01%7Cbrutzman%40nps.edu%7C9af7f0ec179b4de705a408da9ed50a20%7C6d93
6231a51740ea9199f7578963378e%7C0%7C0%7C637996935216623040%7CUnknown%7CTWFpbG
Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
000%7C%7C%7C&sdata=VUSk0M6mWE9j6eiKRenFztk0wkMLVxZuAYhyaxsm3%2BM%3D&reserved
=0> .
4) Neither "your" nor "my" diagram tackles server implementations. Only
clients are considered.
All the best
Christoph
*) i put quotation marks around "your" and "my", because from a
philosophical point of view, everything happening on the public list are
actually "our" efforts :-)
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 25.09.22, 01:54 schrieb "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu
<mailto:brutzman at nps.edu> >:
Christoph, thanks for your efforts and your work on this diagram.
Since there are many ways to put together an application stack that utilizes
X3D, we are striving for flexibility.
Not a goal: mandating a best or recommended practice. That is unhelpful.
Regarding purpose statement, our best phrasing suggested so far is
* “X3D is interoperable with diverse technologies, providing multiple
choices to developers.”
Am avoiding a layer for programming languages – there are many, sometimes
with several used together, and with different configurations between
developers and servers and clients. So including such a layer in a general
diagram seems like an unnecessary complication/confusion.
I hope you think that your diagram has many similarities with this
more-general attempt. Vive la difference
Hope this helps, have fun with X3D! 8)
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
<mailto: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: Christoph Valentin <christoph.valentin at gmx.at
<mailto:christoph.valentin at gmx.at> >
Sent: Saturday, September 24, 2022 11:16 AM
To: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com> >;
Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> >
Cc: X3D Public Mailing List (x3d-public at web3d.org
<mailto:x3d-public at web3d.org> ) <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >
Subject: Aw: Re: [x3d-public] X3D Working Group meeting 23 SEP 2022: X3D
Application Stack Layers Alternatives diagram refinement
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 <mailto:yottzumm at gmail.com> >
An: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu
<mailto:brutzman at nps.edu> >
Cc: "X3D Public Mailing List (x3d-public at web3d.org
<mailto:x3d-public at web3d.org> )" <x3d-public at web3d.org
<mailto: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
<mailto: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 <mailto: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
<mailto: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 <http://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
<mailto:x3d-public at web3d.org> ) <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >
Cc: brutzman at nps.edu <mailto: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.
a. 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.or
g%2FGraphics%2FSVG&data=05%7C01%7Cbrutzman%40nps.edu%7C9af7f0ec179b4de705a40
8da9ed50a20%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637996935216623040%
7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
LCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=prkC1PUfDEHZ1b%2BcfuvLU8B%2BOB28FBDhR49
3xUhuEJ4%3D&reserved=0> 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.
b. 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.
c. 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/component
s/core.html#BindableChildrenNodes>
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
<mailto: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 <http://faculty.nps.edu/brutzman>
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________ x3d-public mailing list
x3d-public at web3d.org <mailto: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/20220925/1ef3572e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220925/1ef3572e/attachment-0001.p7s>
More information about the x3d-public
mailing list