[x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architectureand event-exchange diagrams, progress review

Sat Mar 2 14:00:01 PST 2019

Look in the elements tab in chrome, sorry I wasn’t clear enough.   The field elements and their attribute names are black for script fields.  I am not sure what that means.

Thanks,

John
Sent from Mail for Windows 10

From: Andreas Plesch
Sent: Friday, March 1, 2019 6:56 PM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architectureand event-exchange diagrams, progress review

Script elements appear in the source tab of the dev tools as authored along with the other html elements. It is also possible to set breakpoints in the script and debug.

But scripts will be executed as DOM scripts and not as X3D scripts even if the script element is contained in the X3D element.

Does that help ?

Andreas

---on the phone---

On Fri, Mar 1, 2019, 6:01 PM John Carlson <yottzumm at gmail.com wrote:
Hmm.  What I thought was clear is not clear.   I don’t think script fields appear in the HTML view in developer tools for X3DOM.

On Fri, Mar 1, 2019 at 4:43 PM John Carlson <yottzumm at gmail.com> wrote:
Andreas, can you confirm that script fields do not appear in developer tools view of X3DOM code?  Thanks!

On Fri, Mar 1, 2019 at 4:25 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
I can try to help with these event questions:

> Wondering, for full convergence of our sample implementation:
>
> a. how have X3DOM and X_ITE each implemented events?

x3dom and I think also X_ITE do not use DOM events to output and receive X3D events. x3dom registers watcher functions which get called when an event is output. Here is the main postMessage function which is used to output events:
https://github.com/x3dom/x3dom/blob/e4b752ec0858aeb1ca1c40e2d3b2e9feffe5d947/src/nodes/Core/X3DNode.js#L226
The watcher functions just call an update field function for the To node in routes.
This means that events just get passed around as quickly as possible. I do not think there is an attempt to keep timestamps constant in a given cascade. Not sure how event loops are handled.
For each X3D output event also a DOM event is fired to give DOM JavaScript a chance to listen in and react. But this is independent of and in addition to the x3d event handling.

> b. What differences exist?

I think X-ITE keeps proper timestamps per cascade. It does not emit DOM events unless my DOM bridge is used. There are probaby other differences although I think the idea of field watchers being registered and then called for each output event is the same.

> c. Are ROUTE connections consistent?

Not sure what the question is. Consistent. Perhaps about timestamps?

> d. X3DOM is still missing some important/simple Event Utility nodes - is there a problem?

Here are the currently implemented event utility nodes:

https://github.com/x3dom/x3dom/tree/master/src/nodes/EventUtilities

I can help if any are missing or misbehaving but I am not aware of any. Only the dev version has the nodes.

Best, Andreas

> Date: Fri, 1 Mar 2019 18:21:06 +0000
> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>, "X3D
>         Graphics Working Group" <x3d at web3d.org>
> Subject: [x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4
>         architecture and event-exchange diagrams, progress review
> Message-ID: <a2450931-5645-34fd-0b1d-23c8401a7f94 at nps.edu>
> Content-Type: text/plain; charset="utf-8"

>
> 0. *Attendance*  Anita Havele, Michalis Kamburelis, Vince Marchetti, Nicholas Polys, Dick Puk, Don Brutzman
>
> Plenty to review today, ensuring that our progress continues to be clearly recorded and communicated.
>
> All information in this email is releasable publicly, no separate member-only minutes this week.
>
> ----
>
> Members and invited experts are welcome.  We are an open organization.
>
> We meet today, as usual, 0800-0930 pacific.  To join the teleconference:
>         Web3D Teleconference
>         http://www.web3d.org/member/teleconference-information
>
> The X3D Graphics Working Group addresses all X3D specification issues and coordinates the technical development of future improvements.
>         http://www.web3d.org/working-groups/x3d
>
> Each week we report out both public and member-only information - membership has value.  To become a Web3D Consortium member:
>         Join the Web3D Consortium
>         http://www.web3d.org/join
>
> ==================================
>
> 1. *Last week's minutes*
>
>         X3D meeting minutes 22 FEB 2019: X3D v4 Development status categories
>         http://web3d.org/pipermail/x3d-public_web3d.org/2019-March/010188.html
>
> Agenda review: looking good.
>
> ==================================
>
> 2. Update of X3Dv4 Development page forthcoming, following restoration of capability.
>         http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development
>         (snapshot attached for future comparison that changes will be correct)
>
> Now that the page is operational again, Don will apply the changes listed last week's minutes, section 2.
>
> Category list:
>
> === Accepted Capabilities ===
> === Approved Capabilities ===
> === Candidate Capabilities ===
> === Deferred Capabilities  ===
> === Deprecated and Removed ===
> === Excluded Capabilities ===
>
> Michalis notes that
> a. He is still working on potential Shader revisions.  At most he might propose it become Deprecated, not removed.
> > My comment was about "Programmable shaders component" in X3D, that we
> > placed in the "Excluded" section in last week's minutes.
> >
> > To clarify:
> >
> > 1. I am *not* working on it right now.
> >
> > 2. I proposed that, if we do anything with it, we should make it
> > "deprecated", not "excluded". Reasons:
> >
> > - Many browsers implement it (at least FreeWRL, Instant Reality,
> > Castle Game Engine).
> >
> > - It is useful for authors.
> >
> > - Other 3D software/authoring tools also exposes this -- e.g. Unity,
> > Three.js allow to edit the shaders (even though doing it needs to be
> > done carefully, if one doesn't want to break existing rendering).
> >
> > The arguments for deprecating:
> >
> > - Cross-browser compatibility for this is hard (different browsers
> > have various names for uniforms), 100% cross-browser compatibility may
> > be impossible (what can be exposed is connected to internal browser
> > stuff; e.g. do you animate in shaders on not? do you need better
> > floating point precision?)
> >
> > - Unity e.g. deals with it by introducing "surface shaders". Castle
> > Game Engine has "compositing shaders in X3D" (Effect nodes
> > extensions).
>
> b. Another item, here is his email:
>
> > The second thing (unrelated) I mentioned is that I propose to add
> > "Make RGB and grayscale textures treatment consistent" to the
> > "Accepted" section. My work on it is already on :
> >
> > https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
>
> ==================================
>
> 3. *X3D Architecture Design and Events*
>
> X3Dv4 design review and discussion of documents/diagrams: Web3D 2017/2018 session notes.  Highly detailed event-model diagram are found in prior 2017 X3Dv4 architecture presentations.
>
>         X3D version 4
>         http://www.web3d.org/x3d4
>
>         X3D Futures: What is happening, how to get involved!
>         Web3D 2018 Conference, Poznan Poland
>         http://www.web3d.org/sites/default/files/page/X3D%20Version%204/X3dFuturesWeb3d2018PoznanPolandBrutzman.pdf
>
>           "Future of X3D" presentation and detailed notes from Web3D 2017 Conference, Brisbane Australia, 7 June 2017.
>           http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf
>           http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf
>           http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg
>
> Based on discussions in Korea and preceding documents, Don has written a further-distilled diagram for HTML5/X3D event models (X3Dv4EventDiagram2019January25.pdf attached).  Essentially each (HTML5 and X3D) have internal event loops, and natural times to exchange event buffers occur at the each loop. As with current X3D specification, ordering is guaranteed for each successive timestamp but ordering is not deterministic or guaranteed within a single timestamp.
>
> Deep discussions regarding diagram:
> - no changes to X3D or HTML event-render loops are expected,
> - keeping things as simple as possible in the specification is our preferred approach,
> - If we add a diagram to specification, it should add value.
>
> Even-simpler event diagram resulted, sketch attached (HtmlX3dEventExchangeSimple.jpg).
>
> Existing X3D-only v3.3 specification:
> 4.4.8.3 Execution model, Figure 4.3 ? Conceptual execution model

> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel
>
> Link, excerpts from HTML5 Recommendation on event loops:
>
> ==============================================
> HTML 5.2, W3C Recommendation, 14 December 2017
> https://www.w3.org/TR/html52
>
> 1.5.1. Serializability of script execution
> This section is non-normative.
> To avoid exposing Web authors to the complexities of multithreading, the HTML and DOM APIs are designed such that no script can ever detect the simultaneous execution of other scripts. Even with workers, the intent is that the behavior of implementations can be thought of as completely serializing the execution of all scripts in all browsing contexts.
>
> -----
>
> 1.9.2. Common pitfalls to avoid when using the scripting APIs
> This section is non-normative.
> Scripts in HTML have "run-to-completion" semantics, meaning that the browser will generally run the script uninterrupted before doing anything else, such as firing further events or continuing to parse the document.
>
> On the other hand, parsing of HTML files happens incrementally, meaning that the parser can pause at any point to let scripts run. This is generally a good thing, but it does mean that authors need to be careful to avoid hooking event handlers after the events could have possibly fired.
>
> There are two techniques for doing this reliably: use event handler content attributes, or create the element and add the event handlers in the same script. The latter is safe because, as mentioned earlier, scripts are run to completion before further events can fire.
> ==============================================
>
> Wondering, for full convergence of our sample implementation:
>
> a. how have X3DOM and X_ITE each implemented events?
> b. What differences exist?
> c. Are ROUTE connections consistent?
> d. X3DOM is still missing some important/simple Event Utility nodes - is there a problem?
>
> Next steps on this topic:
> - write spec prose, then consider if a diagram helps,
> - update presentation materials,
> - offer them as another annual update during Friday 26 JUL 2019 meetings at Web3D 2019.
>     http://web3d2019.web3d.org
>
> ==================================
>
> 4. Updated README of github specification pages attached for review.
>
> As noted a number of times before, our current approach is to
> - follow all Web3D procedures,
> - using mailing list, working group teleconferences and Mantis to create drafts and resolve issues,
> - Dick and Don integrate approved into specification on github.
> - plan Working Draft (WD) at Web3D 2019 with initial functionality,
> - plan Committee Draft (CD) is DEC 2019 with final list of nodes.
> - given improving procedures, opportunity for others to edit spec directly.
>
> Discussing schedule:
> - Don and John will be writing X3D JSON Encoding Committee Draft (CD).
> - Another editor assisting us would be helpful.
> - We will also integrate *Tandem Work* listed last week.
> - We will also update all existing encodings: ClassicVRML XML and CompressedBinary.
>
> These updates will be applied to the X3Dv4 Development page, posted to list, and discussed next week.
>
> As noted earlier, directory names will soon be modified to eliminate whitespace.
>
> ==================================
>
> 5. Progress report on MetadataSet implementation efforts:
>
> As it turns out, the recently identified option to change default containerField value won't work, because all must match to ensure consistent parent-child relationship defaults.  Thus merging of MetadataSet.value and MetadataSet.metadata fields as a single MFNode Metadata.children field appears to be the only available resolution of this difficulty.
>
> Looking ahead: since prior objections are theoretically reasonable but have never been observed in practice, request that examples demonstrating the necessity current paired-field approach be developed.  That way we can more directly evaluate this design issue.
>
>         [x3d-public] X3D meeting minutes 3 FEB 2019: X3Dv4 mantis github specification changes, glTF plans, MetadataSet
>         http://web3d.org/pipermail/x3d-public_web3d.org/2019-February/010048.html
>         section 6. MetadataSet and /metadata/ fields.
>
> Don can remember some examples in prior work (though frankly keeping things straight was our biggest challenge then).  This exercises the two containerField options.  There were no cases where it was essential to disambiguate the set of children nodes as different fields.  Design rationale and example template follow.
>
>         SAVAGE Modeling and Analysis Language (SMAL) Resources
>         https://savage.nps.edu/Savage/Tools/SMAL/SMAL.html
>
>         X3D Example Archives: Savage, Tools, SMAL
>         https://savage.nps.edu/Savage/Tools/SMAL/index.html
>
>         Savage Object Metadata Template
>         https://savage.nps.edu/Savage/Tools/SMAL/SavageObjectMetadataTemplate.x3d
>         https://savage.nps.edu/Savage/Tools/SMAL/SavageObjectMetadataTemplate.html
>
> Michalis posted exemplar X3D metadata with Blender script that might export metadata.
>
> > Inside my "demo models", I have
> >
> >   https://github.com/castle-engine/demo-models/blob/master/x3d/blender_custom_properties.x3d
> >
> > The idea is that some day we could make X3D exporter that exports this Blender model:
> >
> >   https://github.com/castle-engine/demo-models/blob/master/x3d/blender_custom_properties.blend
> >
> > with the metadata. It has
> >
> >    <MetadataSet name="custom_properties">
> >       <MetadataString containerField='value' name='MyObjectProperty' value='"object prop value"'/>
> >       <MetadataInteger containerField='value' name='IntProperty' value='123'/>
> >       <MetadataFloat containerField='value' name='FloatProperty' value='456.789'/>
> >    </MetadataSet>
> >
> > The containerField may look "too elaborate", but it works nicely in practice
> >
> > Regards,
> > Michalis
>
> ==================================
>
> Thanks for many contributions and persisting through another necessary slog today.
>
> Of note is that no major showstoppers are noted, rather we are getting closer to a comprehensive X3Dv4-HTML5 architecture each time.
>
> Having fun with X3Dv4!
>
> 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 http://faculty.nps.edu/brutzman
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: X3Dv4EventDiagram2019January25.pdf
> Type: application/pdf
> Size: 49816 bytes
> Desc: X3Dv4EventDiagram2019January25.pdf
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190301/d5ab18c3/attachment.pdf>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: HtmlX3dEventExchangeSimple.jpg
> Type: image/jpeg
> Size: 80871 bytes
> Desc: HtmlX3dEventExchangeSimple.jpg
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190301/d5ab18c3/attachment.jpg>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 120, Issue 3
> ******************************************

-- 
Andreas Plesch
Waltham, MA 02453
_______________________________________________
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/20190302/25bf0e70/attachment-0001.html>