Difference between revisions of "X3D version 4.0 Development"

Revision as of 17:27, 25 February 2016

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 BOF meetings.

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

• Summary slides here (Oct 2013) summarize this steadily continuing effort
• Major technology under consideration: HTML5, Declarative 3D, X3DOM, and possibly CSS
• Major technology under consideration: Augmented Reality Continuum (ARC) (being renamed as Mixed Augmented Reality MAR)
• Relaxing prior design constraints can enable a broader new basis for X3D integration
• Normalizing interaction semantics with HTML5 - now a stable W3C Recommendation - can further open up X3D for the vast majority of Web authors

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

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

• Is it necessary for Layout component to be deprecated or improved?

Candidate capabilities

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.

• Appearance
  • Images: recommended formats for imagery and video (.gif .bmp .svg .flv .exr .hdr etc.). Consider QR codes as a first-class image type since it contains imagery and information, especially useful in Mixed Augmented Reality (MAR) applications
  • Materials: advanced parameters
  • 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.
• Audio and video: adding royalty-free formats, streamability, disabling attenuation, 3D aural spatialization using reflection from simple geometry (such as RESOUND or Web Audio API)
• Computer Aided Design (CAD) Interactive Profile, to include:
  • CADInterchange profile plus FillProperties/LineProperties, primitive/Geometry2D nodes, Extrusion, NURBS, ClipPlane
  • Part selection/animation, 3D printing, Compressed Binary Encoding (CBE), possibly annotations component
  • Building Information Models (BIM), Architecture Engineering Construction (AEC), Physical Sensors
• ECMAScript (Javascript) specification revision compatibility with X3D scripting; possibly add C# or Python support
• 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
  • Possibly Virtual Reality Peripheral Network (VRPN), gesture recognition (such as KINECT, LEAP), etc.
  • Support for arbitrary sensors and user interaction devices
• Geometry: point size (or perspective rendering), progressive meshes (suitable for both compression and streaming), 3D ExtrudedText, support for Web typography using Web Open Fonts Format (WOFF)
• Geospatial X3D component
  • Enhanced Geospatial Component - spatial reference frame (SRF) and KML support, OGC 3D Portrayal, GpsSensor, OpenLayer mashups
  • GeoSet collection of adjacent GeoElevationGrid nodes to enable proper computation of normals for edge boundaries of adjacent grids
• Humanoid Animation (H-Anim) anatomical correctness for skeleton and skinning, motion capture (mocap) and playback, interchangeable avatars, animation for hands feet and faces
• 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 capabilities
  • Annotations component and metadata usage
  • Archival 3D medical records, potential emphasis on Traumatic brain injury (TBI) volume visualization
  • Haptics component for force feedback
  • Soft-body physics component to complement rigid-body physics component
• 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:
  • 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., impl. in X3DOM and InstantReality)

All suggestions and recommendations are welcome. Component improvements and additions are approved by Web3D Consortium members.

• TODO: Which experimental nodes are ready? Candidates include Fraunhofer, Bit Management, other members and working groups?
• TODO: articulate Big Data and Cloud, server-side visualization, related issues

Please contact us if you think additional technologies need to be considered.

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

• As with all other X3D components, all work is defined in the abstract specification has corresponding file encodings (.x3d .x3dv .x3db) and language bindings (ECMAScript and Java).
• Compatibility concerns include evolutionary efforts to upgrade the X3D Compressed Binary Encoding (CBE), as described in the X3D Compressed Binary Encoding Call For Contributions.
• ECMAScript (JavaScript) support in X3D needs to be upgraded to the new standard for that rapidly improving programming language.
  • ISO/IEC 16262:2011 Information technology — ECMAScript language specification (.zip download)
  • Downloadable from ISO Publicly Available Standards site without charge
  • This relates to 19777-1 Part 2, X3D Scene Access Interface (SAI) language bindings for EcmaScript

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.

Open questions

• Are ARC abstract design and X3D AR proposals sufficiently mature to enable integration with HTML5/Declarative 3D/X3DOM 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 Augmented Reality). Nodes and capabilities in this arena will build on v4.0 and HTML5. Experimentation, evolution and evaluation

occurs throughout.

Schedule

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 as v3.5. 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