Difference between revisions of "X3D V4 HTML Integration Requirements"

Revision as of 10:57, 5 April 2017

Web3D Strategy

"Next-generation evolution + revolution is combined with archival compatibility of existing legacy content." Web3D Standards Strategy

Boundary conditions

1. This is just for X3D running in a web browser and integrated with HTML. This could be expressed as <x3d> ... </x3d> can be treated as a document fragment in the body of an HTML document. If there is X3D outside of this limitation, these requirements may or may not apply.
2. Changes to X3D Abstract Specification? I had not gone as far as indicating which changes needed to go where. Obviously new nodes would need to be in the Abstract specification. But even before going there it is necessary to determine what environments X3D will operate in. My limitations are only for a web browser environment. Environments beside that one are not a concern of the requirements I stated. If there are to be other environments than those differences and similarities would need to be worked out.
3. Defining an HTML5 Encoding, and perhaps a corresponding HTML5 Profile

Notes

1. Some of these requirements may overlap by varying amounts. It was easier to specify them this way then trying to make a complete and non-overlapping set. I'm not going to even claim that this is a complete set, but it is a beginning.
2. For those that want XHTML, then convert all references to HTML to XHTML and make the appropriate syntax changes. The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML.
3. Cross-check with the following pages:
   1. X3D V4 at http://www.web3d.org/x3d4
   2. X3D V4 development at http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development

Candidate Requirements

Looks "like" HTML

Elements (nodes in X3D-speak) shall be case independent

Attributes (fields in X3D-speak) shall be case independent

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.

All X3D nodes shall support all HTML Global Attributes [1]

Is this equivalent to requiring that X3D nodes need to derive from HTMLElement as defined in the DOM?

All X3D fields with the same name as HTML attributes shall behave as the HTML element

TBD: Not all style attributes apply to X3D nodes & fields

HTML encodings

HTML5 has two encodings, not one. Each consistently maps to DOM. The WG developing corresponding functionality and syntax that supports both encodings will add tremendous value to everyone.

HTML5 Recommendation section 8. The HTML syntax https://www.w3.org/TR/html5/syntax.html#syntax

HTML5 Recommendation section 9. The XHTML syntax https://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax

The differences between HTML and XHTML in the appearance of the elements and attributes is that XHTML is strict. This amounts to closing elements, elements and attributes are lower case, mandatory elements and attributes, different MIME type (text/html vs. application/xml or applications/xhtml+xml), and quoted attributes -- see https://www.w3schools.com/html/html_xhtml.asp for details. The WhatWG has a pretty good documentation page on the differences at https://wiki.whatwg.org/wiki/HTML_vs._XHTML. There are differences in scripting. Most of the differences are obvious extensions from XHTML being an XML document. The W3C HTML5 specification (https://www.w3.org/TR/html5/introduction.html#html-vs-xhtml) is consistent with the above comments. All of the formalities aside, from my observations there is very little use of the XHTML document type for regular web pages.

Functions "like" HTML

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.]

The scene graph does not need to be DOM (or a portion of it).

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.

Changes to the DOM shall be reflected in the scene graph

Changes to the scene graph shall be reflected in the DOM

Using the DOM to maintain and reflect state is often considered slow. Could this 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.

Events are handled as HTML events

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.

Other HTML related

X3D scenes can pass events to/from the DOM and ROUTE events within the scene graph.

HTML elements, SVG elements and css blocks can be interspersed with X3D elements.

HTML Script, SVG Script and X3D Script elements are unique and distinguishable.

I still have not heard a good reason to have X3D scripts. They cannot have the same element name so legacy X3D files cannot run. At that point using HTML JavaScript for all processing appears to be the right thing to do. I see it as very important to content developers not to have multiple flavors of JavaScript running.

String-based DOM events correlate with strongly typed X3D events by defined correspondences

Multiple candidate approaches can be listed and compared

The events I am referring to are those that cross between X3D and HTML or any other non-X3D environment (e.g., display, orientation, etc.).

X3D shall support the evolving web standards for flat-3D (WebGL), VR WebVR) and AR

Existing features & functionality

Perform the following tasks with the requirements that is be conflict with the above

Conduct a review of all existing features (nodes) to determine if any should be deprecated in V4

Conduct a review of all existing functionality (run-time) to determine if any should be deprecated or changed in V4

Include all features and functionality that passes the above reviews

Additional features to be added

Deformable-skin joint based animation

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.

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.

Mechanism to navigate a scene without a pointing device

Mechanism to touch or select objects without a pointing device

Or with wand or controller.

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 ?

General comments

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.

OBJ file format

I applaud the idea of multiple geometry formats, as we need interoperability, and glTF is a nice standard.

But I would remove OBJ from the list, or be *careful* what parts of the OBJ are necessary to be supported.

• The OBJ is an old format. It doesn't have many features nice for modern rendering (like a specification of shading suitable for modern GPUs). And it does have some features that are unhandy, and were probably really useful only by the initial Wavefront OBJ implementation (trace_obj).
• The OBJ specification is not officially maintained by anyone, I think. It's not updated. The creators of it, and the original software implementing it, are closed now. (https://en.wikipedia.org/wiki/Wavefront_Technologies , https://en.wikipedia.org/wiki/The_Advanced_Visualizer ). Noone since then has taken the effort to update the OBJ specification in any way, as far as I know.
• Although it has a specification http://www.martinreddy.net/gfx/3d/OBJ.spec , most implementations treat it more like a "de-facto" standard, implementing a different subsets of the format, whatever seems useful. There are features in OBJ format that are widely supported (vertexes with normals, tex coords), and there are features not supported by any existing implementation (I have not seen yet an implementation that supports Bezier patches defined in OBJ files; or one that supprts d_interp or trace_obj).

Bottom line: While OBJ is a popular format, I would either discourage from using it (we made X3D for a reason --- it's really better on all accounts), or at least specify only a precise subset of OBJ features required to be supported.

A very informative link to Wikipedia description of OBJ: https://en.wikipedia.org/wiki/Wavefront_.obj_file

I included OBJ because it is a very popular format for the exchange of geometry and normal information. I have only seen it with triangles. I am in complete agreement with Michalis about limiting it's scope.

Scripting

For example, SVG also has a script node that seems to operate just fine in combination with HTML.

• See [2]
• See the example in 18.2 The 'script' element at [3]
• See the DOM interface definition for SVGScriptElement at [4]