Difference between revisions of "X3D version 4.0 Development"

From Web3D.org
Jump to: navigation, search
(→‎Candidate Capabilities)
(→‎Excluded Capabilities: SVG entry)
Line 157: Line 157:
 
=== Excluded Capabilities ===
 
=== Excluded Capabilities ===
  
−
Excluded capabilities are considered "out of scope" for X3D, and are not expected to be included in future versions.
+
Excluded capabilities are evaluated as "out of scope" for X3D, and are not expected to be included in future versions.
  
−
* None yet listed.
+
* Native support for Scalable Vector Graphics (SVG).
  
 
=== Removed Capabilities ===
 
=== Removed Capabilities ===

Revision as of 17:02, 8 March 2019

X3D Version 4 is a major upgrade to the Extensible 3D (X3D) Graphics International Standard that aligns with the HTML5 Recommendation. This is major work in progress, expected to include several future versions. This effort is driven by the X3D Graphics Working Group with regular community outreach.

Genesis and Strategic Overview

Web3D Consortium working groups currently define specification goals and requirements. Working group efforts are often the focus for defining and testing new X3D components.

We publicly review these goals annually during Web3D Conference and SIGGRAPH Birds of a Feather (BOF) meetings (SIGGRAPH 2016, upcoming SIGGRAPH 2017).

Suggestions, development and discussion via the x3d-public mailing list is ongoing.

X3D version 3.4 Development efforts were evolutionary improvements to the widely proven X3D Graphics architecture. Consortium members decided to skip version 3.4 and go straight to version 4.0, prior goals and requirements have all been merged here.

The Candidate Capabilities list shows that a lot of interesting capabilities have been proposed and are under way for X3D version 4. However, topics on this list are not guaranteed to be completed! Rather these are all works in progress.

Activity and approval proceeds based on technical contributions and Web3D Consortium Member priorities. Please consider joining Web3D Consortium to help advance 3D graphics on the Web.These X3D version 4.0 Development efforts are considering potentially major additions to the baseline X3D architecture.

Please contact us if you think additional technologies need to be considered. X3D Futures planning is primarily a Web3D Consortium member-only activity, with community input.

Capabilities

Component improvements and additions considered and recommended by the X3D Working Group, with review by the X3D community. The draft X3D specifications are approved by Web3D Consortium Board of Directors and then submitted to ISO for ratification.

All suggestions and recommendations are welcome. Please contact us if you think additional technologies need to be considered.

Accepted Capabilities

These capabilities are accepted in principle by the X3D Working Group. Further feasible work remains in specification writing, examples, implementation and evaluation.

  • TODO link reference pages on Web3D.org
  • TODO link specification-tracking spreadsheet
  • X3D Node Inventory Comparison (spreadsheet .xlsx) shows implementation coverage
  • TODO how to track examples?

TODO copy full entries from below, edit for clarity and consistency.

  • Annotations component
  • Humanoid Animation (HAnim) version 2: anatomical correctness for skeleton and skinning, motion animation, hands and feet. Future: faces, organs
  • Lighting model: glTF and Physically Based Rendering (PBR)
  • Materials: improvements to Material and TwoSidedMaterial
    • to make them modern (e.g. normal maps)
    • consistent with PhysicalMaterial (e.g. texture slots inside Material).
  • Texturing - Projective Texture Mapping (PTM), Environment Lighting
  • PointProperties
  • Volume Rendering component extensions
  • Security Considerations section added to each component.

Approved Capabilities

These capabilities are published in the github draft X3Dv4 specification, reviewed by the X3D community for comment, fully recommended by the X3D Working Group, and approved by the Web3D Consortium Board of Directors.

  • No capabilities for X3Dv4 are yet approved.

Candidate Capabilities

Candidate capabilities are under active consideration by the X3D Working Group.

  • Each of the following possibilities for X3D version 4 have been discussed by the various X3D working groups during meetings and on mailing lists.
  • Each potential capability is considered to be a feasible (and in most cases, straightforward) addition to the existing X3D version 3.3 architecture.

