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.

The modern display environment is significantly more powerful and robust than before. Much content is viewed on a mobile device in a browser. Today's browsers includes support for 3D content using X3DOM, three.js, and other libraries. It is expected that current content be near cinematic in quality (modeling, appearance, and animation) while retaining all of the interaction that is customary on a web page. It is expected that these capabilities will continue to grow and exceed forecasts for the future. It is likely that the user's environment in 20 years is significantly different than today's environment of HTML5, WebGL, and JavaScript. If X3D does not stay current in the environment, it will stop being a viable format and eventually the old content will suffer digital rot.

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