Purpose of X3D - Architecture
This is the third in a series discussing the next generation of X3D. The current architecture of X3D does not support the industry standards in modeling, archival, and user experience. It uses a single primary file with additional external resources loaded as needed including other X3D files or media (images, audio, video, and scripts). The capabilities made available in the X3D files are either insufficient (e.g., lack of deformable skin animation) or in conflict with the major display environment (e.g., Scripts). This post describes a systems architecture with implications for content architecture that addresses these issues.
The current systems architecture of X3D is a file that is the archive, transmission, and display format of the content. The file can exist in several different encodings, but all encodings contain the same information. While this is good to ensure a lossless conversion process, it does not tailor the content to the best use of the medium involved.
The needs of archival storage of content are different than what is required to provide a modern user experience, especially and time passes and the expectations for user experience evolve. Archival storage needs an architecture that is durable, understandable, and probably self-documenting. Vinton G. Cerf in the October 2016 issue of Communications of ACM [1] laments that while significant art and cultural artifacts are available from as far back as 17,300 years ago, our current content is turning to unusable and perhaps unreadable dust during our lives.
User experience is a quickly evolving environment. In under 10 years, the mobile market has gone from a new device introduction (iPhone in 2007) to full head mounted displays. The expectation of users viewing 3D has changed during that period from 3D objects displayed on a flat screen to full immersive audio-visual environments with head tracking and hand devices. The biggest market for 3D is on mobile devices. The biggest market for VR is on mobile devices with cardboard (or equivalent). Architecture (both systems and content) that support full archival will struggle to simultaneously support display.
The proposed systems architecture is to split the archival and display into two separate categories. A transmission category is the bridge that connects the two. The Display X3D supports content that is compatible with the current user experience. X3D content that is not compatible is handled by the transmission category and transformed to a format that is compatible. The goal is to have most content be automatically transformed from its initial format to a display format.
References:
[1] http://cacm.acm.org/magazines/2016/10/207755-were-going-backward/fulltext