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.

This is one in a series examining the purpose of X3D - where is it's niche in the electronic ecosystem and what function does it perform. The series also looks at where X3D needs to evolve to best serve the ecosystem. This post looks at animation. It was motivated by issues involving deformable skins that are needed to animate non-mechanical models.

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.

X3D is the ISO standard for the display of 3D graphics on the Web (ISO/IEC 19775). Until the last year, it was necessary to have use a plug-in or specialized application to display and interact with 3D objects. In late 2014, the browser builders released versions of their browsers that provided a JavaScript interface to the underyling graphics system of your computer. This interface is called WebGL and is part of most HTML5 implementations. There are several different libraries that provide a simplier interface to the graphics.

Events in X3D are the means for generating and handling behaviors. All changes in the state (including geometry, appearance, animation; but not animated images) are because at least one event was generated and processed. Events can be generated by timers, user interactions, response to other events, or from external sources. Events are routed fro a particular field of a node to another field of a different node. This cycle repeats throughout the time the scene is running. 

This post follows X3D Futures: Structure of the Next Version and uses concepts and descriptions presented there. It also assumes the presentation environment is an HTML5 compatible browser.

I have been doing a lot of thinking and talking with people working in computer-based 3D graphics to determine what the next generation of X3D should look like. There are important considerations and practices that need to be addressed. This post is an attempt to summarize the current state of X3D and the industry (primarily non-X3D) process of creating 3D scene. The next part will outline some of the options for the next generation.

In starting any new effort, it is important to identify the goals of the project. Goals are important because they provide a focus for the most desired outcome. They are not necessarily the destination of a project, as there are a number of factors that may limit (or expand) the initial goals.

I am working on developing the standard for the next generation of declarative 3D graphics. The current version is called X3D. At this time that name I am using for this is X3D V4. Final naming is not up to me.

For 20 years, the Web3D Consortium has developed and maintained a open, royalty free, ISO ratified and well documented standardized markup language for transmitting and displaying 3D content on the web called X3D.