3D File Formats
As we begin to witness the ascent of mixed reality into the next generation primary human-computer interaction environment it’s not entirely unreasonable to wonder how the existing infrastructure for 3D graphics would bear the load of ubiquitous usage. I’m thinking about file interchange and runtime formats which have a tax associated with them in that in order to develop or use any kind of 3D software pipeline there is inherently the issue of how to use different formats, how to convert between them and how to do all of this whilst retaining the features you need for the job in hand. These are implementation details that we could do without and need to be enveloped into the infrastructure if we are going to move up an abstraction layer. Over the last 30 years or so any 3D project will have been concerned with low-level details about how to interchange 3D scenes, moving assets from one tool to another with the plethora of proprietary formats and converters, etc, etc. Also, each industry vertical has resulted in the expansion of specific creation tools and formats. If there was one accepted, open and standard format for this it would free up the time to think about more productive things.
At some point in the near future a content creator will be able to create using an immersive display technology, so the content could be there with them in their work space in 3D, and use natural inputs collected by sensors in the real world. They could interact with the digital content in a natural way, like a sculptor with a block of clay, or some yet-to-be-discovered new way enabled by the technology or a combination of both. Either way, it is vital that they are not hampered by details such as how the data is stored. So, enter into the mix glTF, billed as “the jpeg of 3D” serves to fulfil this role as a complete 3D scene representation. We are seeing momentum in the industry for glTF; we can load them into Office products, Simplygon, Modo and Blender support is available just to name a few (for many more see https://www.khronos.org/gltf/)
Now, glTF stands for graphics library transmission format and the first two letters seem to suggest an affinity to OpenGL and whilst true that its roots lie with OpenGL there is nothing that ties the format to any particular graphics library. Whilst there are plenty of open source samples of glTF loaders/viewers for WebGL; BabylonJS, three.js, etc. there doesn’t seem to be too many for DirectX.
The sample viewer, written in C++ uses DirectX11 to render a glTF file. The sample application itself started as a way for me to understand the file format better and originally was just a glTF file parser but I gradually added features and will continue to do so. It is fundamentally a port from the Khronos sample Physically-Based Rendering in glTF 2.0 using WebGL- https://github.com/KhronosGroup/glTF-WebGL-PBR which details the physically-based rendering approach employed by glTF. Also, you can find the glTF 2.0 specification here https://github.com/KhronosGroup/glTF/tree/master/specification/2.0 for reference and comprehensive documentation.
The code for this sample is here https://github.com/Microsoft/glTF-DXViewer and I will go over some of the more interesting implementation details in subsequent posts.