<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/27/2017 8:05 PM, Andreas Plesch
wrote:<br>
</div>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<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>
</div>
</blockquote>
<br>
Thanks Andreas. Comments below. Some extra stuff removed for
clarity.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<div class="gmail_extra" dir="auto">
<div class="gmail_quote" dir="auto"><br>
<blockquote class="quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote>
<br>
In that case, each node would be aliased with a HTML5 Custom Element
compatible name. I don't know the answer. It might depend on how
"integrated" the spec is with HTML.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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 moz-do-not-send="true"
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>
</blockquote>
<br>
Interesting point. If so, I wonder what else that requires for each
X3D node.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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">
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>
</blockquote>
<br>
X3DOM keeps a separate scene graph from the DOM. The rendering
occurs from the scene graph. Changes to the DOM cause changes to the
scene graph and vice versa. I did not want to preclude that
operation.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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>
</blockquote>
<br>
Perhaps it is better to set all current fields that are initialized
to be (generally) non-updated. If you want to see a particular
value, you need to listen to the appropriate event. Certain events
would cause the initialized fields to be updated. I know that this
is not written well. <br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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>
</blockquote>
<br>
Would it be possible to implement the SAI over DOM? I am concerned
about having more than one fundamental API. It will cause confusion
and errors.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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>
</blockquote>
<br>
I'd like to see that when you are done.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto"><br>
<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">
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. <br>
</div>
</div>
</blockquote>
<br>
Including programmable shaders in declarative language and not
providing pre-defined operations seems like a poor choice. This is
an attempt to start to rectify it.<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67uJYy-HONQO9_Y_HqsWY0qSw6AmSn-EtNYVbWLrT0Ba1w@mail.gmail.com"
type="cite">
<div dir="auto">
<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>
</blockquote>
<br>
Deformable skin from joint animation calculations are typically
carried out on the GPU. Too much for serial processors. I'm sure
there are other items.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>