Other formats overview:
Introduction
Virtual Reality Modeling Language (VRML) was created in the mid-1990s as a format to put 3D scenes on web pages. In 1997 a second version of the format was designed and it was standardized by ISO. It didn't see widespread use though, because the bandwidth was quite limited at the time. In the early 2000s the successor to VRML, named X3D (which stands for Extensible 3D graphics), was released with the same goal of integration of 3D graphics on the web. Its specification has evolved since, so X3D now has a larger scope than VRML did before, supporting various effects obtainable within the 3D graphics pipeline.
Despite the slow adoption of the formats in the area of integration of 3D graphics into web pages, the VRML and X3D have seen widespread use as neutral exchange formats for mesh models, in particular models created with CAD software. This is due to the fact that both formats are open and feature-rich.
Technical details
VRML and X3D are quite closely related. Models in both formats are typically represented with text files. They are composed of nodes, each of which carries some type of information about the model, such as the geometry, its placement, appearance, model structure, etc. VRML features a distinctive syntax (see Fig. 1), which was inherited from the data model of Open Inventor software by Silicon Graphics. X3D, on the other hand, is usually written in XML (see Fig. 2). Even though figures 1 and 2 were created from different models, one can readily see the similarities in node types and the fields the nodes have. There are other persistence forms for both formats (gzip-compressed for both VRML and X3D, VRML-like and binary for X3D only), but they are not nearly as common as the main ones depicted below.
Strengths and weaknesses
VRML and X3D have a wide array of capabilities. Naturally, they both support 3D polygonal geometry (face sets and line sets), materials and textures. The meshes are indexed, meaning that their topology can be kept intact (unlike in STL), they can include arbitrary polygons (not just triangles) and they can carry all the vital attributes - vertex normals, vertex colors, and texture coordinates. LODs are supported and there is an ability to define the hierarchical structure of the model and attach transformations to its portions. Further, X3D provides the ability to store metadata in the form of key-value pairs. This already ticks a lot of boxes when it comes to a neutral exchange format. When one considers mesh data exchange, there isn't much else to require.
But VRML and X3D were designed with the intention to describe virtual interactive worlds. There is much more to an interactive world than just 3D geometry, structure, and metadata, so VRML also offered features such as setup of properties of the viewer's avatar, keyframe-based animation, lighting, references to audio, event system, and support for scripting to take the interactivity to the max. X3D went even further, featuring support for shaders, particle effects, volume rendering, and rigid body physics. When one considers a 3D graphics workflow, which just happens to use CAD models as assets, this is quite a nice value proposition. Fig. 3 illustrates a few basic interactivity features that can be encoded in the VRML and X3D.
Source: X3D examples archive
Source: X3D examples archive
Source: X3D examples archive
Since VRML was used for CAD data exchange, X3D sought to extend that way as well, and it was enriched with features specific to the computer-aided design domain, such as support for NURBS and a mechanism to designate elements of the model using CAD terminology of assemblies, parts, and faces. Granted, these capabilities do not qualify as a fully-fledged B-Rep data model and are more of a tool to augment the meshes and nodes with CAD semantics.
Both VRML and X3D feature a neat system, where a certain portion of the model can be identified with a DEF statement and later instantiated multiple times with a USE statement, kind of like a macro. Each USE statement includes only the name of a DEF, thus cutting down on the file size through reuse of the object definitions. Another mechanism in the same vein is the facility of prototypes - a built-in capability to define your own nodes in terms of already available ones. The key difference from the DEF/USE is the ability to define parameters for your nodes and include them in the event processing.
Still, even with all these capabilities, VRML and especially X3D are far from being the industry standard, both in CAD and general 3D graphics space. Despite the open specifications and freely available converter libraries, the support across 3D apps is rather spotty. VRML can be encountered as one of the import or export options quite often, the same can't be said for X3D. Both formats have multiple persistence options, but are effectively text-based, with usual consequences - number precision limitations and file sizes larger than a binary format like JT can achieve. In summary, it makes sense to use VRML and X3D if you need a capable format to store mesh models while preserving all the mesh attributes and model hierarchy. X3D is a better choice if the models also contain metadata. However, the software that participates in this data workflow has to be carefully analyzed to ensure that all the required features of these formats are supported.
Example model:
Further reading
CAD Exchanger SDK / VRML converter