Working notes:

  1. TODO: Which experimental nodes implemented by X3D browsers are ready for consideration? Candidates include Fraunhofer, X3DOM, Cobweb, other members and working groups?
  2. TODO: articulate server-side visualization: Big Data, cloud computing, and related issues.
  3. Discussion from 24 FEB 2019: put X3D-HTML5 integration in a new Annex in 19775-1 to see if that works. Much easier lift procedurally than starting a separate 19775-3 specification. Dick described tradeoffs. Seems like a good idea to put candidate text in an Annex before committing to a whole new specification.
    1. Of note: Roy created a draft 19775-3 in github for HTML5-X3D
    2. Don and Dick will look at prior materials and create draft annex structure for HTML5-DOM in X3D Architecture 19775-1.
  4. Discussion (move onto Mantis and mailing list): should we consider adding X3DUOM descriptive prose in Concepts section? It is becoming essential to confirming that node interfaces are well specified and implementable precisely/interoperably in various X3D file encodings and language bindings.
    1. Summary: "X3DUOM fully defines all object-oriented relationships for nodes, fields and abstract interfaces in the X3D Architecture. X3DUOM is a validatable expression of X3D relationships that can be applied to implement various X3D file encodings and programming-language bindings."

Nodes and components:

  • Appearance
    • Images: recommended formats for imagery and video (.gif .bmp .flv .exr .hdr etc.) - details below:
      • GIF: "Graphics Interchange Format, Version 89a", W3C. 31 July 1990.
      • BMP: BMP. Note: Originally developed by Microsoft for OS/2 and Windows.
      • FLV: FLV and F4V usage has been deprecated by browser manufacturers.
      • EXR: EXR file layout, developed as OpenEXR by Industrial light and magic (ILM). This requires HDR (see below).
      • Khronos Texture Format (KTX): Khronos KTX File Format
      • QR codes: QR codes, while useful in Mixed Augmented Reality (MAR) applications, are a content representation and not a file format.
      • attributes: width_changed, height_changed, aspectRatio_changed with accessType outputOnly
    • SVG: Possible use of SVG for image generation on the fly. Images could be static or dynamic. See W3C Graphics on the web.
    • Materials: advanced parameters
    • HDR: Improvements in both materials and rendering for high definition rendering (HDR) technological advances.
    • Multitexture: review for correctness, completeness and conformance of rendering example scenes
    • Rendering: bump maps, shadows, edge smoothing, gamma correction, Non-Photorealistic Rendering (NPR)
    • Shaders: improved support and better interoperability, library of examples; CommonSurfaceShader?
    • Texturing: Texture atlas, projective texture mapping (PTM), RenderedTexture node for multipass rendering - 2D texture version of GeneratedCubeMapTexture, first proposed by Xj3D and also implemented in X3DOM and InstantReality, useful for all kinds of NPR, shadows, mirrors, etc. Also review 8-bit vs 24-bit texture application differences - see https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode.
    • Chroma key for TextureProperties node to support special transparent background.
  • Audio and video: alignment with W3C Audio Working Group, especially for Web Audio API and Web Midi API.
  • Computer Aided Design (CAD) a new profile to be named CADInteractive, to include:
  • ECMAScript (Javascript) specification revision compatibility with ECMAScript encoding; possibly add C# or Python support. Note that minor changes in the current X3D Script node might be needed to enable full integration into HTML/DOM.
  • Events
    • Review X3D event interoperability with other event models, such as Document Object Model (DOM) Recommendations
    • Add capability for Event logging and playback so that deterministic replay is possible for demonstrations and debugging
  • Generalized input/output interface support
  • Geometry
  • Geospatial X3D component
  • Interoperability: include class attribute for all nodes to all encodings
  • JSON: JavaScript Object Notation as an X3D encoding (assessment thread), relation to GlTF, streaming considerations
  • Medical working group ImageTextureAtlas plus capabilities including recent Community Improvements to the Volume Component (Aberlaiz et al 2018 [1], and MPR)
  • Mobile Profile. TODO - needed? Calling out a reduced palette for mobile devices remains interesting, but might instead remain a browser-optional optimization.
  • Metadata: support for embedding information useful for applications utilizing X3D
    • Enumerated types: better access, typing, naming, and validation than using MetadataSet/MetadataString combinations
  • Mixed and Augmented Reality (MAR): follow ISO MAR Reference Model, integrate multiple capabilities with devices situated in real world
  • Networking: consider NetworkSensor and event-passing issues, streaming using JSON, server-side 3D topics
  • Security and privacy:
    • Include X3D Networking Component Level 4 support for https in Immersive, Interactive and other commonly used profiles
    • Review X3D specifications to ensure that Security Considerations are fully documented throughout in every component
    • XML Security provides best-available encryption, digital signature (authentication)
    • Web Privacy: examine X3D compatibility with Do Not Track, P3P, POWDER
  • Viewing and navigation: cinematic camera control, alternative navigation types (such as PAN, TURNTABLE etc.), Recommended navigation behaviours review, and old MatrixTransform node (esp. useful for CAD, VR/AR etc., implemented in X3DOM and InstantReality)
  • Virtual Reality (VR): requirements definition needed includes viewing with stereo devices, interocular distance, frame-rate requirements, comparison (and potential profile) for WebVR capabilities, physiological considerations, health and safety, relation with Mixed Augmented Reality (MAR), etc.

