O'Reilly logo

OpenGL Insights by Christophe Riccio, Patrick Cozzi

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

An OpenGL-Friendly
Geometry File Format and
Its Maya Exporter
Adrien Herubel and Venceslas Biri
32.1 Introduction
Geometry is at the heart of most computer graphics, whether film, video games, or
tools. The vast majority of props, sets, and characters rendered to the screen come
from geometry files stored in the computer hard drive.
Despite being the lowest common denominator of CG applications, there is no
de facto standard for geometry files. On the contrary, there is a plethora of both
proprietary and open formats. One of the many reasons for this state of affairs is
that each application has different requirements that are not efficiently compatible.
An out-of-core path tracer will have different needs for its geometry-storing solution
than a 3D editor or a game. Of course a kitchen-sink approach will offer all the
needed features, but probably at the cost of computational and storage efficiency.
The goal of this chapter is not to implement the ultimate geometry format. In-
stead, we will show how to tackle the problem by creating a file format suited to our
needs along with the right tools. A file format is pointless without tools for exporting
and importing but also for data-mining or conformation. Good tools enable rapid
iterations on our asset production pipeline, thus increasing productivity and enabling
better artistic impulse.
First we start by defining our feature requests for a file format suitable for the
OpenGL API. We will then confront our use cases against the feature matrix of
existing formats. In the second part, we will present the Drone format, a binary
chunk-based format, designed for efficient deserialization and serialization of a 3 D
scene. Then, in the third part, we write our first tool, a Maya exporter, introducing
the software API. Finally, a second tool is used to benchmark our file format.
467
32
468 V Transfers
32.2 Manifesto
32.2.1 Goals and Features
Computer graphics presents an interesting paradox stated by Blinns 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 define a few key points for a geometry file 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 file for
each shape or to consolidate a full scene into only a few files. 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 coefficient. 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 file, as it increases
file size. The cost of loading the file 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 file.
Arbitrary access. The file-format-reading API should be able to only load par t of
the file. 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
as needed.
Scene exporting. In game and film 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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required