3D FILE FORMATS FOR GRAPHICS PROJECTS
Richard P. Simpson, Catherine V. Stringfellow
Computer Science Department
Midwestern State University
3410 Taft Blvd.
Wichita Falls, TX 76308
richard.simpson@mwsu.edu, catherine.stringfellow@mwsu.edu
Abstract
Although the standard graphics class is often taught from a theoretical
standpoint, a student’s education is inevitably enhanced by carefully
designed programming projects. Many of the projects found in textbooks
are artificial and as a result are not very interesting to serious students of
graphics. In an attempt to spice up the projects a number of real world 3D
file formats were investigated to determine those that were appropriate for
use in undergraduate graphics projects. This paper discusses three such
projects, together with a review of the associated file format.
Introduction
Technology in support of graphics is one of the fastest changing areas of computing.
Consequently teaching graphics at a university level forces faculty, to modify the level of
presentation as well as the level of projects. Over the years graphics classes were often
taught from the ground up even when API’s such as OpenGL were readily available. As
graphics became more complicated at the higher levels, earlier low level approaches to
teaching had to be dropped, for example faculty seldom have time to teach Breshenham’s
algorithm. Faculty teach graphics classes by initially assuming the existence of an API
that is constantly moving further away from the underlying hardware. The direct
consequence of this, from the student perspective, is projects can be more leading edge.
This implies that completed well designed projects are often impressive to the students
themselves, their friends, as well as their professors.
Students like to feel that they are working on relevant real world problems. One of the
easiest ways to construct relevant projects, using the current API, is through the use of
3D file formats. Almost every 3D application has one or more in-house 3D file formats
associated with it. Modeling, architectural design, and molecular visualization are just a
few of the program categories that require 3D file formats. These formats are really the
glue between different 3D applications. Understanding these 3D file formats is one way
to understand 3D data structures used to hold mesh information. Although these formats
vary widely, a study of several selected cases will give a flavor of what is usually stored
in these files. Since the file types associated with high-end modeling packages, such as
Lightwave and Maya, are often complicated, it is advantageous to first look at files
generated by less ambitious applications. This paper will look at three graphics projects
and the file formats used in those projects. The formats include one for representing the
structure of 3D molecules, one that represents 3D meshes, and one that represents terrain
data. The information and tools that go with these files is easily accessible on the web.
Three Dimensional Molecule Viewer
The first project involves the development of a three dimensional molecule viewer. A
variety of molecule visualization programs, including RasMol, RasWin, Chime, Cn3D,
and ChemDraw, are found on the web [1, 5, 10]. In analyzing these applications a variety
of well-known molecule definition file formats such as PDB and MOL were encountered.
Even though the programs can read and render a variety of molecule format files, this
paper focuses on MOL since it is very simple to understand and does not have the
generality and associated complication found in PDB file. The format is familiar enough
from a graphics perspective that not having chemistry course work prior to working on
this project appears not to be a hindrance. A complete MOL file specification, entitled
ctfile.pdf, can be found at the Elsevier MDL (Molecular Design Ltd) company web site
[4]. (Note that there is another program called MOLDRAW that uses an in-house format
that also uses .mol as its extension. This is not the same file format as MDL’s mol, so
make sure you extract the correct definitions from the web.) Figure 1 show an example
of a file definition for L-Alinine.mol and its associated rendering.
L-Alanine
WLViewer
6 5 0 0
-0.6622
0.6220
-0.7207
-1.8622
0.6220
1.9464
1 2 1 0
1 3 1 1
1 4 1 0
2 5 2 0
2 6 1 0
M END
3D
1 0
0.5342
-0.3000
2.0817
-0.3695
-1.8037
0.4244
0 0
0 0
0 0
0 0
0 0
0
3 V2000
0.0000 C 0 0
0.0000 C 0 0
0.0000 C 1 0
0.0000 N 0 3
0.0000 O 0 0
0.0000 O 0 5
//Bond Block
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
// Counts line
0 // Atom Block
0
0
0
0
0
Figure 1. L-Alinine File Definition
Although each line is carefully defined in the CTfile format file, there are only a few
lines that a graphics application developer need to know. The line
6 5 0 0 1 0
3 V2000
is the Counts line and it contains the number of atoms, bonds, etc. This file contains six
lines defining atom locations and five lines containing bond connectivity. Following this
line is the section known as the Atom Block. It contains three floating point numbers
indicating the atoms’ relative location in 3D space, followed by a single letter specifying
the atom type, as well as other information, such as mass difference, not used in our
projects. The bond block contains the connectivity information. The first two values in
each bond definition assume that the Atom information is stored in an array subscripted
from 1 to the number of atoms. For example, the fourth line indicates that the first
carbon atom (C) is connected to the Nitrogen atom (N) via a single bond as given by the
third value in the list. A 1 is a single bond, a 2 is a double bond, a 3 is a triple and a 4
represents aromatic bonds. The remaining values are not used in the project.
The project requires the student to build an application that reads in any MDL mol file
and displays the molecule in Ball/Stick form as shown in Figure 1. Scaling, centering,
rotating and zooming the object are basic requirements. Extensions for advanced work
involve other display forms, such as, wireframe, spacefill. Creating a vibrating molecule
is also a nice extension. Figure 2 shows that graphically these are not difficult
extensions. The space fill form draws spheres of larger radii, whereas the stick mode
draws equal sized cylinders between and 3D coordinate locations of the atoms.
Figure 2. Several Molecule Display Options
This project uses only spheres and cylinders, easily rendered using primitive display
functions such as gluCylinder() in OpenGL [6]. The project can be given early in a
graphics course, right after rotation and translation transforms are completed. (As a side
note, the command auxSolidCylinder() can be difficult to use since it draws the cylinder
in an unusual position that needs to be corrected via translation. Warning the students of
this can save a lot of problems.) The most difficult part of this project is the proper size,
rotation and placement of the cylinderical bonds. A short lecture on this is advisable
about a week (or until they complain in class) after the project is given. Letting the
student struggle for a while before helping them with a solution is critical to their proper
understanding of a difficult concept. This is one of those rare projects that is just about at
the perfect level of difficulty. Upon completion, students proudly demonstrate their
awesome projects to other majors who inadvertly pass by in the lab.
3D Mesh Viewer
The second project requires the student to read in mesh data from a 3D file and display
the object. Centering, zooming, and rotating are as usual required. The graphics world
is overrun with a huge collection of 3D mesh file formats. Almost every 3D application
from games to modelers such as LightWave 3D, 3D Studio Max, Maya, etc., have their
own in-house file format. There have even been applications, such as NuGraf,
developed specifically to perform the complicated conversion between these formats.
Quick3D (.q3o), PLY(.ply) and Milkshape(ascii and .ms3d) are some of the formats that
were previously used in projects [3, 8, 9]. Changing the format between semesters
greatly cuts down the temptation to copy past projects. The .q3o file format that
Quick3D uses is a good one to use in a first project of this type. It is complicated enough
to be able display interesting models. In addition, its structure allows a project to be done
in stages. A first project might be to read in a single mesh and display it not using any
embedded material information. Later projects can include multiple meshes together
with texturing. The .q3o data file format begins with a header and has the following
structure.
struct OBJFILEHEADER{
char signature[8];
char version[2];
int numberMeshes;
int numberMaterials;
int numberTextures;
}
A simple way to read in the header and other information from the file uses the command
fread(). The above header can be read and displayed in a single block using the
following sample code.
OBJFILEHEADER head;
fread(&head,sizeof(OBJFILEHEADER),1,objectfile);
cout<<"HEADER INFORMATION"<<endl;
cout<<"Headersize="<<sizeof(OBJFILEHEADER)<<endl;
int num_meshes=head.numMeshes;
numberMeshes=head.numMeshes;
cout<<"Number of meshes:"<<num_meshes<<endl;
// Create space to hold these meshes
int num_mats=head.numMaterials;
cout<<"Number of Materials: "<<num_mats<<endl;
int num_tex=head.numTextures;
cout<<"Number of Textures: "<<num_tex<<endl;
numberTextures=num_tex;
It is very important that the students incrementally develop a load function for .q3o files,
so as each section is read it may be scrutinized for error. Some errors are very difficult to
unravel and incremental dumping of the read data is critical to success.
Each .q3o file may contain one or more mesh definition. A mesh is defined as follows:
MESH{
long numberVertices;
vertex vertices[numberVertices];
long numberFaces;
short faceShapes[numberFaces];
face faces[numberFaces]
int materialIndices[numberFaces];
long numberNormals;
normal normals[numberNormals];
long numberTextureCoordinates;
texUV textureCoordinates[numberTextureCoordinates];
face textureIndices[numberFaces];
vertex centerOfMass;
float boundingBox[6];
}
This data can be read easily using fread(), as well.
fread(&numberVertices,4,1,objectfile);
cout<<"Number of vertices="<<numberVertices<<endl;
vertexArrayPtr=new float[numberVertices*3];
//vertex is 3 floats
fread(vertexArrayPtr,numberVertices*12,1,objectfile); //Read them
The rest of the data is extracted similarly and loaded into the appropriate object variables.
From this structure, it is clear that Quick3D uses standard methods for storing a mesh.
We see that a vertex array, a face array and a normal array hold the geometric
information. The face shape array is a minor addition that allows each polygon in the
mesh to have a different number of sides. Once this data is loaded it is a simple matter to
write a display routine in, for example OpenGL to render the mesh. When a student
completes the mesh drawing phase of a project, it requires little additional work to add
material support, as well as texturing, both of which are included in the file format. Even
though the file seems to contain a large amount of data, the structure could be much more
complex and have information concerning animation, etc., in the file.
Three Dimensional Terrain Rendering
A very nice terrain generation and rendering program called
Terragen has been around for some time. Although it is capable
of photorealistic landscape visualization and special effects, the
main interest lies in the file format used. Rendering the data is
the students problem. The company, Planetside Software, is
presently developing Terragen 2 [7]. This is a new version of
Terragen that is much more powerful.
Figure 3.
For the purposes of student projects the original Terragen is quite suitable. This program
rapidly generates terrains that can be saved as a .ter file. It even has a 3D Preview that
allows one to do a simple fly-over of the generated terrain. This preview is the
foundation of a nice project. The students are requested to read in a .ter file and render it
in real time so that one can fly over the terrain. A .ter file is a binary file beginning with
a simple header containing identification and size information which is followed by a list
of (x,y,z) points. A .ter file is really nothing more that a collection of height field data for
the terrain and its file specification can be found on Planetside’s web site [7]. This is an
example of a file format that is easy to read and hard to render. In their attempt to render
the height field the students rapidly begin to observe the limitations of present hardware
as well as their algorithm. Version 1 of the project is in their hands. Some just render all
the triangles in a loop, while others get a little tricky and render the entire terrain using
triangle strips. In other words the algorithm for rendering the terrain selected by the
student is seldom very efficient. It takes way too long to render each frame, resulting in a
jerky display. After the students become appropriately upset with their inability to create
a cool “flight simulator” they are ready to listen to a more serious approach.
A well-known web site called the Virtual Terrain Project [11] contains a lot of
information that is well outside of a standard first course in graphics, so is generally
covered only in a second course on Game Graphics, which covers algorithms associated
with real-time 3D graphics. In this course, a project continues with the above problem
by studying and implementing one of the LOD (level of detail) algorithms such as
ROAM (Real-time Optimally Adapting Meshes )[2].
Conclusion
The use of real work files in student products greatly increases the relevance of the
projects, as well as the interest of students. The projects are naturally more general and
the execution of the programs on a set of test data files will quickly uncover bugs. The
data sets of a wide range of complexities are easy to generate using other 3D applications
or by downloading these from the web. Knowledge of graphics applications and their file
formats can often increase the confidence level of many of our students.
References
[1] Chem Draw, http://www.adeptscience.co.uk/products/lab/chemoffice/chemdraw,
Sept. 29, 2006.
[2] Duchaineau, D., Wolinsky, M., Sigeti, D., Mille, M., Aldrich, C., and MineevWeinstein, M.,”Roaming terrain: Real-time optimally adapting meshes,”
Proceedings of IEEE Conference on Visualization, Phoenix, AZ, Oct. 1997, pp. 81-88
[3] chUmbaLum sOft, http://www.swissquake.ch/chumbalum-soft/, Sept. 29, 2006.
[4] Molecular Design Ltd, http://www.mdli.com/downloads/public/ctfile/ctfile.jsp, Sept.
29, 2006.
[5] Cn3D 4.1 Homepage, National Center for Biotechnology Information,
http://130.14.29.110/Structure/CN3D/cn3d.shtml, Sept. 29, 2006
[6] Shreiner, D., Woo, M., Neider, J., and Davis, T., OpenGl Programming Guide,
Fourth Edition, Addison Wesley, 2004.
[7] Plantetside, the home of Terragen, http://www.planetside.co.uk/, Sept. 29, 2006.
[8] Nehab, D., RPly: ANSI C library for PLY file format,
http://www.cs.princeton.edu/~diego/professional/rply/, Sept. 29, 2006.
[9] Sherman, B., Quick3D, http://www.quick3d.com/, Sept. 29, 2006.
[10] Bernstein, H., RasMol and Open RasMol, http://www.openrasmol.org/, Sept. 29,
2006.
[11] Virtual Terrain Project, http://www.vterrain.org/index.html, Sept. 29, 2006.