Purpose of X3D
X3D and VRML have been an international standard since 1997. They define a means to model and texture 3D geometry, animate it, and provide user interaction. As an International Standard (VRML: ISO/IEC 14772, and X3D: ISO/IEC 19775-19777) these have provided extraordinarly stable and long-lasting formats. Content developed 20 years ago still runs today. That is an important legacy that should not be lost. At the other end of the timescale (today), there are environments and capabilities that could not have been imagined when the first standard was approved. X3D needs to keep a foot in the ancient past (as far as computer time goes) and current so that history is not lost.
When VRML was first developed, CPUs were slow (relative to today) and GPUs did not exist. Computations had to be kept simple, including geoemtry, lighting, and animations. Many choices were made to allow the desktops and workstations of the day to display animated interactive 3D content. There was some ground-breaking content developed - Floops (requires a VRML plugin - for example Bitmanagement's bsContact) that needs to be preservered for historical reasons. Since then a significant amount of archival content has been developed that will continue to be developed. This includes museum artifacts scanned as part of the European Union's COFORM project.
Currently, X3D exists on a computer as a file in one of the (currently) three standardized formats. It is transmitted to the client in one of those formats, and is displayed by the client in a formatted supported by the client's browser. At the time of the writing, the only plug-in browsers support the strict formatting (case sensitivity) of XML. That same class of browsers is the only one that supports the ClassicVRML or Compressed Binary format. The HTML-based browser libraries support a relaxed form of the XML format. The three stages of the content (server-based, in-transit, client-based) all use a standard X3D format (generally the same one). All design decisions (those made during specification develop and those done by the content creator) are all embedded in the file. This imposes a substantial burden on the client-display software. In the last 20 years a significant change has come to industry practice in terms of modeling, texturing, and animation. Much of this is not reflected in the current X3D specification. My blog post on "Purpose of X3D - Animation" discusses this in much more detail.
A means for X3D to stay viable and continue to support the historical content involves separating the required format support in the three functional areas - archives (including all server-based storage), transmission, and display. By separating the supported formats and features, each can be optimized for its purpose -- archival for long-term storage of 3D assests, display for staying current with user experience, and transmission for bridging the two. In a properly designed environment, all three work together without imposing excessive requirements on the developers.
Future blog posts will separately address these areas:
- Archival storage and formatting
- X3D Animation
- Display (run-time) requirements and formats
- Transmission format conversions and interfaces