This page presents examples and summarizes progress in preparing web 3D visualization of CAD models, using X3D/X3DOM standards and glTF (in particular, the glTF binary extension) to store, transmit, and load large amount of geometric mesh data.

The models presented were translated into X3D from STEP files. The boundary-representation and product assembly structure in the original STEP file is preserved in the X3D translation using the X3D CADGeometry component.

• faces (STEP Part 42 entity advanced_face ) in the STEP file are are 1-1 mapped to CADFace nodes in the X3D file.
• The part-assembly tree in the original STEP file is mapped into a hierarchy of CADAssembly/CADPart X3D nodes.

The results are X3D files with large number of X3D Shape nodes for the faces, most of which have geometry defined by X3D IndexedTriangleSet nodes. It is a design goal of this work to retain this structure rather than aggregate the meshes. Keeping the faces as individual Shape nodes will allow more detailed coloring and interactivity with the model.

The three models described below were translated from STEP files and representing three levels of complexity in terms of the total number of faces. The links below labeled as (standard) are X3DOM files in which the faces are defined by IndexedTriangleSet nodes with standard text encoding.

The glTF specification offers the opportunity to encode 3D content, including mesh geometry, into digital assets. The glTF binary extension specifies packaging a collection of assets into a single file. This file contains a short header, a json encoded data structure, and a BLOB (big lump of binary); the json contents section is the guide for interpreting the binary data. For the particular case of mesh data the binary buffer is interpreted as arrays of 32 bit floating point numbers as coordinates; and 16 bit unsigned integers, for vertex indices. The packaging of meshes into glTF assets offers two potential benefits:

1. Reduced total file size for storage and transmission.
2. Reduced loading time into the X3DOM canvas; as the binary mesh data structure is optimized for rendering using the WebGL API.

The X3DOM javascript library, at version 1.7.2, implements the option of loading content from glTF-binary files into X3D scenegraphs. This capability is demonstrated on the x3dom.org website here. For the case of meshes this loading is achieved with the X3DOM node ExternalGeometry. The ExternalGeometry node is not a part of the X3D standard, as of version 3.3. The ExternalGeometry node references an individual mesh in a glTF asset file through a URL locating a separate file; with conventional extension .glb; and identifying the mesh through a URL fragment identifier.

For the three demonstration cases below, an X3DOM file loading meshes from an asset file were prepared and may be rendered in WebGL enabled browsers through the links labeled glTF-binary. For these models the xhtml files pointed to by the link is much smaller since they do not contain the mesh coordinate and index data; and this mesh data is downloaded (through a javascript XMLHttpRequest call) as a glTF-binary asset file. The table entries give the combined file sized for the xhtml file and the single glTF-binary asset file.

The glTF-binary asset file for each X3D model was created using open source code implemented as a suite of XSLT 1.0 scripts and a Python 2.7 script. This code is available at X3D to glTF-binary conversions on github. This code reproduces a subset of the functionality of the aopt tool, part of the InstantReality framework.

Results and Issues

1. The packaging of meshes into glTF-binary asset file works and can be delivered in X3DOM scenes. For models with many curved surfaces (and consequently larger meshes) the total file size are reduced by approximately 50%. The DOM scripting, as demonstrated by the product-structure features in the models below, works identically across standard X3DOM files and those using glTF-binary assets.
2. The appearance of the model faces in the glTF-binary renderings follows the Appearance node from the X3DOM file, rather than the material property specified in the glTF asset. For debugging purposes the material defined in the digital asset was specified as a red emissive surface, while the rendering show that the rendered faces retain the cool silver color from the X3DOM file.
3. The planar faces in the glTF-binary models are being rendered dark (or black); see the laser__top model for a vivid example.
4. Most serious issue: The current implementation of loading glTF assets appears to request and process the digital asset file for each individual face. For example, the large file mixing_tank below contains 1763 files, and the 5.4 Mb asset file (mixing_tank.glb) is being requested from the server for each face. HTTP caching is reducing some of the network load, but there are further delays presumably from javascript handling of this significant sized blob. In short, on a standard desktop installation, the loading of the mixing_tank model below grinds to a halt after loading about 50% of the model.

Future Work

1. The first priority is to assess whether some caching of the binary asset data at the X3DOM library level can reduce the need to request and process the binary blob individually for each face.
2. Need to resolve the color rendering for planar faces. This may require defining (geometric) normal data even for the planar meshes.
3. Extend the glTF-binary packaging to include meshes defined by other X3D nodes, included IndexedFaceSet, IndexQuadSet, and the special Triangle set nodes.