Graphics Reference
In-Depth Information
from this to the kinds of special effects seen in video games and Hollywood films,
but some of the important ideas—building a mathematical model, converting it to
a 2D picture 5 —are present in our simple renderer in a basic form.
3.5 Limitations
We will now step back and look critically at this success. When you run the pro-
gram, you see a perspective view of a cube, consisting of 12 line segments (with
dots at the corners of the cube as well), as expected.
There are several limitations to the program. First, the wire-frame drawing
means that we can see both the back and the front of the cube. We could address
this in much the same way we addressed the drawing of edges: We could observe
that all points on a face of a cube (one of the square sides of the cube) will project
to points in the quadrilateral defined by the projections of the four vertices. So,
instead of keeping an edge table, we could keep a face table, and for each face,
we could draw a filled polygon in two dimensions. (We could draw both faces and
edges, of course.) Using this approach, our main concern will be to find a way to
draw only polygons that face toward the eye rather than away from it. There are
many strategies for doing this, but all of them require either more mathematics
than we wish to introduce in this chapter, or more complex data structures than
we wish to discuss at this time.
Second, although we all know that we see objects because of the light they
emit (which enters our eyes and causes us to perceive something, as described
in Chapters 5 and 28), there's nothing in our current program that describes any-
thing about light (except that our use of straight lines for projection is based on
the understanding that light travels along straight lines). We would get the same
picture of a cube whether we imagined any light being present or not. This also
means that all kinds of other light-dependent features, like shadows and shaded
parts of the surface, cannot manifest themselves. It's possible to add these with-
out an explicit model of light, but it's a mistake to do so, according to the Wise
Modeling principle.
Third, when this program runs, it only shows one model (the cube), and only
shows it in one position. We did a lot of work for not much output; our program
is not versatile enough to display other scenes without changing the code. This
can be addressed by storing the data representing the cube in a file that can be
read by the program; a typical representation would begin with a vertex count, a
list of vertices, an edge count, and a list of edges. Although it's less compact, it's
wise to make such files contain explicit tags on the data, and to allow comments;
it will make debugging your programs much easier. Here's an example file for
representing a cube:
1
2
3
4
5
6
7
8
9
# Cube model by jfh
nVerts: 8
vertTable:
0
-0.5
-0.5
-0.5
1
-0.5
0.5
-0.5
...
7 0.5 0.5 0.5
# Note that each edge of cube has length = 1
5. We're using the term “picture” informally here, as in “something you can look at.”
 
 
Search WWH ::




Custom Search