<div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote">Hi Leonard,</div><div class="gmail_quote" dir="auto"><br></div><div class="gmail_quote" dir="auto">this is a good, demanding list. Some quick comments below.</div><div class="gmail_quote" dir="auto"><br><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
To: X3D Public <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
Subject: [x3d-public] X3D V4 Draft Requirements Proposal<br>
<br>
Last week there was a bit of conversation on the 3D WG list about<br>
requirements. I am sending my contribution on the topic of X3D V4<br>
requirements to the public list to get increased conversation. Note that<br>
this is NOT the product of the WG and I am not claiming that these are<br>
final. This is only a personal early draft of requirements for X3D<br>
running in a web browser environment. Please feel free to discuss or<br>
propose additions/changes to this list.<br>
<br>
<br>
*Requirements*<br>
Boundary conditions: This is just for X3D running in a web browser and<br>
integrated with HTML. If there is X3D outside of this limitation, these<br>
requirements may or may not apply.<br>
<br>
Note: Some of these requirements may overlap by varying amounts. It was<br>
easier to specify them this way then trying to make a complete and<br>
non-overlapping set. I'm not going to even claim that this is a complete<br>
set, but it is a beginning.<br>
<br>
For those that want XHTML, then convert all references to HTML to XHTML<br>
and make the appropriate syntax changes. The differences between HTML<br>
and XHTML in the appearance of the elements and attributes is that XHTML<br>
is strict. This amounts to closing elements, elements and attributes are<br>
lower case, mandatory elements and attributes, different MIME type<br>
(text/html vs. application/xml or applications/xhtml+xml), and quoted<br>
attributes -- see <a href="https://www.w3schools.com/html/html_xhtml.asp" rel="noreferrer" target="_blank">https://www.w3schools.com/<wbr>html/html_xhtml.asp</a> for<br>
details. The WhatWG has a pretty good documentation page on the<br>
differences at <a href="https://wiki.whatwg.org/wiki/HTML_vs._XHTML" rel="noreferrer" target="_blank">https://wiki.whatwg.org/wiki/<wbr>HTML_vs._XHTML</a>.<br>
<br>
<br>
1) Look "like" HTML (5).<br>
   a) Elements (nodes in X3D-speak) shall be case independent<br>
   b) Attributes (fields in X3D-speak) shall be case independent<br>
   c) X3D nodes shall not have name conflicts with any HTML-defined elements<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I believe the HTML5 Custom Elements spec requires a prefix-name format for element names. While allowing lowercase should we also allow 'x3d-transform' format alternative names ?</div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   d) All X3D nodes shall support all HTML Global Attributes<br>
(<a href="https://www.w3schools.com/tags/ref_standardattributes.asp" rel="noreferrer" target="_blank">https://www.w3schools.com/<wbr>tags/ref_standardattributes.<wbr>asp</a>)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM ?</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   e) All X3D fields with the same name as HTML attributes shall behave<br>
as the HTML element<br>
   f) TBD: Not all style attributes apply to X3D nodes & fields<br>
<br>
2) Function "like" HTML (5).<br>
   a) All nodes shall be fully integrated with the DOM [This may need to<br>
change if certain nodes need to remain hidden from the DOM. For example,<br>
the manner which X3DOM implements Inline.]<br>
   b) The scene graph does not need to be DOM (or a portion of it).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Not sure I can follow here.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   c) Changes to the DOM shall be reflected in the scene graph<br>
   d) Changes to the scene graph shall be reflected in the DOM<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Using the DOM to maintain and reflect state is often considered slow. Could d) be optional ? Changes to the scene graph cause events which can be listened to if required. (This is why cobweb-dom does not reflect back interpolator output to the DOM at this point).</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   e) Events are handled as HTML events<br>
   f) DOM is the external (i.e., from the web page) API to the scene graph<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">X3dom does it that way. One could add that this external API could be implemented using the SAI thereby guaranteeing X3D event flow determinism.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
3) X3D shall support the evolving web standards for flat-3D (WebGL), VR<br>
(WebVR) and AR (nothing yet).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I still want to complete my diff between webvr draft standard and x3d. However, it looks like the webvr standard already evolved quite a bit.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) Existing features & functionality<br>
   a) Perform the following tasks with the requirements that is be<br>
conflict with the above<br>
     i) Conduct a review of all existing features (nodes) to determine<br>
if any should be deprecated in V4<br>
     ii) Conduct a review of all existing functionality (run-time) to<br>
determine if any should be deprecated or changed in V4<br>
   b) Include all features and functionality that passes the above reviews<br>
<br>
5) Additional features shall be added<br>
   a) Deformable-skin joint based animation<br>
   b) Support for multiple geometry formats, including OBJ, glTF<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I have a pretty good idea about gltf2 support in x3dom, see my x3dom GitHub issue. But since it is quite a bit of work, it will be some time/use case.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   c) Increased Material support with a standard library of pre-defined<br>
shaders<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Three.js has good shaders including for PBR. But again quite a bit of work. Not sure if Fraunhofer is that engaged since there may be commercialization interest. </div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   d) Mechanism to navigate a scene without a pointing device<br>
   e) Mechanism to touch or select objects without a pointing device<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Or with wand or controller.</div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   f) Review other 3D/VR display technologies (XML3D, A-Frame, GLAM,<br>
etc.) to determine if there are features that should be included<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The three.js examples are also inspiring. Postprocessing of the rendered frame in another shader stage comes to mind.  There are probably many more modern graphics methods which need some support. Ambient occlusion ssao ? Motion blur ? Distance defocus ? </div><div dir="auto"><br></div><div dir="auto">Generally, the vrml spec. was written before the advent of powerful GPUs (massively parallel super computers) where it now can be faster to repeat the same fragment shader operation for each pixel (perhaps a million times) rather than update data between cpu and gpu once. Not sure what the consequences exactly are other than being shader friendly in some way.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
*Leonard Daly*<br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - /Creating the Future/<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170327/3ce37711/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/<wbr>attachments/20170327/3ce37711/<wbr>attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
------------------------------<br>
<br>
End of x3d-public Digest, Vol 96, Issue 66<br>
******************************<wbr>************<br>
</blockquote></div><br></div></div>