Graphics Reference
In-Depth Information
emanate from the same group, there is no easy way for a developer to take assets
and use them in their engine. Two major issues create a gap. The content has to
be processed to fit within the data format that is required by the GL APIs, and
the content has to be formatted for transmission and parsing performance.
The idea of creating a new spec focusing on the runtime use rather than
content-creation needs was raised a few years ago in the working group, and it
finally resulted in the work done by the authors of this chapter to introduce
glTF—the GL Transmission Format. By analogy, this format is in the same
category as the audio and video formats, such as MP3 and MPEG, that have been
key in supporting the consumption of media content and dramatically impacted
the ecosystem and consumers. We hope that glTF will help 3D content be easily
deployed and consumed.
Although significant work has been done, at the time this topic goes to press,
glTF is still a work in progress; it is not an ocial Khronos-ratified specification
yet.
2.3 Goals
2.3.1 Easy and E
cient to Render
A glTF asset is composed of a .json file for the structure, .bin files for numerical
data, .glsl (text) files for shaders, and image files. The .json file references the
other files. The .bin files store data as little endian since this covers the vast
majority of the market.
glTF uses JSON to define the node hierarchy, materials, lights, and cameras
and the binary blobs to store geometry and textures. (See Figure 2.1.) JSON
is cross-platform, compact, and readable, allows validation, and minifies and
compresses well. Binary blobs, unlike JSON data, allow ecient creation of GL
buffers and textures since they require no additional parsing, except perhaps
decompression. glTF specifically targets the GL APIs, so the runtime engine can
eciently load and render the asset because most of the data processing is done
by the content pipeline.
2.3.2 Balanced Feature Set and Extensible
Only allowing features directly supported by the GL APIs would make glTF too
limited. Likewise, including all features in interchange formats would make glTF
too complex for runtime use. We carefully selected features, such as the node
hierarchy, materials, animation, and skinning, to balance the trade-offs between
simplicity and completeness.
Unlike interchange formats, which need to preserve data used for authoring,
glTF only preserves data used for rendering. For example, COLLADA allows
