[x3d-public] X3D meeting minutes 1 MAR 2019: X3Dv4 architecture and event-exchange diagrams, progress review
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Fri Mar 1 10:21:06 PST 2019
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-0001.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-0001.jpg>
More information about the x3d-public
mailing list