Model Space

by William Shoaff with lots of help

Contents

• Contents
• Model Space: Where The Graphics Pipeline Starts
• Primitives
• Files and Data Structures
  • File organization
  • Data organization
• Conclusions
• Bibliography

Model Space: Where The Graphics Pipeline Starts

Jim Blinn's book [Bli96] provides a vivid account of the graphics pipeline, in particular, reading chapters 13 to 18 is enlighting. Each of these chapters were originally published in IEEE Computer Graphics and Applications.

The pipeline can be interpreted as a series of coordinate spaces where objects exist. There is little agreement on the names of these spaces, but, more importantly, architectures and algorithmics may eliminate or add spaces, or change when and how certain operations are made. We will distinguish the following spaces:

Model Space (MS)

is where individual objects are defined. It is usually three dimensional Euclidean space with a right-handed orientation.

World Space (WS)

is where we seldom want to stop, but one that is conceptually useful as a collector and arranger of individual objects from their model coordinates.

View Space (VS)

is where the recorder is at the origin looking along the positive z axis. Now we're in a left-handed world.

Perspective Space (PS)

a weird place where the origin is at infinity, and points are punctured lines.

Clip Space (CS)

is simply the unit cube $0\leq x, y, z \leq 1$.

Normalized Space (NS)

is a standard space that eliminates distorting when mapping to an display device.

Device Space (DS)

is an integer grid (array indices) of pixels.

At present, we are only interested in model space. Other terms for this space are: master space or object space. In fact, there is not just one model space, but every object contained in the graphics scene is defined in its own model space. An object that appears multiple times is only defined once in its model space, but occurs multiple times in the scene graph.

The objects in which we are interested are mostly three dimensional, thus model space is most often a three dimensional Euclidean coordinate system of points denoted by $(x,\,y,\,z)$. Some objects are inherently two dimensional, for example, a playing card: For these objects, we can still use a three dimensional space with z fixed at 0. Some objects may be most easily described in systems other than the Euclidean system (e.g., cylindrical or spherical coordinates). We will not consider these special cases.

Our three dimensional Euclidean model space is right-handed. What this means is that if you hold your right hand with thumb, fore finger, and middle finger at right angles (orthogonal) to each other they form the x, y, and z axes of a model space. Diagrams of three dimensional Euclidean space appears in Figure 1. Only the positive axes are drawn from the origin. In the one on the left you are looking at the xy plane from above the xz plane and to the right of the yz plane. The diagram on the right presents a view where you are looking at the origin. It can be difficult to draw three dimensional objects on a two dimensional surface: You will need to use your imagination.

  

Figure 1: Diagrams of right-handed three dimensional Euclidean space.

  
Primitives

The primitive objects are: points, lines, and polygons: They are used to create more complex objects.

• A point is defined by a an ordered triple $(x,\,y,\,z)$. For example $(3,\,1,\,4)$ is a specific point. In model space we most often choose the most simple description of an object, and so, the canonical model space point is $(0,\,0,\,0)$.

  We will always write points in a rows:
  

  (x, y, z, w)
  
  
  . Some authors write them as columns:
  
  $$\left(\begin{array}{c}x \\ y \\ z \\ \end{array}\right).$$
  
  

• A line is defined by two (end) points $(x_0,\,y_0,\,z_0)$ and $(x_1,\,y_1,\,z_1)$. It is more appropriate to call this object a line segment, yet, we'll take a lazy approach and simply call it a line. A canonical model space line can defined by $(0,\,0,\,0)$ and $(1,\,0,\,0)$, although you may believe that other lines are more ``simple.''

• A polygon is a closed region bounded by straight lines. The points where the lines intersect are called vertices. The lines forming the polygon's border are called edges. The interior region is called a face: A polygon has two faces; often called the front and back face. Finally, a polygon determines an inside and outside region, yet it can be ambiguous what these are.

  There are several modifiers that are useful when describing polygons.

  • A polygon is simple if no edges cross each other (they meet only at vertices). We want all of our polygons to be simple.
  • A polygon is regular if all its edges have equal length and the interior angle at each vertex are equal.
  • A polygon is convex when the line connecting any two interior points lies inside the polygon.
  • A polygon is planar if each of its vertices lies in a single plane. Although many polygons may start out as planar when they are defined in model space, the vagaries of computer arithmetic may quickly make them non-planar!
  Polygons will appear frequently and we will have much more to say about them when we explore other graphics topics. Triangles are frequently used polygons: They are simple and convex, and they are planar.

Objects are collections of primitives. In general, objects will be polygonal meshes (i.e., a collection of adjacent polygons).

Object coordinates are defines in model space. Additional attributes can also be be declared. For example, an object's color is often specified, and so are normal vectors at polygon vertices. Delving into these now is not possible.

  
Files and Data Structures

The subject of creating complex models is beyond the scope of this beginning graphics class. We will take the simple approach that the model objects are stored in one or more files which our programs will scan and store internally in a data structure.

File organization

One possible method to organize a model data file follows.

• The number of vertices, polygons, and surfaces in the mesh.
• Vertex information:
  • Vertex number
  • Coordinates $(x,\,y,\,z)$
  • Color $(r,\,g,\,b,\,\alpha)$
  • Vertex normal $\langle n_x,\, n_y,\,n_z\rangle$
• Polygon information:
  • Polygon number
  • Surface number
  • Number of vertices
  • List of vertex numbers

Note that this is not the only possible way to describe your model data. Please feel free to create better, richer descriptions.

