[x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architectureand event-exchange diagrams, progress review
Andreas Plesch
andreasplesch at gmail.com
Mon Mar 4 09:00:23 PST 2019
Hi John,
there are currently no plans to add a x3dscript node to x3dom as far
as I know. I looked at the X_ITE implementation again. It uses both,
the 'with' statement and the 'eval' function both of which come with
strong a warnings on MDN. "with' is used to allow the short hand x3d
script/SAI syntax for field functions and constructors but is
deprecated in ECMAScript 2015 and ignored in 'strict mode'.
My impression is that using the Function constructor instead of eval()
and no 'with' statement would lead to script source text something
like this:
- wrap in function so x3d script source cannot affect globals
(although it probably still could)
- preamble:
-- define shortcuts: var SFString = x3dom.fields.SFString; // many,
SFRotation (easy) and some SAI functions would need to implemented
-- define custom fields: var fieldname = x3domNode._vf.fieldname;
//nodefields use _cf
- script source (as is since hard to sanitize)
- return value:
-- var result = {
initialize: initialize, // the function
...,
shutdown: shutdown,
customfield1: (set_)customfield1(_get),
...}
-- return result;
Then updateField(field) would call resultFromScriptFunction[field].
Here is a question: Is x3d script code which lives outside of the
event functions expected to be executed each time, eg. for any event,
before the event function is called ? If so then it may be necessary
to construct a separate Function for each field (and standard event)
which has the complete source and in the end just calls one function
for the return value.
ComposedShader adds routable custom fields by parsing the field nodes
and executing the x3dom .addfield method for each in constructed
custom Function. In routes then the updateField(field) function gets
called. This may be transferable to x3dscripts. Another big job may be
to add routing of node value fields in x3dom. It is important for
scripts.
-Andreas
On Mon, Mar 4, 2019 at 1:18 AM John Carlson <yottzumm at gmail.com> wrote:
>
> 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
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list