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.

Current State

The current release of X3D (aka V3D V3.3) is an ISO standard that can be encoded in any one of three forms: XML, ClassicVRML, and Compressed Binary. All three encodings are ISO Standards and can be losslessly converted from one to another. ISO Standardization is very important because it allows content to be developed with very long lifetimes (50+ years). It is important that there is always a path forward so that old versions of X3D can be always displayed.

This version is an evolution of VRML V2 (from circa 1997). There are 233 nodes (+67 abstract nodes) that are structured into 31 components. There are 8 profiles designed to help the content developer and browser builders easily display a 3D scene. Most of the content is created in the Immersive profile; however, a few of the other profiles provide very important capabilities including volume rendering, CAD geometry, and Geospatial support.

X3D was developed in an era when 3D scenes were displayed in stand-alone applications or using a plug-in in a browser environment. In either of these environments, X3D was insulated from other applications, operating system, and other APIs. HTML5 added enough capabilities to allow X3D to run directly in the browser without the need for external applications (including plug-ins). This has caused an impendence mismatch in several parts of X3D, including node names (e.g., Script), event handling, and remote files. The next generation of X3D needs to resolve these issues, while continuing to support older versions.

Existing Workflow for 3D Content Creation

A large majority of 3D model and scene developers do not use X3D. To increase the adoption of X3D, it is necessary for X3D to support their development methodology. The development generally starts with small units of the final scene – the models. These are textured, rigged, animated, and exported using a standard modeling program (e.g., Maya, Blender, AutoCad). The models are imported into the scene environment and integrated with the other models and the scene structure. The scene environment for games is typically Unreal or Unity, but other environments are available. The end product of a self-contained viewable scene is created by the Scene Environment. For the most part, this is a one-way workflow from modeling to final product.

X3D capabilities encompass this entire workflow. That is one of its strengths and problems. It allows someone to work entirely in X3D; however, importing X3D can be a very complex operation. Developing X3D profiles that are similar in capability to existing industry-standard file formats for the various exchange steps would make this process easier. The primary exchange step is from the modeling program to the scene program. FBX is the format of choice for this step. The recent work with Khronos integrating SRC with glTF binary is important and very useful.

The scene environment is where most of the complex behaviors are defined. This is the area that the most complex features of X3D or the scene generation program are used. These include multiple instancing and scripting. X3D handles instancing of geometry by referencing a single instance (DEF/USE). Any change to the instance immediately modifies all referenced copies. X3D’s PROTO creates a base copy where each use creates its own instance.

Unreal creates geometry instances with a base class and individually rendered instances. This allows a change to a single instatance or changes to all instances (via base class). Blueprint in the name of Unreal's scripting language and interface. Though the details are different, the concepts are nearly identical and the features are similar.

The Preliminary Proposal for X3D V4 in HTML5 is in the next blog post.