X3D and HTML5 Summary

Status: these are draft slides for the X3D and HTML5 working-group effort that will be provided to the Technical Plenary Week (TPAC) 2009.

Family of X3D Specifications

X3D Abstract Specification describes basic functionality of how X3D works
Three file formats are available: XML (.x3d), ClassicVRML (x3dv), and Compressed Binary Encoding (.x3db)
High-performance Application Programming Interfaces (APIs) are defined for Ecmascript-264 (Javascript) and Java

Non-profit Web3D Consortium maintains and extends X3D via working groups
Set of International Standards certified over 12-year period by multiple national bodies in ISO
Multiple implementations are available (open and commercial source)
Numerous resources available online, including specifications themselves
Third-generation 3D graphics language that extends predecessor Virtual Reality Modeling Language (VRML97)
Long-time W3C member and contributor

Scene graphs are high-level declarative models about how geometry is constructed, colored and animated; these can be expressed as an XML tree
APIs are mid-level libraries for programmers to create imperative source code about geometry and animation (various proprietary codebases, perhaps WebGL or O3D)
Render layers are low-level software libraries that expose the functionality of graphics hardware (e.g. OpenGL and DirectX)
Numerous other 3D technologies exist at each these other layers, often in the form of codebases
The X3D Specifications include both declarative models and strongly typed APIs

MathML describes mathematical expressions and then renders a presentation of them
Scalable Vector Graphics (SVG) describes and presents renderings of 2D shapes, with optional animation and interaction
Extensible 3D (X3D) describes and presents renderings of 3D shapes, with optional animation and interaction
All three languages are formally specified and have well-developed XML encodings
Authors want to use these languages for multimedia content in HTML pages

X3D Scene Access Interface (SAI) provides functionally consistent standardized high-performance APIs
X3D SAI has Ecmascript and Java bindings, other programming languages can be added
X3D SAI is functionally equivalent and has same expressive power as file formats (.x3d, .x3dv, .x3db)
Document Object Model (DOM) is also legal (X3D is XML after all) but historically has been infrequently used because of low performance

OpenGL, DirectX, others are used as render layers for output of X3D player which parses .x3d XML files and draws them
Unlikely that all browsers will implement the same render layer (OpenGL ≠ DirectX)
A Canvas3D layer might be helpful to unify calls to the underlying render layer - but how will it evolve over time?
Not clear that Web authors are clamoring for ability to program low-level OpenGl (or similar) source code in Javascript, such models are not interoperable or composable
X3D avoids these problems as a declarative scene-graph language available in XML

X3D scene as external reference (Anchor link)
X3D embedded in object tag
HTML5 with embedded X3D as mixed-namespace document
Forthcoming InstantReality X3DOM javascript demo: html5+x3d with event-passing connections
(Can we structure our non-scripted examples to correspond to MathML and SVG examples?)

Experience: FreeWRL was originally interpreted Perl with specialized "C" functions. Hoped that hardware would improve faster than size of models; that was not the case.
Interpreted was not the way to go, rewritten in C for performance
Differing OpenGL capabilities: X3D Browsers can handle these, so older models can run efficiently on new hardware (write once, run anytime; even VRML1 models from NASA run fast now)
X3D models are not tied to specific hardware, can run over OpenGL-ES, OpenGL-3.2, DirectX11, older standards like OpenGL-1.0...
OpenGL requires significant programming skills. Don't know why the average web author would want to code in OpenGL.
What does FreeWRL require from Web browser or window? An OpenGL Context (i.e. a number); mouse and keyboard events, window size events, that's about it.

Ensure proper X3D references in HTML5 specifications - what happened, what happens next?
How to allow X3D scene to either reserve screen space or float over the page? Presumably CSS, X3D elements include the class attribute
X3D version 3.3 draft is considering SVG and HTML as source for image textures; how to pass events?
X3D compression will likely evolve to use Efficient XML Interchange (EXI)
Web Accessibility is a future interest
Continue to document correct integration and best practices for X3D and HTML5