X3D and HTML5 Summary

From Web3D.org
Revision as of 02:57, 6 November 2009 by Brutzman (Talk | contribs)

Jump to: navigation, search

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


  • X3D Strengths
    • 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



  • Relationships between 3D scene graphs, APIs and render layers
    • 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 of the other layers, often in the form of codebases
    • The X3D Specifications include both declarative models and strongly typed APIs


  • Similarities between MathML, SVG, and X3D
    • 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 graph APIs
    • 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


  • Differences with underlying render layers
    • 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


  • Simple X3D and HTML5 examples
    • 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?)


  • Lessons learned from years developing FreeWrl, an X3D player
    • Experience - FreeWRL, 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)
    • 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... and MultiThreading OpenGL if the hardware supports it.
    • People don't code in assembler much anymore. I don't know why the average person would want to code in OpenGL.
    • What does FreeWRL require? An OpenGL Context (ie, a number); mouse/keyboard events, window size events, that's about it.


  • Action items for X3D and HTML5
    • 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


  • Conclusions
    • X3D Graphics is a natural fit for HTML5
    • We want to maximize capabilities and deployment
    • Further collaboration welcome