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

[John Carlson]

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/20190301/7c34b224/attachment-0001.html>