Deferred Capabilities

Deferred capabilities are candidates for inclusion in a follow-on version of X3Dv4.

In general, new capabilities for Mixed Augmented Reality (MAR) are deferred to X3Dv4.1.

  • None yet listed.

Deprecated Capabilities

Deprecation means that a feature will still be included for the next version, but is nevertheless expected to be removed in future versions. This approach can simplify transition of content to a new approach.

Under consideration:

  • GeoOrigin node was deprecated in X3Dv3.3 and needs to be either restored or removed.
  • Layout component - perhaps no longer needed, especially with HTML5 (and MAR) integration expected.
  • Shaders component - deserved close reconsideration.

Excluded Capabilities

Excluded capabilities are evaluated as "out of scope" for X3D, and are not expected to be included in future versions.

  • Native support for Scalable Vector Graphics (SVG).

Removed Capabilities

Removed capabilities will no longer be supported in X3Dv4.

  • None yet listed.

Architectural Considerations

This section will synopsize significant differences between X3D version 4 and X3D version 3 that may require structural changes in tools and scenes. Special attention is needed to minimize incompatibilities with legacy software and content.

Much depends on the target environment. X3D V3.x presumes a controlled environment that interacts with the rest of the (computing) world through a well defined API (called SAI). When X3D is running in the browser (as in fully integrated with the DOM), the DOM defines a portion of the environment in which X3D must operate. For that environment it will be necessary to make changes to X3D so that it is compatible with the DOM.

Backwards and Forwards Compatibility

A major benefit of using the X3D standard is full backwards compatibility with prior VRML97 and X3D content. Thanks to careful design and insistence on implementation/evaluation, the X3D International Standard has maintained both steady growth and interoperability ever since Virtual Reality Modeling Language (VRML) in 1997. This track record of stability and innovation is among the best in the 3D graphics industry.

Our goal is to maximize, but not necessarily require, backwards compatibility in version 4.0 with the version 3.x specifications

  • A great majority of X3D nodes and features are likely achievable without change
  • Some X3D features may require import/export conversion for compatibility (event model reconciliation, ROUTEs and sensors perhaps)
  • A few features might be refactored, deprecated or obsoleted (none yet identified)
  • Name deconfliction: HTML Script versus embedded X3D Script

The comprehensive forward compatibility of VRML97 and X3D with later-developed X3D versions shows that careful anticipatory design is achievable.

X3D version 4.0 Development efforts are currently focused on HTML5, Declarative 3D, X3DOM, and Cobweb with many more issues under consideration.

X3D Version 4.1 is focused on Mixed and Augmented Reality (MAR) capabilities, which may also require architectural changes. Some new technologies may get pushed from 4.0 to 4.1 (or back again) after careful consideration by the respective working groups.

Related specification support and changes

Legacy Issues

We plan to confirm the existence of complete capabilities for X3D v3.3 prior to final approval of X3D version 4.

  • Full support for all existing X3D v3.3 components:
    • At least two compatible implementations (including at least one in open source) plus repeatable example scenes
    • Layer, ParticleSystems, RigidBodyPhysics, Shaders, TODO others
    • TransformSensor node: IGD and old Cortona
    • Note that it is not a requirement that all features and capabilities in X3D V3.3 are included in V4.0
  • Is it necessary for Layout component to be deprecated or improved?
  • Are there other features or capabilities that should not or are not able to move into V4.0?

