X3D Compressed Binary Encoding Call For Contributions

Requirements

The overall requirements for the final standard are listed here. Each individual contribution is expected to provide a specific technical capability that works well within the existing framework that already includes other contributions.

• X3D Compatibility. The compressed binary encoding shall be able to encode all of the functionality described in X3D Abstract Specification.
  • This means that compressed functionality includes the full capabilities of X3D scenes.
• Interoperability. The compressed binary encoding shall contain identical information to the other X3D encodings (XML-based .x3d and ClassicVrml-based .x3dv).
  • This requirement includes identical round-trip conversion between the X3D encodings.
• Multiple, separable data types. The compressed binary encoding shall support multiple, separable media data types, including all node (element) and field (attribute) types in X3D. In particular, it shall include geometric compression for the following.
  • Geometry - polygons and surfaces, including NURBS
  • Interpolation data - spline and animation data, including particularly long sequences such as motion capture (also see Streaming requirement)
  • Textures - PixelTexture, other texture and multitexture formats (also see Bundling requirement)
  • Array Datatypes - arrays of generic and geometric data types
  • Tokens - tags, element and attribute descriptors, or field and node textual headers
• Processing Performance. The compressed binary encoding shall be easy and efficient to process in a runtime environment. Outputs must include directly typed scene-graph data structures, not just strings which might then need another parsing pass. End-to-end processing performance for construction of a scene-graph as in-memory typed data structures (i.e. decompression and deserialization) shall be superior to that offered by gzip and string parsing.
• Ease of Implementation. Binary compression algorithms shall be easy to implement, as demonstrated by the ongoing Web3D requirement for multiple implementations. Two (or more) implementations are needed for eventual advancement, including at least one open-source implementation.
• Streaming. Compressed binary encoding will operate in a variety of network-streaming environments, including http and sockets, at various (high and low) bandwidths. Local file retrieval of such files shall remain feasible and practical.
• Authorability. Compressed binary encoding shall consist of implementable compression and decompression algorithms that may be used during scene-authoring preparation, network delivery and run-time viewing.
• Compression. Compressed binary encoding algorithms will together enable effective compression of diverse datatypes. At a minimum, such algorithms shall support lossless compression. Lossy compression alternatives may also be supported. When compression results are claimed by proposal submitters, both lossless and lossy characteristics must be described and quantified.
• Security. Compressed binary encoding will optionally enable security, content protection, privacy preferences and metadata such as encryption, conditional access, and watermarking. Default solutions are those defined by the W3C Recommendations for XML Encryption and XML Signature.
• Bundling. Mechanisms for bundling multiple files (e.g. X3D scene, Inlined subscenes, image files, audio file, etc.) into a single archive file will be considered.
• Intellectual Property Rights (IPR). All technology submissions must follow the predeclaration requirements of the Web3D Consortium IPR policy in order to be considered for inclusion.