Difference between revisions of "X3D and HTML5 Summary"

From Web3D.org
Jump to: navigation, search
m
m (editorial)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Status:  these are draft slides for the [[X3D and HTML5]] working-group effort that will be provided to the  
+
Status:  these are the [[X3D and HTML5]] working-group slides presented to the [http://www.w3.org/html/wg HTML Working Group] during [http://www.w3.org/2009/11/TPAC Technical Plenary Week (TPAC) 2009].  These slides are also available in [http://web3d.org/x3d/presentations/X3D+HTML5.W3cTpac-20091106.pdf .pdf] form.
[http://www.w3.org/2009/11/TPAC Technical Plenary Week (TPAC) 2009].
+
  
  
* Family of [http://www.web3d.org/x3d/specifications X3D Specifications]
+
== Family of [http://www.web3d.org/x3d/specifications X3D Specifications] ==
** X3D Abstract Specification describes basic functionality of how X3D works
+
* X3D Abstract Specification describes basic functionality of how X3D works
** Three file formats are availableXML (.x3d), ClassicVRML (x3dv), and Compressed Binary Encoding (.x3db)
+
* Three file formats are available
** High-performance Application Programming Interfaces (APIs) are defined for Ecmascript-264 (Javascript) and Java
+
** XML (.x3d) with XML Schema and also DTD
 +
** ClassicVRML (x3dv)
 +
** Compressed Binary Encoding (.x3db) with geometric compression and Fast Infoset (FI)
 +
* High-performance Application Programming Interfaces (APIs) are defined for Ecmascript-264 (Javascript) and Java
  
  
* X3D Strengths
+
== X3D Strengths ==
** Non-profit [http://www.web3D.org Web3D Consortium] maintains and extends X3D via working groups
+
* Non-profit [http://www.web3D.org Web3D Consortium] maintains and extends X3D via working groups
** Set of International Standards certified over 12-year period by multiple national bodies in ISO
+
* Set of International Standards certified over 12-year period by multiple national bodies in ISO
** Multiple implementations are available (open and commercial source)
+
* Multiple implementations are available (open and commercial source)
** Numerous resources available online, including specifications themselves
+
* Numerous resources available online, including specifications themselves
** Third-generation 3D graphics language that extends predecessor Virtual Reality Modeling Language (VRML97)
+
* Third-generation 3D graphics language that extends predecessor Virtual Reality Modeling Language (VRML97)
** Long-time W3C member and contributor
+
* Long-time W3C member and contributor
  
  
* Web3D Consortium has formal liaisons and working partnerships with other key organizations
+
== Web3D Consortium has formal liaisons and working partnerships with other key organizations ==
** [http://www.iso.org International Organization for Standardization (ISO)]
+
* [http://www.iso.org International Organization for Standardization (ISO)]
** [http://www.w3.org World Wide Web Consortium (W3C)]
+
* [http://www.w3.org World Wide Web Consortium (W3C)]
** [http://www.opengeospatial.org Open Geospatial Consortium (OGC)]
+
* [http://www.opengeospatial.org Open Geospatial Consortium (OGC)]
** [http://www.khronos.org The Khronos Group]
+
* [http://www.khronos.org The Khronos Group]
** [http://dicom.nema.org Digital Imaging and Communications in Medicine (DICOM)]
+
* [http://dicom.nema.org Digital Imaging and Communications in Medicine (DICOM)]
  
  
* Relationships between 3D scene graphs, APIs and render layers
+
== 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
+
* 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 [http://en.wikipedia.org/wiki/WebGL WebGL] or [http://code.google.com/apis/o3d O3D])
+
* APIs are mid-level libraries for programmers to create imperative source code about geometry and animation (various proprietary codebases, perhaps [http://en.wikipedia.org/wiki/WebGL WebGL] or [http://code.google.com/apis/o3d O3D])
** Render layers are low-level software libraries that expose the functionality of graphics hardware (e.g. [http://www.opengl.org OpenGL] and [http://en.wikipedia.org/wiki/DirectX DirectX])
+
* Render layers are low-level software libraries that expose the functionality of graphics hardware (e.g. [http://www.opengl.org OpenGL] and [http://en.wikipedia.org/wiki/DirectX DirectX])
** Numerous other 3D technologies exist at each of the other layers, often in the form of codebases
+
* 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
+
* The X3D Specifications include both declarative models and strongly typed APIs
  
  
* Similarities between MathML, SVG, and X3D
+
== Similarities between MathML, SVG, and X3D ==
** MathML describes mathematical expressions and then renders a presentation of them
+
* 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
+
* 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
+
* 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
+
* All three languages are formally specified and have well-developed XML encodings
** Authors want to use these languages for multimedia content in HTML pages
+
* Authors want to use these languages for multimedia content in HTML pages
  
  
* X3D scene graph APIs
+
== X3D scene graph APIs ==
** X3D Scene Access Interface (SAI) provides functionally consistent standardized high-performance 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 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)
+
* 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
+
* 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
+
== 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
+
* 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)
+
* 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?
+
* 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
+
* 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 avoids these problems as a declarative scene-graph language available in XML  
  
  
* Simple [[X3D and HTML5 examples]]
+
== Simple X3D and HTML5 examples ==
** X3D scene as external reference (Anchor link)
+
Detailed example source is provided on the [[X3D and HTML5 examples]] page.
** X3D embedded in object tag  
+
* X3D scene as external reference (Anchor link)
** HTML5 with embedded X3D as mixed-namespace document
+
  HTML source:  Here is my <a href='[http://www.web3d.org/x3d/content/examples/HelloWorld.x3d HelloWorld.x3d]' title='Link to new X3D document'>[http://www.web3d.org/x3d/content/examples/HelloWorld.x3d HelloWorld example]</a> in X3D.
** Forthcoming InstantReality [http://www.web3d.org/x3d/specifications X3DOM] javascript demo: html5+x3d with event-passing connections
+
* X3D embedded in object tag
** (Can we structure our non-scripted examples to correspond to MathML and SVG examples?)
+
  [http://www.web3d.org/x3d/content/examples/HtmlObjectTagForX3d.html HTML Object Tag for X3D] shows how to place X3D objects within an HTML page
 +
* HTML5 with embedded X3D as mixed-namespace document
 +
  [http://www.X3Dom.org X3Dom] demonstration
 +
<!-- Can we structure our non-scripted examples to correspond to MathML and SVG examples? -->
  
  
* Lessons learned from years developing FreeWrl, an X3D player
+
== X3DOM.org implementation ==
** 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)
+
* Open Source, Javascript / WebGL based
** 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)
+
* Needs Firefox/WebKit nightly builds
** 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.
+
* Runs without any plugin
** People don't code in assembler much anymore. I don't know why the average person would want to code in OpenGL.
+
* Can be easily modified while evolving
** What does FreeWRL require? An OpenGL Context (ie, a number); mouse/keyboard events, window size events, that's about it.
+
* Needs XHTML encoded data, one line script per XHTML
  
  
* Action items for X3D and HTML5
+
== X3DOM.org functionality ==
** Ensure proper X3D references in HTML5 specifications - what happened, what happens next?
+
* Searches for existing &lt;X3D xmlns= &gt; and creates scenegraph from DOM Tree
** How to allow X3D scene to either reserve screen space or float over the page?  Presumably CSS, X3D elements include the class attribute
+
* Creates canvas with WebGL-Context for rendering
** X3D version 3.3 draft is considering SVG and HTML as source for image textures; how to pass events?
+
* Monitors changes with DOM Level 2 events (DOMNodeRemoved, DOMNodeInserted, DOMAttrModified)
** X3D compression will likely evolve to use Efficient XML Interchange (EXI)
+
** DOMAttrModified [http://www.x3dom.org/?p=242 buggy] in WebKit !!!
** Web Accessibility is a future interest
+
* Supports simple interaction (HTML events on 3D Object) and navigation
** Continue to document correct integration and best practices for X3D and HTML5
+
  
 +
 +
== X3DOM.org status ==
 +
* 3 work-months of development
 +
* Manageable Code Size (~5000 Lines JavaScript Code, ~1000 Lines GLSL Shader Code)
 +
* Support well defined Subset of X3D
 +
** Interchange Profile + Inline, Scripting, Text nodes
 +
** No Scripting or Prototype on the X3D side
 +
* Dynamic X3D content
 +
** Support for n:m FieldToField ROUTEs, TimeSensor + Interpolator + Follower nodes
 +
 +
 +
== X3DOM.org solution considerations ==
 +
* Provides an experimental open-source runtime – not the ultimate solution
 +
** Feature Limitations: e.g. no access to spatial audio or video texture layer
 +
** Performance Limitation: Javascript/WebGL can only handle models up to ~200.000 Triangle right now
 +
* Standardization and native implementations are needed
 +
** Support for SAI/X3D-Plugin in addition to the WebGL-Render backend will be next iteration
 +
** Final deployment solution best as part of browser
 +
** X3D community has multiple open-source C/C++ codebase [http://www.web3d.org/x3d/content/examples/X3dResources.html resources] available
 +
 +
 +
== Lessons learned from years developing the [http://freewrl.sourceforge.net FreeWrl] X3D player ==
 +
* 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.
 +
 +
 +
== 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
 
<!-- Any other recommendations or work issues? -->
 
<!-- Any other recommendations or work issues? -->
  
* Conclusions
+
 
** X3D Graphics is a natural fit for HTML5
+
== Conclusions ==
** We want to maximize capabilities and deployment
+
* X3D Graphics is a natural fit for HTML5
** Further collaboration welcome
+
* We want to maximize capabilities and deployment
 +
* Further collaboration welcome

Latest revision as of 18:34, 6 November 2009

Status: these are the X3D and HTML5 working-group slides presented to the HTML Working Group during Technical Plenary Week (TPAC) 2009. These slides are also available in .pdf form.


Family of X3D Specifications

  • X3D Abstract Specification describes basic functionality of how X3D works
  • Three file formats are available
    • XML (.x3d) with XML Schema and also DTD
    • ClassicVRML (x3dv)
    • Compressed Binary Encoding (.x3db) with geometric compression and Fast Infoset (FI)
  • 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


Web3D Consortium has formal liaisons and working partnerships with other key organizations


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 these 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

Detailed example source is provided on the X3D and HTML5 examples page.

  • X3D scene as external reference (Anchor link)
  HTML source:  Here is my <a href='HelloWorld.x3d' title='Link to new X3D document'>HelloWorld example</a> in X3D.
  • X3D embedded in object tag
  HTML Object Tag for X3D shows how to place X3D objects within an HTML page
  • HTML5 with embedded X3D as mixed-namespace document
  X3Dom demonstration


X3DOM.org implementation

  • Open Source, Javascript / WebGL based
  • Needs Firefox/WebKit nightly builds
  • Runs without any plugin
  • Can be easily modified while evolving
  • Needs XHTML encoded data, one line script per XHTML


X3DOM.org functionality

  • Searches for existing <X3D xmlns= > and creates scenegraph from DOM Tree
  • Creates canvas with WebGL-Context for rendering
  • Monitors changes with DOM Level 2 events (DOMNodeRemoved, DOMNodeInserted, DOMAttrModified)
    • DOMAttrModified buggy in WebKit !!!
  • Supports simple interaction (HTML events on 3D Object) and navigation


X3DOM.org status

  • 3 work-months of development
  • Manageable Code Size (~5000 Lines JavaScript Code, ~1000 Lines GLSL Shader Code)
  • Support well defined Subset of X3D
    • Interchange Profile + Inline, Scripting, Text nodes
    • No Scripting or Prototype on the X3D side
  • Dynamic X3D content
    • Support for n:m FieldToField ROUTEs, TimeSensor + Interpolator + Follower nodes


X3DOM.org solution considerations

  • Provides an experimental open-source runtime – not the ultimate solution
    • Feature Limitations: e.g. no access to spatial audio or video texture layer
    • Performance Limitation: Javascript/WebGL can only handle models up to ~200.000 Triangle right now
  • Standardization and native implementations are needed
    • Support for SAI/X3D-Plugin in addition to the WebGL-Render backend will be next iteration
    • Final deployment solution best as part of browser
    • X3D community has multiple open-source C/C++ codebase resources available


Lessons learned from years developing the FreeWrl X3D player

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


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