[x3d-public] X3D V4 Draft Requirements Proposal

[Leonard Daly]

On 3/27/2017 8:05 PM, Andreas Plesch wrote:
> Hi Leonard,
>
> this is a good, demanding list. Some quick comments below.

Thanks Andreas. Comments below. Some extra stuff removed for clarity.


>
>
>     1) Look "like" HTML (5).
>        a) Elements (nodes in X3D-speak) shall be case independent
>        b) Attributes (fields in X3D-speak) shall be case independent
>        c) X3D nodes shall not have name conflicts with any
>     HTML-defined elements
>
>
> 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 ?

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.


>
>
>        d) All X3D nodes shall support all HTML Global Attributes
>     (https://www.w3schools.com/tags/ref_standardattributes.asp
>     <https://www.w3schools.com/tags/ref_standardattributes.asp>)
>
>
> Is this equivalent to requiring that X3D nodes need to derive from 
> HTMLElement as defined in the DOM ?

Interesting point. If so, I wonder what else that requires for each X3D 
node.


>     2) Function "like" HTML (5).
>        a) All nodes shall be fully integrated with the DOM [This may
>     need to
>     change if certain nodes need to remain hidden from the DOM. For
>     example,
>     the manner which X3DOM implements Inline.]
>        b) The scene graph does not need to be DOM (or a portion of it).
>
>
> Not sure I can follow here.

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.


>
>        c) Changes to the DOM shall be reflected in the scene graph
>        d) Changes to the scene graph shall be reflected in the DOM
>
>
> 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).

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.


>
>        e) Events are handled as HTML events
>        f) DOM is the external (i.e., from the web page) API to the
>     scene graph
>
>
> X3dom does it that way. One could add that this external API could be 
> implemented using the SAI thereby guaranteeing X3D event flow determinism.

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.


>
>
>     3) X3D shall support the evolving web standards for flat-3D
>     (WebGL), VR
>     (WebVR) and AR (nothing yet).
>
>
> 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.

I'd like to see that when you are done.


>
>     5) Additional features shall be added
>        a) Deformable-skin joint based animation
>        b) Support for multiple geometry formats, including OBJ, glTF
>
>
> 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.
>
>        c) Increased Material support with a standard library of
>     pre-defined
>     shaders
>
>
> 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.

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.


>
>        d) Mechanism to navigate a scene without a pointing device
>        e) Mechanism to touch or select objects without a pointing device
>
>
> Or with wand or controller.
>
>        f) Review other 3D/VR display technologies (XML3D, A-Frame, GLAM,
>     etc.) to determine if there are features that should be included
>
>
> 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 ?
>
> 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.

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.


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170327/61376411/attachment.html>