468 V Transfers
32.2.1 Goals and Features
Computer graphics presents an interesting paradox stated by Blinn’s law: “As tech-
nology advances, rendering time remains constant.” Performance is and always will
be a key requirement when building a CG application. Therefore, geometry storage
is not an exception. We deﬁne a few key points for a geometry ﬁle format suitable
for a typical OpenGL application. Generally geometry data is stored once and for all
during the asset creation pipeline and potentially read many times at runtime, so the
format should be optimized to follow this use case.
Full scene storage. A good format will offer the possibility either to use a ﬁle for
each shape or to consolidate a full scene into only a few ﬁles. Therefore, a b asic scene
structure is required. A scene should at least feature, meshes, transforms, lights, and
basic shading data like diffuse color and specular coefﬁcient. Meshes can be either
static, or animated, using keyframes or skinning.
No transformation at runtime. Data stored on the disk should be kept as close
as possible as the data used to feed the OpenGL Vertex Buffer API. Ideally, the initial
deserialized buffer should be enough. Runtime transformation of data should be kept
for dynamic geometry only. For example, a mesh should be stored using only trian-
gles, and vertices with multiple normals should be duplicated. This requires more
computation when writing geometry but considerably reduces loading times. There
are trade-offs when precomputing transformations directly into the ﬁle, as it increases
ﬁle size. The cost of loading the ﬁle might surpass the cost of transforming geometry,
especially if it is stored on a slow media or streamed across the network. Moreover,
some transformations, like subdivision sur faces and level-of-detail, are generally not
uniformly applied on the whole scene and therefore might not be suited for precom-
putation in the ﬁle.
Arbitrary access. The ﬁle-format-reading API should be able to only load par t of
the ﬁle. For example, we should allow it to quickly iterate on all the stored bounding
boxes, then only load visible meshes. The other advantage for offering arbitrary access
to shapes is to enable the use of out-of-core algorithms by loading and discarding data
Scene exporting. In game and ﬁlm industries, sets and characters are generally
built in commercial or homegrown editors, often using their own geometry formats.
Thus, the asset-creation pipeline should be supported by robust exporting procedures
from the editor format to the rendering-engine or game-engine format. Due to the
sheer amount of produced data, per-shape tweaking, and human intervention in
general should not b e necessary during this stage.