vector_3d struc
    x REAL4 ?
    y REAL4 ?
    z REAL4 ?
    w REAL4 ?
vector_3d ends

point_3d struc
    x REAL4 ?
    y REAL4 ?
    z REAL4 ?
    w REAL4 ?
point_3d ends

dir_3d struct
    ang_x SWORD ?
    ang_y SWORD ?
    ang_z SWORD ?
dir_3d ends

polygon struc
    num_points SWORD ?
    vertex_list SWORD 4t DUP (?)
    color SWORD ?
    shade SWORD ?
    shading SWORD ?
    two_sided SWORD ?
    visible SWORD ?
    active SWORD ?
    clipped SWORD ?
normal_length REAL4 ?
polygon ends

object struc
    id SWORD ?
    num_vertices SWORD ?
    vertices_local point_3d 32t DUP (<>)
    vertices_world point_3d 32t DUP (<>)
    vertices_camera point_3d 32t DUP (<>)
    num_polys SWORD ?
    polys polygon 16t DUP (<>)
    radius REAL4 ?
    state SWORD ?
    world_pos point_3d <>
object ends

The difficulty in using c structures to track objects in our 3d world arises when operations must be performed upon them by external assembly routines. We will vaguely disclose how we plan on accomplishing this. Because working without the object heirarchy described above would lead to a coding hazard, and the fact that LaMothe's book includes a PLG loader that interperates PLG files into his object style (the same style we've adopted for our polygon rederer), we decided to code our main loop in c, which takes care of the pointer passing to our far functions, and write the mission critical graphics and mathematics routines in no-holds-barred assembly.

• Translation:
  • Translation is simply a movement in space with a delta_X, delta_Y, and delta_Z.  To translate the points of an object, we look at the vertex list of every polygon that composes the object and add the appropriate deltas.
  • To do this with matrix mathematics requires that a 4x4 matrix be used so that the 3d coordinates become homogenous.  This means that the 3d coordinates are scaled relative to a normalizing factor, which is necessary for the matrix multiplication.
  • The translation matrix looks like this:
    [1       0       0        0]
    [0       1       0        0]
    [0       0       1        0]
    [delta_x delta_y delta_z 1]
• Scaling:
  • Scaling an object is as simple as multiplying each point that defines the object by a scaling_factor.  However, the object must be scaled in its local coordinate system, less unwanted translation occur if the object is scaled when not oriented about (0,0,0).
  • The scaling matrix looks like this:
    [scale 0     0     0]
    [0     scale 0     0]
    [0     0     scale 0]
    [0     0     0     1]     
• Rotation:
  • Despite the complexity of the mathematics behind rotation, the idea is really quite simple.  We have three ways to rotate an object, with respect to the x, y, and z axes.
  • Now, keeping in mind that LaMothe used a left-handed coordinate system, lets look at the matrices necessary for rotating an object, relative to its own local coordinate system, relative to one axis at a time.
  • The z-rotation matrix looks like this:
    [ cos(theta_z) sin(theta_z) 0 0]
    [-sin(theta_z) cos(theta_z) 0 0]
    [ 0            0             1 0]
    [ 0            0             0 1]
  • The y-rotation matrix looks like this:
    [cos(theta_y) 0 -sin(theta_y) 0]
    [0            1  0             0]        
    [sin(theta_y) 0  cos(theta_y) 0]
    [0            0  0             1]
  • The x-rotation matrix looks like this:
    [1  0            0             0]
    [0  cos(theta_x) sin(theta_x) 0]
    [0 -sin(theta_x) cos(theta_x) 0]
    [0  0            0             1]
  • All of these matrices are simply multiplied (using standard matrix multiplication rules) by the point vectors (matrix_1x4 type) that describe an object to achieve the desired translation, rotation, scaling, or combination of the previous.

Graphics Pipeline

• The graphics pipeline is as follows:

1. local to world transformation

   • Because the rotation and scaling transformations are done relative to an 

   objects local coordinate system, it must be transformed to the world 

   coordinate system.  This is done by simply adding the objects position to 

   each of the vertices that define the object in local space.

2. lighting and back-face removal

   • Each polygon has an attribute flag that states whether it is visible or
     
     not.  This flag is determined by computing the surface normal of the
     
     polygon and then finding the intersection of a ray cast from the camera
     
     position (a line of sight vector).  If the intersection angles with
     
     respect to the surface normal of the line of sight vector are less than 90
     
     degrees, then the face is visible.  At this time the color of the polygon
     
     is determined as well.  The color is an expression of the ambient light
     
     that suffuses the entire world and the intensity of light from a point
     
     source.

3. world to camera transformation

   • The world to camera transformation is complex.  We have to rotate all
     
     objects so that the view angles seem to be at (0,0,0) and move all objects
     
     so that the viewpoint seems to be at (0,0,0).  This is done with the
     
     following calculations:
     
     T_inverse=the translation matrix to the viewpoint's position
     
     R_?_inverse=the rotation matrix to the viewangles
     
     The world to camera transformation = WC = T_inverse * R_x_inverse *
     
                                                           R_y_inverse *
     
                                                           R_z_inverse;

4. clip polygons to viewing volume

   • All polygons outside of the viewing frustrum are removed if wholly
     outside or only partially rendered by the triangle routine which takes
     screen boudaries into account.

5. perspective projection

6. redering to screen.

 

PLG Files

The PLG file format is used to store all of the objects in our world. Basically, it contains a list of the verticies, polygons, and colors for one object. The version LaMothe uses also provides for blank lines and comments. An example file for a cube is as follows:

; CUBE object
cube 8 6

; vertice list
-20 20 20
20 20 20
20 20 -20
-20 20 -20
-20 -20 20
20 -20 20
20 -20 -20
-20 -20 -20

; polygon list
; cube has six sides all flat shaded
0x109f 4 0 3 2 1
0x109f 4 2 3 7 6
0x109f 4 4 5 6 7
0x109f 4 0 1 5 4
0x109f 4 0 4 7 3
0x109f 4 1 2 6 5

_A_KEY        db 0 ; Any key was pressed
_TURN_RIGHT   db 0 ; Right Arrow (1 = Button is down, 0 = Button is up)
_TURN_LEFT    db 0 ; Left Arrow
_DIVE_DOWN    db 0 ; Up Arrow
_CLIMB_UP     db 0 ; Down Arrow 
_SPEED_INC    db 0 ; 
_SPEED_DEC    db 0 ;
_Exit_Flag    db 0 ; Set to 1 when time to exit  (ESC)