Open Questions

  • Are MAR abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM/Cobweb issues?
  • Are the previously X3D Layer/Layering components compatible with HTML5 overlay model? Are they still needed, perhaps for multiscreen or CAVE support?
  • Mashup and interoperability support: is anything else needed for broader use with the Web? YouTube etc.

Related Work

Much careful planning is involved, we are working to ensure that X3D version 4 can be coherently advanced in combination with a coordinated set of steadily evolving ISO/IEC standards.

  • X3D Efficient Binary Encoding (EBE). This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings. See also SRC format (Web3D 2014)and ExternalGeometry node in InstantPlayer and X3DOM
  • X3D JavaScript Object Notation (JSON) Encoding. This work is proceeding in parallel. X3D version 4 must maintain compatibility with all encodings.
  • X3D version 4.0 (HTML5/X3D DOM). This work is proceeding in parallel. X3D version 4 support is expected.
  • X3D version 4.1 (Mixed and Augmented Reality). Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation occurs throughout.

Technologies and activities that relate to X3D version 4 are:

  • WebVR "bringing virtual reality to the web" - standardize the interface to VR displays and controllers
  • W3C's Declarative WebVR Community Group formed to developed a declarative 3D standard for WebVR
  • three.js, a JavaScript library
  • A-Frame "a web framework for building virtual reality experiences"
  • XML3D " seamless integration of 3D content into HTML pages"

Timeline (new section)

  1. links to guiding Web3D pages on spec strategy and process,
  2. link to status tracking spreadsheet,
  3. we effectively have a Web3D/ISO Working Draft (WD) now,
  4. we continue adding components/nodes via working group process,
  5. (currently) Mantis is where issues, draft spec functionality and design tradeoffs are captured, reviewed and approved,
  6. Apply new prose sections in github spec repository (by Dick and I, many improvements occurred this week),
  7. (suggested) Web3D announces X3D v4 Working Draft availability at Web3D & SIGGRAPH 2019 conferences,
  8. TODO consider whether that is a public release to encourage engagement - or not.
  9. Working Group continues to add nodes and components,
  10. Excerpted draft spec and implementation details posted for public comment on a per-component basis ~monthly,
  11. (suggested date) Web3D announces plans to close additions to X3Dv4 on 16 DEC 2019
  12. +1 month, final public comments period and editorial work, member review, Board review and approval
  13. Web3D submits New Work Item Proposal (NWIP) and Committee Draft (CD) to ISO
  14. implement, evaluate examples, refine, resolve all related issues
  15. (suggested date) Web3D approves, submits X3Dv4 Draft International Spec DIS to ISO at Web3D 2020
  16. ISO dates/deadline for DIS/FDIS/IS proceed
  17. Work begins on X3Dv4.1 Working Draft (WD)

TODO: is an annual cycle possible?

Schedule (old section, review and merge with Timeline)

ISO Considerations

  • Deciding readiness for ISO New Work Item Proposal (NWIP): we need Committee Draft (CD) specification prose for each planned capability.
  • Web3D Consortium is not locked into an annual schedule, ISO handling is flexible.
  • Once the NWIP is approved, ISO rules for schedule and review are established.

Execution goals

  • Review progress during monthly calls, Web3D Conference, and SIGGRAPH Conference.
  • We are continuing a monthly review schedule for submissions so that we can build out X3D version 4 one component at a time.
  • We are planning to have a 1-year deadline for completion of CD specification prose, rather than wait until all possible version 4 work is ready.
  • Web3D Consortium members and public review when a final draft specification is ready to proceed to ISO.
  • Any new components not meeting Web3D deadlines might be a candidate for deferral to V4.1. Or considered not ready.

Progress

  • Active development of X3D, X3DOM and Cobweb content is tracking HTML 5 capabilities now
  • We participate and contribute to the W3C Community Group for Declarative 3D
Retrieved from "http://web3dconsortium.org/wiki/index.php?title=X3D_version_4.0_Development&oldid=9787"