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

John Carlson yottzumm at gmail.com
Sun Mar 3 22:18:25 PST 2019


okay, I guess you’re leaving it up to me.   I am pretty sure that the event
DOMNodeInserted (sp?) does not get called on the script field elements,
which would prevent the script field elements from becoming ROUTEable, but
I will make a larger test case.   I have been sleeping a whole lot.   I
have not been following X3DOM closely since figuring this out.

As previously suggested by Leonard, please try new Function() instead of
eval.   I have not tried this myself.   You may have to search through the
email from him.

Yes, I believe if you enable X3D scripting via the attribute, and add the
fields to the script like ComposedShader adds fields, you just might have a
total solution.   No guarantees though.   The API you mention to connect
the scenegraph to the script is what I tried *after* after doing the above.
  I suggest if you want to tie the scenegraph to the script, do something
like x_ite.   Holger is much more successful than my code.

On Sun, Mar 3, 2019 at 1:23 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> You are right that x3dom does not recognize custom script fields
> defined by field elements. But this is unrelated to the coloring.
> x3dom just leaves script elements alone. As discussed previously
> adding a type attribute with some custom mime-type would prevent
> execution of the script by the browser and allow for x3d scripting.
> I found https://github.com/NeilFraser/JS-Interpreter which provides a
> sandboxed interpreter not using eval. But it runs about 200x slower
> than the browser interpreter and one has to provide the API to connect
> the script to the scene-graph.
> -Andreas
>
> On Sat, Mar 2, 2019 at 5:00 PM John Carlson <yottzumm at gmail.com> wrote:
> >
> > But as seen here, the field element, attribute names, and CDATA are
> black.  What does black mean?   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
> >
> >
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190304/24a1534a/attachment-0001.html>


More information about the x3d-public mailing list