Difference between revisions of "X3D and HTML5 Summary"
From Web3D.org
m (editorial) |
|||
(56 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | Status: these are | + | 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] == | ||
+ | * 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 [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 | ||
+ | * 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 == | ||
+ | * [http://www.iso.org International Organization for Standardization (ISO)] | ||
+ | * [http://www.w3.org World Wide Web Consortium (W3C)] | ||
+ | * [http://www.opengeospatial.org Open Geospatial Consortium (OGC)] | ||
+ | * [http://www.khronos.org The Khronos Group] | ||
+ | * [http://dicom.nema.org Digital Imaging and Communications in Medicine (DICOM)] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | == 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 [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]) | ||
+ | * 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 | |
− | + | ||
− | + | ||
− | + | ||
− | ** HTML5 with embedded X3D as mixed-namespace document | + | == 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='[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. | |
+ | * X3D embedded in object tag | ||
+ | [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? --> | ||
− | * | + | == 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 [http://www.x3dom.org/?p=242 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 | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | * | + | |
− | ** Ensure proper X3D references in HTML5 specifications | + | == 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? --> | ||
+ | |||
+ | |||
+ | == Conclusions == | ||
+ | * X3D Graphics is a natural fit for HTML5 | ||
+ | * 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.
Contents
- 1 Family of X3D Specifications
- 2 X3D Strengths
- 3 Web3D Consortium has formal liaisons and working partnerships with other key organizations
- 4 Relationships between 3D scene graphs, APIs and render layers
- 5 Similarities between MathML, SVG, and X3D
- 6 X3D scene graph APIs
- 7 Differences with underlying render layers
- 8 Simple X3D and HTML5 examples
- 9 X3DOM.org implementation
- 10 X3DOM.org functionality
- 11 X3DOM.org status
- 12 X3DOM.org solution considerations
- 13 Lessons learned from years developing the FreeWrl X3D player
- 14 Action items for X3D and HTML5
- 15 Conclusions
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
- International Organization for Standardization (ISO)
- World Wide Web Consortium (W3C)
- Open Geospatial Consortium (OGC)
- The Khronos Group
- Digital Imaging and Communications in Medicine (DICOM)
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