As an example, consider modeling a cylinder by six side faces, a top, and a bottom. This example, comes from the text by Alan Watt [Wat89] and images used were created by a former graphics student (Weigang Li). Watt does not give explicit coordinates, yet they are easy to determine. Refer to Figure 2. It is easy to count that there are 12 vertices and 8 polygons, but we'll declare there are only 3 surfaces: The top, bottom, and the side, which is made from 6 polygons. This information is recorded in Table 1 below, which represents the cylinder data file. (We'll use double slashes to comment the data file.)

Let's assume the origin $(0,\,0,\,0)$ is located at the center of the cylinder, it is 2 units high, and the distance between parallel side faces is 1 unit. The top and bottom are regular polygons (hexagons). The interior angle of a regular polygon with n sides is given by

$$\theta = \frac{n-2}{n}\pi,$$

and the length of each side is

$$s = 2R \sin\frac{\pi}{n},$$

where R is the radius of the circumscribed circle. (This type of information can be found in a standard book of tables, for example, the CRC Standard Mathematical Tables.) For the hexagon, we find $\theta = 2\pi/3 = 120^{\circ}$ and R = 1. It is convenient to place vertex 1 (and 4, 7, 10) in the plane along the x axis. This allows us to simply fill out the coordinate information for vertices 1, 4, 7, and 10 in Table 1.

A little trigonometry can now be used to determine that vertex 2 is at coordinates $(-1/2, 1, -\sqrt{3}/2)$ and symmetry determines the remaining vertices. We have to approximate $\sqrt{3}$ and this type of error when combined with other round-off and truncation errors can cause irregularities in the scene: We must be careful.

In a complete model we would specify a color (red, green, blue), an opacity (an $\alpha$ value), and a normal vector $\vec{N}$ at each vertex. Sometimes, we may prefer to calculate the normal vector from information stored in the model data file.

To complete the data file, we'll assign surface number 1, 2, and 3 to the side, top, and bottom, respectively, and polygon numbers. For example, the polygon labeled 1 in Figure 2 is part of the side (belongs to surface 1) and has 4 vertices: 1, 7, 8, 2; polygon 7 from Figure 2 is surface 2 and has 6 vertices: 1, 2, 3, 4, 5, 6. This information is shown in Table 1.

There is a very important, but subtle point in the last paragraph: The order in which vertices are listed. I have chosen the convention that when viewed from the outside all polygons have their vertices listed counter-clockwise. The importance of this will become clear when we discuss normal vectors, and front and back faces. When you create your models be certain you develop a convention for listing the vertices of polygons and stick to it. Debugging this type of input error is frustrating: Spend the time up front to get it right the first time.

  

Figure 2: A cylinder modeled by a polygonal mesh.

 

Table 1: The data file for a simply cylinder approximation.

12 // vertices
8 // polygons
3 // surfaces
// Vertex number	x	y	z
1	-1.0	1.0	0.0
2	-0.5	1.0	-0.86602540
3	0.5	1.0	-0.86602540
4	1.0	1.0	0
5	0.5	1.0	0.86602540
6	-0.5	1.0	0.86602540
7	-1	-1.0	0.0
8	-0.5	-1.0	-0.86602540
9	0.5	-1.0	-0.86602540
10	1.0	-1.0	0.0
11	0.5	-1.0	0.86602540
12	-0.5	1.0	0.86602540

// Polygon number	Surface number Vertices	Vertex list
1	1	4	1	7	8	2
2	1	4	2	8	9	3
3	1	4	3	9	10	4
4	1	4	4	10	11	5
5	1	4	5	11	12	6
6	1	4	6	12	7	1
7	2	6	1	2	3	4	5	6
8	3	6	12	11	10	9	8	7

Data organization

The last item we will cover in this section is internal storage of the models. To develop a data structure flexible enough to allow us to implement all of the algorithms we will want to is not trivial. Luckily, we can program at a higher level using a graphics API such as OpenGL, Direct3D, or Java3D that eliminate the need for us to develop complex data structures from scratch. However, in the interest of presenting a complete introduction to computer graphics, I'll include some notes on this subject. Again, I've borrowed from Alan Watts' book [Wat89]. Figure 3 provides a diagram of the data structure. The scene is contained in a list of objects. Note that a better implementation would use a more complex graph (e.g., a directed acyclic graph [DAG]) to allow faster operations (find, insert, delete) on the scene. Each object record contains a reference (pointer) to a list of surfaces that comprise the object. Each surface record contain a reference to a list of polygons that comprise the surface. Each polygon record contains the a reference to the polygon's vertices, a vector normal to the polygon, and a flag that indicates whether should cull (throw away) the polygon from the scene or not. Each vertex has its own local coordinates; currently these are model coordinates, but they will change to other spaces down the pipeline. Watt also saves the world position of the point: This (or view coordinates) are useful for lighting calculations; and the screen or device coordinates of the point. Each vertex has its own normal, which is used in interpolative shading

  

Figure 3: A data structure to capture polygonal mesh information.

Conclusions

There are several spaces that make up the graphics pipeline: model, world, view, perspective, clip, normalized, device. We've learned that every object in a graphics scene has a model space where it is defined. Primitive objects are points, lines, and polygons. The basic object used in the standard graphics pipeline is a polygonal mesh. A simple object file format has been proposed and an internal data structure has been described.

• Where to we go from here? To world space.
• How do we get there? By affine transforms.
• How about some practice in model creation? Visit the practice exercises

Bibliography

Bli96

Jim Blinn.
Jim Blinn's Corner: a trip down the graphics pipeline.
Morgan Kaufmann Publishers, Inc., 1996.
1-55860-387-5.

Wat89

Alan Watt.
Fundamentals of Three Dimensional Computer Graphics.
Addison-Wesley, 1989.