[x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architecture and event-exchange diagrams, progress review
John Carlson
yottzumm at gmail.com
Fri Mar 1 14:43:53 PST 2019
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/5183a3bd/attachment-0001.html>
More information about the x3d-public
mailing list