3-DIMENSIONAL WORLD

Document Sample
3-DIMENSIONAL WORLD Powered By Docstoc
					               EEL 4914 – SENIOR DESIGN I



               3-DIMENSIONAL WORLD
                   (USING OpenGL)



                    CHRIS R. MARTIN
                   ERICH P. SCHMUNK
                    BRIAN S. RAVAK




             UNIVERSITY OF CENTRAL FLORIDA
COLLEGE OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
                      SUMMER 2002




                      GROUP – 7
                DESIGN DOCUMENTATION



                      24 JULY 2002
Table of Contents: ------------------------------------------------------------------ i
Table of Figures: ------------------------------------------------------------------ iii
3-DIMENSIONAL WORLD --------------------------------------------------------- 1
CHAPTER 1: PROPOSED SYSTEM ---------------------------------------------------- 1
  1.1. PROPOSAL – STATEMENT OF WORK ------------------------------------------------------- 1
  1.2. DESCRIPTION --------------------------------------------------------------------------------- 1
  1.3. ADDITIONAL DESIGN OPTIONS ------------------------------------------------------------- 1
CHAPTER 2: IMPLEMENTATION REQUIREMENTS --------------------------- 3
  2.1. WHY IMPLEMENTATION IN OPENGL? ------------------------------------------------------ 3
  2.2. DESIGN METHOD AND FUNCTIONALITY --------------------------------------------------- 3
  2.3. APPROACH ------------------------------------------------------------------------------------ 4
    2.3.1. Strategy ------------------------------------------------------------------------------- 5
    2.3.2. Analysis ------------------------------------------------------------------------------- 5
    2.3.3. Design --------------------------------------------------------------------------------- 5
    2.3.4. Build ------------------------------------------------------------------------------------ 6
    2.3.5. User Documentation ------------------------------------------------------------- 6
    2.3.6. Testing -------------------------------------------------------------------------------- 6
    2.3.7. Production --------------------------------------------------------------------------- 6
CHAPTER 3: SYSTEM REQUIREMENTS -------------------------------------------- 9
  3.1. HOW THIS SOFTWARE APPLICATION WILL BE DEVELOPED ----------------------------- 9
    3.1.1. Utilization of C/C++ -------------------------------------------------------------- 9
    3.1.2. OpenGL -------------------------------------------------------------------------------- 9
  3.2. PLATFORM DEPENDABILITY ----------------------------------------------------------------- 9
  3.3. REQUIREMENTS ------------------------------------------------------------------------------- 9
    3.3.1. Hardware Requirements ------------------------------------------------------- 9
    3.3.2. Software Requirements ------------------------------------------------------- 10
  3.4. ALGORITHMS ------------------------------------------------------------------------------- 10
  3.5. PSEUDO-CODE ------------------------------------------------------------------------------ 11
  3.6. PROJECT TEAM MEMBERS ----------------------------------------------------------------- 12
  3.7. COST ANALYSIS ---------------------------------------------------------------------------- 12
  3.8. PROJECT TIMELINE ------------------------------------------------------------------------- 12
    3.8.1 Milestones --------------------------------------------------------------------------- 13
CHAPTER 4: DESIGNING THE WORLD ------------------------------------------- 15
  4.1. EXPANDING THE PSEUDO-CODE – A PROTOTYPE -------------------------------------- 15
    4.1.1. Snapshots from Source Code Output --------------------------------- 23
  4.2. FUNCTION DEFINITIONS ------------------------------------------------------------------- 25
  4.3. VARIABLES ---------------------------------------------------------------------------------- 26
  4.4. THE PURPOSE OF GLUT ------------------------------------------------------------------ 28
  4.5. GLUT CALLBACK FUNCTION DEFINITIONS --------------------------------------------- 28
CHAPTER 5: ORDER OF OPENGL EVENTS ------------------------------------- 31

                                                  i
  5.1. OVERVIEW ----------------------------------------------------------------------------------- 31
  5.2. GEOMETRIC OPERATIONS ----------------------------------------------------------------- 32
    5.2.1. Per-Vertex Operations --------------------------------------------------------- 32
    5.2.2. Primitive Assembly ------------------------------------------------------------- 32
  5.3. PIXEL OPERATIONS ------------------------------------------------------------------------- 33
    5.3.1. Texture Memory ----------------------------------------------------------------- 33
  5.4. FRAGMENT OPERATIONS ------------------------------------------------------------------ 34
  5.5. ODDS AND ENDS --------------------------------------------------------------------------- 34
  5.6. NOTE FROM THE TEAM ------------------------------------------------------------------- 34
CHAPTER 6: SYSTEM MODELS------------------------------------------------------- 35
  6.1. USE CASE ----------------------------------------------------------------------------------- 35
    6.1.1. Use Case Description ---------------------------------------------------------- 36
  6.2. ACTIVITY DIAGRAM ------------------------------------------------------------------------ 40
    6.2.1. System Activity System ------------------------------------------------------- 40
  6.3. STATE DIAGRAM --------------------------------------------------------------------------- 41
    6.3.1. Operate System ------------------------------------------------------------------ 41
    6.3.2. Develop System ------------------------------------------------------------------ 41
APPENDIX 7: TEST PROCEDURES -------------------------------------------------- 43
  7.1. TEST OVERVIEW ---------------------------------------------------------------------------- 43
  7.2. TEST PROCEDURES ------------------------------------------------------------------------- 43
    7.2.1. Introduction ----------------------------------------------------------------------- 43
    7.2.2. Relationship to other Documents ----------------------------------------- 43
    7.2.3. System Overview ---------------------------------------------------------------- 43
    7.2.4. Features to be Tested/not to be Tested --------------------------------- 43
    7.2.5. Pass/Fail Criteria ---------------------------------------------------------------- 44
    7.2.6. Approach --------------------------------------------------------------------------- 45
    7.2.7. Suspension and Resumption ------------------------------------------------ 45
    7.2.8. Testing Materials (Hardware/Software requirements) ----------- 46
    7.2.9. Test Cases-------------------------------------------------------------------------- 47
    7.2.10. Testing Schedule -------------------------------------------------------------- 49
APPENDIX A: GLOSSARY OF TERMS ---------------------------------------------- 51
  A.1. DEFINITIONS -------------------------------------------------------------------------------- 51
APPENDIX B: ACRONYMS ---------------------------------------------------------------- 57
  B.1. ACRONYMS LIST ---------------------------------------------------------------------------- 57
APPENDIX C: EXECUTING COMMANDS IN 3-D WORLD ---------------- 59
  C.1. EXPLANATION ------------------------------------------------------------------------------ 59
  C.2. LIST OF COMMANDS ---------------------------------------------------------------------- 59
REFERENCE: ------------------------------------------------------------------------------------- 61




                                                 ii
Table of Figures/Pictures ---------------------------------------------------------- iii
FIGURE 1. SYSTEM LIFE CYCLE --------------------------------------------------------------------------- 4
FIGURE 2. UML ACTIVITY DIAGRAM --------------------------------------------------------------------- 5
FIGURE 3. PHASED SYSTEM PRODUCTION ----------------------------------------------------------------- 7
FIGURE 4. TIMELINE OF EVENTS ------------------------------------------------------------------------ 13
PICTURE 1. OUTSIDE WORLD --------------------------------------------------------------------------- 23
PICTURE 2. STARTING POINT OF MAZE ------------------------------------------------------------------ 23
PICTURE 3. FIRST HALLWAY ---------------------------------------------------------------------------- 23
PICTURE 4. FIRST TURN -------------------------------------------------------------------------------- 24
PICTURE 5. COLUMN/ISLAND --------------------------------------------------------------------------- 24
PICTURE 6. END OF MAZE ------------------------------------------------------------------------------ 24
FIGURE 5. ORDER OF EVENTS. -------------------------------------------------------------------------- 31
FIGURE 6. USE CASE DIAGRAM ------------------------------------------------------------------------- 35
FIGURE 7. SYSTEM ACTIVITY DIAGRAM ----------------------------------------------------------------- 40
FIGURE 8. OPERATE SYSTEM STATE DIAGRAM ---------------------------------------------------------- 41
FIGURE 9. DEVELOP SYSTEM STATE DIAGRAM ---------------------------------------------------------- 41
FIGURE 10. TEST SCHEDULE ---------------------------------------------------------------------------- 49




                                                   iii
                   3-DIMENSIONAL WORLD
                       (USING OpenGL)

                   CHAPTER 1: Proposed System
1.1. Proposal – Statement of Work
  Develop a 3-Dimensional world capable of rendering an environment
  based upon user input. The user can select a design (shape) for the
  world based upon a predetermined set of points (coordinates) that the
  user will be prompted to input. The shape will conform to a geometric
  polygon of three to eight sides. Upon input of the predetermined
  points the world will be designed. The world will also provide user
  interaction via input device(s).

1.2. Description
  This design proposal is explicitly intended for the development of a
  graphical software application utilizing OpenGL (graphics libraries).
  The purpose for developing this software application is solely for the
  requirements set forth for Senior Design I & II at the University of
  Central Florida, College of Electrical Engineering & Computer Science.
  The software application being proposed, in essence, is a 3-
  dimensional world. This world will provide the framework for a 3-
  dimensional environment that can be utilized for various functions. In
  short, the software application will be able to receive a set of points,
  coordinates or end points of a geometric polygon, and generate a 3-
  dimension world based upon this shape. The pathway or maze that is
  created will provide an environment for user interaction allowing the
  user to travel through the maze and maneuver by various commands.

  At a minimum, the 3-dimensional world that will be developed allows
  the user to maneuver in various directions. Forward, backward, left,
  right, with full rotation about the x and y-axis are minimum features
  that this world will provide for the user to interact in. In addition to
  the maneuverability within the world, coloring, texturing, and special
  effects lighting will also be included within the application.

1.3. Additional Design Options
  Depending on time, system complexity, and scope of the design, other
  features may also be added to the design of this system. These
  additional features are as follows:




                                    1
   Enhanced texture mapping and special effects
        (mip-mapping)
   Free floating environment
        (anti-gravitational environment)
   Variable speed control
   Cross platform demonstration on an Silicon Graphics system
   User Manual Document




                           2
           CHAPTER 2: Implementation Requirements
2.1. Why Implementation in OpenGL?
  The development of this graphical software application requires the
  C/C++ environment.      Although this application will be primarily
  developed in C/C++, it will also include the graphical features
  available in OpenGL, specifically, the Graphical Library Utility Toolkit
  (GLUT). GLUT has many powerful features that are available in
  OpenGL and the fact that OpenGL is the industry leader for developing
  portable, interactive 2D and 3D graphics applications, makes it the
  best choice for the development of this application. It is the most
  widely used and most widely supported 2D and 3D graphics
  application programming interface (API). OpenGL has an inherent
  development setting, which increases the speed of application
  development. It provides texture mapping, special effects, and other
  powerful visualization functions. Developers can leverage the power
  of OpenGL across all popular desktop and workstation platforms,
  ensuring wide application deployment.

  Not only is OpenGL the programmers choice for developing graphical
  interfaces, it is also a well-structured graphics library software
  application. It provides the Developer with an environment that is
  stimulated by instinctive design features utilizing logical commands.
  The efficiency of OpenGL enhances development of routines that
  typically result in applications with fewer lines of code than those that
  make up programs generated using other graphics libraries or
  packages.     Furthermore, OpenGL drivers encapsulate information
  about the underlying hardware, freeing the application Developer from
  having to design for specific hardware features. The cross-platform
  functionality is one of the many reasons Open GL has evolved into the
  industry standard for graphics design and development.

2.2. Design Method and Functionality
  The necessary theories guiding production of graphical software
  applications in OpenGL stem primarily from highly involved matrix
  algebra. The understanding of various algorithms learned in EEL 3420
  (Engineering Analysis), EEL4832 (Engineering Applications of
  Computer Methods), as well as, various computer-programming
  courses, is essential in understanding the concepts and functionality
  of OpenGL.

  The functionality of this graphical software application or graphical
  interface is seen in its user defined world development.            The
  application will be able to receive a set of points, coordinates or end
  points of a geometric polygon, and generate a 3-D world based upon


                                    3
   this shape. The shape that is created will be further developed to
   create a pathway or maze in this 3-dimensional world that will also
   provide user interaction. The user will be able to travel through the
   maze and maneuver through various obstacles.              The user will
   encounter four basic options: go forward, turn around, or make left
   or right turns. The system will allow the user to guide their way
   through this 3-dimensional world encountering various decision-
   making processes.        The interactive capabilities of the software
   application will allow the user to visualize the real-time power behind
   OpenGL.
2.3. Approach
   A staged approach will be followed to methodically engineer this
   system through a prescribed life cycle. A large number of tasks must
   be carried out in a systematic and methodical manner to assure the
   success of this system. The tasks are grouped into major stages as
   can be seen by the figure below. This figure provides the framework
   for the life cycle of the system to be developed.



                                 STRATEGY




                                  ANALYSIS




                                   DESIGN




                         BUILD                   USER
                                             DOCUMENTATION



                                  TESTING




                                 PRODUCTION

FIGURE 1. SYSTEM LIFE CYCLE1



                                     4
2.3.1. Strategy
    This phase outlines the project goals and provides a clear
    understanding of the system to be developed. Through explicit
    strategic planning, the Developers can easily separate the „what to
    do‟ or analysis from the „how to do it‟ or design. The goal of this
    project is do develop a 3-dimensional world. The next point will
    address the analysis for this project.

2.3.2. Analysis
    As has already been addressed in the previous deliverables for Senior
    Design I, as well as encapsulated in this document, the analysis
    stage has been completed. Through analysis, the project team has
    anticipated many of the possible stumbling blocks that can arise and
    have noted and specified the criteria in which they will work.
    Chapter 3 of this document addresses in more detail the analysis
    completed for this project.

2.3.3. Design
    Design takes the detailed requirements from the analysis stage and
    determines the best approach to achieving the goal. The bulk of this
    document will outline this design approach. Several tools will be
    utilized in the design process.            Specifically, the use case
    methodology for object oriented design, modeling with UML (Unified
    Modeling Language), as well as, concepts from the CASE*Method for
    a structured approach for carrying out tasks of system development.
    The figure below identifies the activities of system design.


               Define               Define            Implement
             design goals         subsystems          subsystems



                                         Map sub-
                                      systems to HW
                                       SW platform
                                                          Select a
                                                       global control
                                                           flow
                                       Manage Data

                                                         Describe
                                                        boundary
                                           Define       conditions
                                           control
                                           policies
FIGURE 2. UML ACTIVITY DIAGRAM2



                                       5
2.3.4. Build
    This stage of development will include the actual coding and testing
    of the program. One important algorithm, the Bresenham‟s, along
    with a snippet of psuedo-code are both explained in the next chapter
    of this document.      Additionally, the project team has begun
    development of a 3-D world that will serve as a prototype and
    provide the framework for future development.          Many of the
    concepts are new to all the Developers on the team; therefore, some
    trial and error is expected. Furthermore, since OpenGL is open
    source, there are many tutorials and aids available on the Internet
    that will be called upon when needed. Nevertheless, as Figure 2
    denotes, there is some handshaking going on during the design
    stage between defining subsystems and implementation.             As
    knowledge of OpenGL is gained throughout the course of design, it
    is anticipated that subsystems already tested and implemented will
    be revisited and modified as necessary.

2.3.5. User Documentation
    User documentation will be provided when the system is operational.
    Therefore, it will not be included here as part of the design
    document. However, a rudimentary list of operations and command
    functions will be provided in an appendix herein.

2.3.6. Testing
    The transition stage, which normally would follow the build stage of
    the CASE*Method structure, has been replace with a testing stage.
    Since this system is being developed for design purposes only and
    will not be deployed to the customer per say, the Developers
    determined that the transition stage was unnecessary. However, the
    system will be operationally capable when complete and will be
    demonstrated as such as part of the final review for Senior Design II.
    For the purposes of this project development, transition then, is
    replaced with testing, which is outlined in detail in Chapter 6, System
    Models, of this document.

2.3.7. Production
    This stage will demonstrate the smooth running of the system and
    will provide for a system that is well documented. Since there is
    such a thin line between system build, testing, and production, the
    team of Developers deemed in necessary to include testing as an
    additional stage of this design document, which will include tests
    conducted on those items outlined in Chapter 6. As this system
    becomes operational, the methodology utilized will enable the
    system to grow and develop depending on future requirements.


                                    6
     Furthermore, the documentation that will be provided will also
     enhance the capabilities of future growth of the system.


2.3.4. Key Deliverables
    Well Documented Source Code
    System Design Documentation
    User‟s Documentation (optional)
    Command Execution Listing
    System Access Controls
    Function Definitions List


                                         PHASED
                                      DEVELOPMENT
                Pro-active
                                        PLANNING      Re-active
                Impact                                Impact
                Analysis                              Analysis
                (enhancements)                        (maintenance)


                                        Monitor
                                        Progress




                                         Update
                                      Documentation



FIGURE 3. PHASED SYSTEM PRODUCTION3




                                           7
8
                    CHAPTER 3: System Requirements
3.1. How This Software Application Will Be Developed

3.1.1. Utilization of C/C++
    This software application will be developed in the C/C++
    environment.      C/C++ was determined to be the programming
    language choice based upon the skills, knowledge, and background
    of the Developers working on this project. All necessary functions,
    methods, and structures will be developed using this environment.
    Those concepts from the object oriented design methodology that
    apply to this development will also be orchestrated into the design of
    this system.

3.1.2. OpenGL
    OpenGL is the choice graphical software package for developing this
    system based upon several reasons. First, it is the industry standard
    and leader for developing 2-D and 3-D graphical applications.
    Second, it provides multiple platform portability. Third, it provides a
    powerful tool in GLUT.        And finally, the Developers for this
    application are currently enrolled in EEL 5771 (Engineering
    Application in Computer Graphics – using OpenGL) to fulfill the
    credit hours for electives for Computer Engineers. The knowledge
    learned in EEL 5771 will be instrumental in developing this system.
3.2. Platform Dependability
   Platform dependability will require a system with a Pentium 2 class
   processor and a minimum processing speed of 200 MHz. Video
   quality requirements will require 16-bit high-resolution color quality.
   Microsoft Visual C++ 6.0, OpenGL (graphics libraries), glut32.dll,
   glut32.lib, and glut.h (GLUT for Win32 version 3.7.6) will be the
   necessary software tools used in the development of this system.
3.3. Requirements
3.3.1. Hardware Requirements
         Windows Based Machine
              I.67 GHz Athlon XP 2000+
              Nvidia GeForce4 TI 4400 (128M DDR)
             Optional System – Unix Based Machine (for demonstration of
              portability)
              Silicon Graphics Indigo2
              250 MHz
              Impact Video Board


                                          9
3.3.2. Software Requirements
       Microsoft Visual C++ 6.0
          GCC Compiler for UNIX (optional)
          OpenGL (graphics libraries)
          GLUT for Win32 version 3.7.6
              glut32.dll
              glut32.lib
              glut.h

3.4. Algorithms
   OpenGL relies heavily on built-in features that perform complex matrix
   algebra to display and animate a 3-D world. This function of OpenGL
   is one of the many reasons it is widely used within the industry.
   Nevertheless, some scaling will have to be rendered, for which
   Bresenham‟s Algorithm* will be utilized. Bresenham‟s Algorithm
   contains a loop that selects x and y coordinates for rendering the next
   pixel of a line to be “filled-in”. By increasing the x coordinate by one
   and increasing the y coordinate by either zero or one relative to the
   previous pixel, the line is rendered. This algorithm is extremely fast
   because the code within the loop uses only integer addition and
   subtraction.     An example of pseudo-code for the Bresenham‟s
   Algorithm is listed below.4

     //considering line endpoints are (x1,y1) and (x2,y2)

     testVariable = 2*(y2-y1)-(x2-x1);
     a = 2*(y2-y1);
     b = 2*(y2-y1-x2+x1);
     y = y1;

     for(int x = x1+1; x < x2-1; x++)
     {
       if(testVariable < 0)
            testVariable = testVariable + a;
       else
            testVariable = testVariable + b;
       y = y + 1;
       writePixel(x,y);
     }

* Information for Bresenham’s Algorithm was obtained from the publication MiniMicro Systems,
November 1983.




                                              10
3.5. Pseudo-code
    The following pseudo-code for the main function is only a preliminary
    concept design for a 3-D world. This rudimentary pseudo-code is an
    initial baseline for further development and is expected to change
    depending on programming needs and requirements.                   From
    programming experience using GLUT and the OpenGL libraries, it has
    already been determined that many of the libraries and function calls
    will provide the heart of the system. Many of the glut function calls
    are readily available at the programmer‟s fingertips to be utilized for
    rapid development. The power of OpenGL will provide a system that,
    not only is versatile, but also is well structured and streamlined. The
    pseudo-code follows:

// preliminary pseudo-code for the main function with
// comments to describe each function call

void main (int argc, char **argv)
{
     glutInit(&argc,argv);                  //Initial arguments

       glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);//Initial
                                //display for the 3-D world
       glutInitWindowSize(1024,768);      //Window Size

       glutInitWindowPosition(0,0);       //Initial start
                                          //position
       glutCreateWindow("OpenGL 3-D World");   //Window Title

       glutDisplayFunc(redraw);           //Redraws world as
            //environment changes due to user interaction

       setLighting();          //Sets lighting within environment

       getCoordinates();       //Requests Maze design from user

       initialDesign();              //Calculates maze design
                                     // based upon user input

       glutKeyboardFunc(keyboard);   //Provides user with 3-D
                           // world interactive environment

       glutMainLoop();         //Provides continuous redisplay
                               //of 3-D world

}



                                    11
3.6. Project Team Members
   Chris R. Martin – Lead Developer (email: ch298034@pegasus.cc.ucf.edu)
          Develop the baseline structure for the 3-D world.
          Provide lead programming expertise and knowledge to the
           development.
          Ensure portability across various platforms (optional).

   Erich P. Schmunk – Software Engineer (email: eschmunk@hotmail.com)
          Develop many of the key components and subroutines.
          Design the interactive capabilities of the 3-dimensional world.

   Brian S. Ravak – System Engineer (email: bravak@aol.com)
          Design the high-level functionality of the system (texturing,
           lighting, etc).
          Conduct testing and facilitate functionality of the system.
          Conduct Research and document the system development.

3.7. Cost Analysis
   Funding will be fully covered by Group 7 Team Members. Hardware
   for the system is personal property of the Team Members, which has
   already procured. Therefore further expected cost for hardware is $0.
   Microsoft Visual C++ 6.0 is also personal property of the Team
   Members. OpenGL and GLUT are freely distributed and downloadable
   from the Internet. One additional reference manual was determined to
   be useful, OpenGL the Red Book, and was procured for the cost of
   $60. Any additional resources will be acquired as necessary.
   An additional $500 of personal funding has been allocated for further
   acquisitions if necessary.     All hardware, software, and reference
   manuals will be returned to the individual Team Members who
   donated such items for this system design. A final copy of the actual
   application that will be developed will be delivered to the University of
   Central Florida College of Engineering and Computer Science, along
   with a copy of all documentation that available.
3.8. Project Timeline
    The testing coordinator, to ensure timely completion of tasks, should
    closely monitor this timeline. This timeline will also be essential for
    the testing stage of completed subsystems. As Developers complete
    individual standalone functions of the code, that portion of code will
    be tested. If a subsystem is not standalone, then it will be tested
    with the next iteration of code that is functional and standalone.




                                    12
3.8.1 Milestones
    The following table is a list of key milestones for beginning new
    tasks and testing completed tasks:

                 Key Date                        Description

                        1 July 2002 Began development of a prototype
                                    2D/3D world to be demonstrated at the
                                    end of Senior Design I.
                      21 July 2002 Completed prototype design and
                                   testing.
                  20 August 2002 Begin development of input acceptance
                                 for world design. Base line this for the
                                 coordinates determined in the
                                 prototype.
               1 September 2002 Complete and test baseline system.
               1 September 2002 Begin coding for acceptance of grid
                                coordinates for the world development
                                for a 3 - 8 sided polygon.
             30 September 2002 Complete and test acceptance of multi-
                               polygon designs. Perform testing of
                               test case3DWorldIcon_NormalUse.
                   1 October 2002 Begin single feature functionality to
                                  include: all critical maneuverability
                                  keys, collision detection, texture
                                  mapping, color mapping, and special
                                  lighting.
                 30 October 2002 Complete tasking from 1 October
                                 2002. Perform testing of the test case
                                 ExecuteCommand_Normal.
                1 November 2002 Begin rapid development and testing of
                                all optional features considered for
                                development.
              15 November 2002 Perform final system test.
              16 November 2002 Conduct dry run for review board.
        18 - 27 November 2002 Prepare for and conduct the final
                              design review with review board.


FIGURE 4. TIMELINE OF EVENTS



                                       13
14
                   CHAPTER 4: Designing the World
4.1. Expanding the Pseudo-Code – A Prototype
     The next several pages are the source code for a 3-D World (Maze)
     Prototype. After the source code, there will be several sections that
     will explain the function definitions, variables, GL, and GLUT function
     calls used throughout the code. This code will provide the framework
     and foundation for further development of the system.
/******************************************************************
* Prototype                                                       *
* Author: Christopher R. Martin, Brian Ravak, Erich Schmunk       *
* w - forward, s - backward, i - look up, k - look down,          *
* j - turn left, l - turn right, mouse – free look,               *
* esc key - exits window,                                         *
******************************************************************/

#include   <GL/glut.h>
#include   <iostream.h>
#include   <stdio.h>
#include   <math.h>
#include   <gl\gl.h>
#include   <gl\glu.h>
#include   <gl\glaux.h>

enum Boolean {YES,NO};
GLuint letter_C = 1, base = 2, walls = 3;
int window_height,window_width;
GLenum depth_function = GL_LESS;

// Initial values of rotation and transformation;
GLfloat xrot=0.0f,yrot=0.0f,x_distance=-45.0f,y_distance=-6.0f,
      z_distance=65.0f;

const float piover180 = 0.0174532925f;
float heading;
GLuint texture[5];

// Y Rotation
GLfloat walkbias = 0;
GLfloat walkbiasangle = 0;

static void init_letter_C(void)
{
      glNewList(letter_C,GL_COMPILE);
      glFrontFace(GL_CCW);
      glColor3f(0.5f,0.3f,0.2f);

        glEndList();
};

static void init_base(void)
{
      glNewList(base,GL_COMPILE);
      glFrontFace(GL_CCW);


                                     15
      glColor3f(0.0f,1.0f,0.0f);

      glEnable(GL_TEXTURE_2D);
      glBindTexture(GL_TEXTURE_2D,texture[2]); // grass texture

// floor
      glBegin(GL_POLYGON);
      glTexCoord2f(0,0);
      glVertex3f(-50.0f,0.0f,50.0f);
      glTexCoord2f(0,1);
      glVertex3f(-50.0f,0.0f,-50.0f);
      glTexCoord2f(1,1);
      glVertex3f(50.0f,0.0f,-50.0f);
      glTexCoord2f(0,1);
      glVertex3f(50.0f,0.0f,50.0f);
      glEnd();

      glDisable(GL_TEXTURE_2D);

// ceiling
      glColor3f(1.0f,1.0f,1.0f);

      glEnable(GL_TEXTURE_2D);
      glBindTexture(GL_TEXTURE_2D,texture[1]);   // sky texture

      glBegin(GL_POLYGON);
      glTexCoord2f(0,0);
      glVertex3f(-50.0f,10.0f,50.0f);
      glTexCoord2f(0,5);
      glVertex3f(-50.0f,10.0f,-50.0f);
      glTexCoord2f(5,5);
      glVertex3f(50.0f,10.0f,-50.0f);
      glTexCoord2f(0,5);
      glVertex3f(50.0f,10.0f,50.0f);
      glEnd();

      glDisable(GL_TEXTURE_2D);

      glEndList();
};

static void init_walls(void)
{
      glNewList(walls,GL_COMPILE);
      glFrontFace(GL_CCW);
      glColor3f(1.0f,1.0f,1.0f);

      glEnable(GL_TEXTURE_2D);
      glBindTexture(GL_TEXTURE_2D, texture[3]); //start texture
      glBegin(GL_POLYGON);
      glNormal3f(0.0f,0.0f,-1.0f);
      glTexCoord2f(0,0);
      glColor3f(1.0f,0.0f,0.0f);
      glVertex3f(-50.0f,0.0f,50.0f);
      glTexCoord2f(0,1);
      glColor3f(0.0f,1.0f,0.0f);
      glVertex3f(-50.0f,10.0f,50.0f);


                                     16
glTexCoord2f(1,1);
glColor3f(0.0f,0.0f,1.0f);
glVertex3f(-40.0f,10.0f,50.0f);
glTexCoord2f(1,0);

glColor3f(1.0f,1.0f,1.0f);
glVertex3f(-40.0f,0.0f,50.0f);
glEnd();

glDisable(GL_TEXTURE_2D);

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture[4]); //Bauer texture

glBegin(GL_POLYGON);
glNormal3f(0.0f,0.0f,1.0f);
glTexCoord2f(0,0);
glColor3f(1.0f,0.0f,0.0f);
glVertex3f(40.0f,0.0f,-50.0f);
glTexCoord2f(0,1);
glColor3f(0.0f,1.0f,0.0f);
glVertex3f(40.0f,10.0f,-50.0f);
glTexCoord2f(1,1);
glColor3f(0.0f,0.0f,1.0f);
glVertex3f(50.0f,10.0f,-50.0f);
glTexCoord2f(1,0);
glColor3f(1.0f,1.0f,1.0f);
glVertex3f(50.0f,0.0f,-50.0f);
glEnd();

glDisable(GL_TEXTURE_2D);

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D,texture[0]);   // brick texture

glBegin(GL_POLYGON);
glNormal3f(1.0f,0.0f,0.0f);
glTexCoord2f(0,0);
glVertex3f(-50.0f,0.0f,50.0f);
glTexCoord2f(0,1);
glVertex3f(-50.0f,10.0f,50.0f);
glTexCoord2f(10,1);
glVertex3f(-50.0f,10.0f,-50.0f);
glTexCoord2f(10,0);
glVertex3f(-50.0f,0.0f,-50.0f);
glEnd();

//    .           34 additional blocks of code hvae been deleted
//    .           from this section. It was very similar to the
//    .           block above and below this comment with the
//                exception of varying values

glBegin(GL_POLYGON);
glNormal3f(1.0f,0.0f,0.0f);
glTexCoord2f(0,0);
glVertex3f(40.0f,0.0f,-40.0f);
glTexCoord2f(1,0);


                             17
     glVertex3f(40.0f,10.0f,-40.0f);
     glTexCoord2f(1,1);
     glVertex3f(40.0f,10.0f,-50.0f);
     glTexCoord2f(0,1);
     glVertex3f(40.0f,0.0f,-50.0f);
     glEnd();

     glDisable(GL_TEXTURE_2D);

     glEndList();
};

//Loads A Bitmap Image from disk
//Standard algorithm for bitmap loading
AUX_RGBImageRec *LoadBMP(char *Filename)
{
      FILE *File = NULL;

     if(!Filename)
           return NULL;

     File = fopen(Filename, "r");

     if(File)
     {
           fclose(File);
           return auxDIBImageLoad(Filename);
     }

     return NULL;
};

//Load Bitmaps And Convert To Textures
//Standar algorithm for bitmap conversion
int LoadGLTextures(int image_count, char *Filename)
{
      int Status = FALSE;

     AUX_RGBImageRec *TextureImage[1];
     memset(TextureImage,0,sizeof(void*)*1);

      if(TextureImage[0]=LoadBMP(Filename))
      {
            Status = TRUE;
            glGenTextures(image_count+1,&texture[image_count]);
            glBindTexture(GL_TEXTURE_2D,texture[image_count]);
            glTexImage2D(GL_TEXTURE_2D,0,3, TextureImage[0]->sizeX,
TextureImage[0]->sizeY,0,
                  GL_RGB, GL_UNSIGNED_BYTE, TextureImage[0]->data);

     glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);

     glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
     }
     if(TextureImage[0])
     {
           if(TextureImage[0]->data)


                                    18
            {
                  free(TextureImage[0]->data);
            }
            free(TextureImage[0]);
     }

     return Status;
};

void SetupRC(void)
{
      // Light values and coordinates
      GLfloat ambientLight[] = {0.4f,0.4f,0.4f,1.0f};
      GLfloat diffuseLight[] = {0.7f,0.7f,0.7f,1.0f};
      GLfloat specular[] = {0.7f,0.7f,0.7f,1.0f};
      GLfloat lightPos[] = {1.0f,10.0f,10.0f,1.0f};
      GLfloat specref[] = {0.5f,0.5f,0.5f,1.0f};
      glShadeModel(GL_SMOOTH);
      //Anti Aliasing
      glEnable(GL_LINE_SMOOTH);
      glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);
      // Enable Lighting
      glEnable(GL_LIGHTING);
      // Setup light 0
      glLightModelfv(GL_LIGHT_MODEL_AMBIENT,ambientLight);
      glLightfv(GL_LIGHT0,GL_AMBIENT,ambientLight);
      glLightfv(GL_LIGHT0,GL_DIFFUSE,diffuseLight);
      glLightfv(GL_LIGHT0,GL_SPECULAR,specular);
      // Position and turn on the light
      glLightfv(GL_LIGHT0,GL_POSITION,lightPos);
      glEnable(GL_LIGHT0);
      // Enable Color Tracking
      glEnable(GL_COLOR_MATERIAL);
      // Set Material properties to follow glColor values
      glColorMaterial(GL_FRONT,GL_AMBIENT_AND_DIFFUSE);
      // All materials hereafter have full specular reflectivity
      // with a moderate shine
      glMaterialfv(GL_FRONT,GL_SPECULAR,specref);
      glMateriali(GL_FRONT,GL_SHININESS,30);

     glEnable(GL_LINE_SMOOTH);
     glBlendFunc(GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA);
};

void redraw(void)
{
      GLfloat xtrans = -x_distance;
      GLfloat ztrans = -z_distance;
      GLfloat ytrans = -walkbias-0.25f-4.0f;
      GLfloat sceneroty = 360.0f - yrot;
      glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
      glutWarpPointer(int(window_width/2),int(window_height/2));

     glDepthFunc(GL_LESS);
     glEnable(GL_DEPTH_TEST); // Hidden surface removal
     glClearDepth(1.0);


                                   19
      glShadeModel(GL_SMOOTH);
      // Enables Smooth Color Shading
      glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);    // Really
Nice Perspective Calculations
      glClearColor(0.0f,0.0f,0.0f,0.0f);
      glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

     glPushMatrix();
     glScalef(1.0f,1.0f,1.0f);
     glRotatef(xrot,1.0f,0.0f,0.0f);
     glRotatef(sceneroty,0.0f,1.0f,0.0f);
     glTranslatef(xtrans,ytrans,ztrans);
     glCallList(letter_C);
     glCallList(base);
     glCallList(walls);
     glPopMatrix();
     glFinish();
     glutSwapBuffers();
};

void ChangeSize(GLsizei w, GLsizei h)
{
      GLfloat fAspect;

     window_height = h;
     window_width = w;
     // prevent divide by zero
     if(h==0)
           h = 1;

     // Set viewport to window dimensions
     glViewport(0,0,w,h);
     fAspect = (GLfloat)w/(GLfloat)h;

     // Reset coordinate system
     glMatrixMode(GL_PROJECTION);
     glLoadIdentity();

     // Produce the perspective projection
     gluPerspective(90.0f,fAspect,0.1f,100.0f);
     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
};

void mykey(int key)
{
      switch (key)
      {
      case 'j':
            heading += 10.0f;
            yrot = heading;
            break;
      case 'l':
            heading -= 10.0f;
            yrot = heading;
            break;


                                    20
      case 'i':
            xrot -= 5.0f;
            break;
      case 'k':
            xrot += 5.0f;
            break;
      case 'w':
            x_distance -= (float)sin(heading*piover180) * 1.0f;
            z_distance -= (float)cos(heading*piover180) * 1.0f;

            if (walkbiasangle >= 359.0f)
            {
                   walkbiasangle = 0.0f;
            }
            else
            {
                   walkbiasangle+= 20;
            }
            walkbias = (float)sin(walkbiasangle * piover180)/1.5f;
            break;
      case 's':
            x_distance += (float)sin(heading*piover180) * 1.0f;
            z_distance += (float)cos(heading*piover180) * 1.0f;

            if (walkbiasangle <= 1.0f)
            {
                   walkbiasangle = 359.0f;
            }
            else
            {
                   walkbiasangle-= 20;
            }
            walkbias = (float)sin(walkbiasangle * piover180)/1.5f;
            break;
      case 'q':
            exit(-1);
            break;
      case 27:
            exit(-1);
            break;
      };
      glutPostRedisplay();
};

void keyboard(unsigned char key,int x, int y)
{
      mykey(key);
};

void mouselook(int x, int y)
{
      if (abs(x)<(window_width/2))
      {
            heading += 3.0f;
            yrot = heading;
      };
      if (abs(x)>(window_width/2))


                                     21
     {
            heading -= 3.0f;
            yrot = heading;
     };
     if (abs(y)<abs(window_height/2))
     {
           xrot -= 3.0f;
     };
     if (abs(y)>abs(window_height/2))
     {
           xrot += 3.0f;
     };
     glutPostRedisplay();
};

void main (int argc, char **argv)
{
      glutInit(&argc,argv);
      glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGB);
      glutGameModeString("1400x1050:16@60");
      if (glutGameModeGet(GLUT_GAME_MODE_POSSIBLE))
      {     glutEnterGameMode();
      }
      else
      {     cout << "The selected mode is not available" << endl;
            glutInitWindowSize (800,600);
            glutInitWindowPosition(0,100);
            glutCreateWindow("OpenGL Engine Prototype");
      };

     glutReshapeFunc(ChangeSize);
     glutSetCursor(GLUT_CURSOR_CROSSHAIR);
     LoadGLTextures(0,"brick.bmp");
     LoadGLTextures(1,"sky.bmp");
     LoadGLTextures(2,"grass.bmp");
     LoadGLTextures(3,"start.bmp");
     LoadGLTextures(4,"bauer.bmp");
     glutDisplayFunc(redraw);
     glClear(GL_COLOR_BUFFER_BIT);
     glFlush();
     glFrontFace(GL_CCW);
     SetupRC();
     init_letter_C();
     init_base();
     init_walls();
     glutKeyboardFunc(keyboard);
     glutPassiveMotionFunc(mouselook);
     glutMainLoop();
};




                                   22
4.1.1. Snapshots from Source Code Output




PICTURE 1. OUTSIDE WORLD




PICTURE 2. STARTING POINT OF MAZE




PICTURE 3. FIRST HALLWAY




                                    23
PICTURE 4. FIRST TURN




PICTURE 5. COLUMN/ISLAND




PICTURE 6. END OF MAZE




                           24
4.2. Function Definitions
   The following is the list of functions from the prototype source code.
   Each function is followed by the definition of the function. It is
   expected that this list will grow during the process of the build stage
   of development. Additions or changes to the code will be documented
   in the final report of Senior Design II.

init_letter_C(void)
   Test routine for pinpointing the center of the world.
init_base(void)
   Sets the texturing for the floor and the ceiling.
static void init_walls(void)
   Sets the texturing for the walls.
ChangeSize(GLsizei w, GLsizei h)
   Sets the viewpoint of the window positon, resets the coordinate system and
   produces the perspective projection.
void keyboard(unsigned char key,int x, int y)
   Accepts inputs from the keyboard and executes the appropriate command based
   upon the user input.
AUX_RGBImageRec *LoadBMP(char *Filename)
   Loads a bitmap from a disk.
int LoadGLTextures(int image_count, char *Filename)
   Load a bitmap from the disk and converts it to a texture.
void main(int argc, char **argv)
   Main function.
void mouselook(int x, int y)
   Accepts inputs from the mouse and executes the appropriate command based upon
   the user input. Allows the user to look in a different direction while walking or
   moving in anotherdirection.
void mykey(int key)
   Provides the necessary case statements for the user to interface with the 3-D world
   via keyboard inputs.
void redraw(void)
   Redraws the World after each command that is executed from an input device.
void SetupRC(void)
   Sets many of the special effect features to include: light values and coordinates, anti-
   aliasing, set lighting, position lighting, turn on/off lighting, set material color
   properties, set reflectivity effect



                                            25
4.3. Variables
   The following list of variables is from the prototype source code. It is
   expected that this list will change and/or increase during the process
   of the build stage of development. Additions or changes to the code
   will be documented in the final report of Senior Design II.

base
   type: GLuint (unsigned integer type)
   Base is the number for the list in the glCompile command used to
   render texture to the floor and ceiling.
depth_function
   type: Glenum
   Depth_function holds the value of GL_LESS used for hidden line
   elimination.
heading
   type: float
   Heading keeps track of which direction you are facing; a direction
   place holder.
texture
   type: Gluint [5]
   An array that holds the value of the bitmap:
      0 = brick.bmp
      1 = sky.bmp
      2 = grass.bmp
      3 = start.bmp
      4 = end.bmp
walkbias
   type: GLfloat
   Used for „head-bobbing‟ to give a more realistic effect as you move
   throughout the world.
walkbiasangle
   type: GLfloat
   Used for „head-bobbing‟ to give a more realistic effect as you move
   throughout the world.




                                    26
walls
  type: GLuint
  Walls is the number for the list in the glCompile command used to
  render texture to the walls of the World.
window_height
  type: int
  Stores the window height, in pixels, of the current screen
window_width
  type: int
  Stores the window width, in pixels, of the current screen
x_distance
  type: GLfloat
  x_distance holds the translation information when a callback function
  executes a movement.
xrot
  type: GLfloat
  Used when transforming a motion in the x-axis; looks up and down.
y_distance
  type: GLfloat
  y_distance holds the translation information when a callback function
  executes a movement.
yrot
  type: GLfloat
  Used when transforming a motion in the y-axis; moves left and right.
z_distance
  type: GLfloat
  z_distance holds the translation information when a callback function
  executes a movement.




                                   27
4.4. The Purpose of GLUT
   OpenGL Utility Toolkit or GLUT has become a popular library for
   OpenGL programmers. It standardizes and simplifies window and
   event management. GLUT enables the application to structure event
   handling using callback functions. First, the application opens a
   window and registers callback routines for specific events. Next, the
   application will create a main loop without an exit. In that loop, if an
   event occurs, its registered callback functions are executed. Upon
   completion of the callback functions, flow of control is returned to the
   main loop.5

4.5. GLUT Callback Function Definitions6
   The following list of callback functions are excerpts from the Red Book
   for OpenGL and is sited, inclusively, via the endnote (endnote 6) at the
   end of the section heading.
void glutInit(int int argc, char **argv);
   glutInit() should be called before any other GLUT routine, because it initializes the
   GLUT library. glutInit() will also process command line options, but the specific
   options are window system dependent. For the X Window System, -iconic, -
   geometry, and -display are examples of command line options, processed by
   glutInit(). (The parameters to the glutInit() should be the same as those to main().)
void glutInitDisplayMode(unsigned int mode);
   Specifies a display mode (such as RGBA or color-index, or single- or double-buffered)
   for windows created when glutCreateWindow() is called. You can also specify that
   the window have an associated depth, stencil, and/or accumulation buffer. The
   mask argument is a bitwise ORed combination of GLUT_RGBA or GLUT_INDEX,
   GLUT_SINGLE or GLUT_DOUBLE, and any of the buffer-enabling flags: GLUT_DEPTH,
   GLUT_STENCIL, or GLUT_ACCUM. For example, for a double-buffered, RGBA-mode
   window with a depth and stencil buffer, use GLUT_DOUBLE | GLUT_RGBA |
   GLUT_DEPTH | GLUT_STENCIL. The default value is GLUT_RGBA | GLUT_SINGLE (an
   RGBA, single-buffered window).
void glutInitWindowSize(int width, int height);
void glutInitWindowPosition(int x, int y);
   Requests windows created by glutCreateWindow() to have an initial size and
   position. The arguments (x, y) indicate the location of a corner of the window,
   relative to the entire display. The width and height indicate the window's size (in
   pixels). The initial window size and position are hints and may be overridden by
   other requests.
int glutCreateWindow(char *name);
   Opens a window with previously set characteristics (display mode, width, height, and
   so on). The string name may appear in the title bar if your window system does that
   sort of thing. The window is not initially displayed until glutMainLoop() is entered,
   so do not render into the window until then.




                                           28
   The value returned is a unique integer identifier for the window. This identifier can
   be used for controlling and rendering to multiple windows (each with an OpenGL
   rendering context) from the same application.
void glutDisplayFunc(void (*func)(void));
   Specifies the function that's called whenever the contents of the window need to be
   redrawn. The contents of the window may need to be redrawn when the window is
   initially opened, when the window is popped and window damage is exposed, and
   when glutPostRedisplay() is explicitly called.
void glutReshapeFunc(void (*func)(int width, int height));
   Specifies the function that's called whenever the window is resized or moved. The
   argument func is a pointer to a function that expects two arguments, the new width
   and height of the window. Typically, func calls glViewport(), so that the display is
   clipped to the new size, and it redefines the projection matrix so that the aspect
   ratio of the projected image matches the viewport, avoiding aspect ratio distortion.
   If glutReshapeFunc() isn't called or is deregistered by passing NULL, a default
   reshape function is called, which calls glViewport(0, 0, width, height).
void glutKeyboardFunc(void (*func)(unsigned int key, int x, int y);
   Specifies the function, func, that's called when a key that generates an ASCII
   character is pressed. The key callback parameter is the generated ASCII value. The
   x and y callback parameters indicate the location of the mouse (in window-relative
   coordinates) when the key was pressed.
void glutPostRedisplay(void);
   Marks the current window as needing to be redrawn. At the next opportunity, the
   callback function registered by glutDisplayFunc() will be called.
void glutMainLoop(void);
   Enters the GLUT processing loop, never to return. Registered callback functions will
   be called when the corresponding events instigate them
void glutIdleFunc(void (*func)(void));
   Specifies the function, func, to be executed if no other events are pending. If NULL
   (zero) is passed in, execution of func is disabled.
void glutSetColor(GLint index, GLfloat red, GLfloat green, GLfloat blue);
   Loads the index in the color map, index, with the given red, green, and blue values.
   These values are normalized to lie in the range [0.0,1.0].




                                           29
30
                   CHAPTER 5: Order of OpenGL Events
5.1. Overview
   The order of events in OpenGL is not always sequential. Some events
   can occur in reverse order with the same outcome. This chapter will
   help identify some of the major operations being performed to
   initialize an object in OpenGL. Specifically, it will outline the order of
   events when a vertex is initialized and when it is written into the
   framebuffer.     The following flowchart helps explain the major
   operations being performed. It can be seen from the flowchart that
   geometric data (vertices, lines, and polygons) follows the path through
   the row of boxes that include evaluators and per-vertex operations,
   while pixel data (pixels, images, and bitmaps) is treated differently for
   part of the process. Both pixel and vertex data undergo per-fragment
   operations and rasterization before the final data are written into the
   framebuffer.


    Vertex                                     Per-vertex
     Data                                    operations and
                                               primitive
                              Evaluators       assembly

                Display
                 List                        Rasterization      Per-fragment
                                                                 operations
                                Pixel
     Pixel                    operations
     Data                                      Texture
                                              assembly          Framebuffer

FIGURE 5. ORDER OF EVENTS.7

   All geometry or pixel data can be saved in a display list or processed
   immediately. When a display list is executed, the data is sent from the
   display list just as if it were sent by the application. Vertices
   eventually describe all geometric primitives. If evaluators are used,
   the data is converted to vertices and from that point are treated as
   vertices. Specialized vertex arrays may also be used to store vertex
   data. Per-vertex calculations are performed on each vertex, followed
   by rasterization to fragments. For pixel data, pixel operations are
   performed, and the results are either rasterized to fragments or stored
   in the texture memory, used for polygon stippling. Finally, the final
   pixel values are drawn into the framebuffer after the fragments are
   subjected to a series of per-fragment operations.8



                                      31
5.2. Geometric Operations
   Geometric data consists of a set of vertices and the type of primitive it
   describes (a vertex, line, or polygon). This is irregardless as to
   whether it comes from an evaluator, a display list, the vertices of a
   rectangle, or as raw data. Vertex data includes the (x, y, z, w)
   coordinates, as well as the following: a color index, a normal vector,
   texture coordinates, material properties, a RGBA color, and edge-flag
   data. All of these elements, except for the vertex's coordinates, can
   be specified in any order. Additionally, default values exist for each of
   these elements. The components are padded as soon as the vertex
   command glVertex*() is issued, if necessary, to four dimensions
   (using z = 0 and w = 1), and the current values of all the elements are
   associated with the vertex. After the components are padded, a
   complete set of vertex data is processed.9

5.2.1. Per-Vertex Operations
    In the per-vertex operations stage of processing, the modelview
    matrix transforms each vertex‟s spatial coordinates, while the
    normal vector is transformed by that matrix's inverse transpose and
    renormalized if specified. New texture coordinates are generated
    from the transformed vertex coordinates if automatic texture
    generation is enabled. Then, they replace the vertex's old texture
    coordinates. Finally, the texture coordinates are then transformed
    by the current texture matrix and passed on to the primitive
    assembly step.

    Additionally, when the lighting calculations are enabled, they
    conduct several transformations, to include: vertex and normal
    vector coordinates, current material, lights, and lighting model.
    These calculations generate new colors or indices that are clamped
    or masked to the appropriate range and passed on to the primitive
    assembly step. 10

5.2.2. Primitive Assembly
    Primitive assembly differs depending on whether the primitive is a
    polygon, a point, or a line. If flat shading is enabled, the indices or
    colors of all the vertices in a polygon or line are set to the same
    value. When special clipping planes are defined and enabled, they
    are used to clip primitives of all three types. Point clipping passes or
    rejects vertices, while line or polygon clipping can add additional
    vertices depending on how the line or polygon is clipped. After
    clipping has been accomplished, the spatial coordinates of each
    vertex are transformed by the projection matrix, and the results are
    clipped against the standard viewing planes x = ± &ohgr; , y = ±
    &ohgr; , and z = ± &ohgr; .


                                    32
    Any primitive not eliminated by clipping generates a selection-hit
    report, if selection is enabled. No further processing is performed.
    Without selection, perspective division by w occurs and the viewport
    and depth-range operations are applied. Also, if the primitive is a
    polygon, it is then subjected to a culling test if culling is enabled.
    Depending on the polygon mode, a polygon might convert to lines or
    vertices.

    Finally, polygons, points, and lines are rasterized to fragments,
    taking into account polygon or line stipples, line width, and point
    size. Rasterization involves determining which squares of an integer
    grid in window coordinates are occupied by the primitive. If
    antialiasing is enabled, coverage (the portion of the square that is
    occupied by the primitive) is also computed. Depth and color values
    are also assigned to each square. Depth values are slightly modified
    by a calculated offset value, if polygon offset is enabled. 11

5.3. Pixel Operations
  Pixels from the host memory are first unpacked into the proper
  number of components. The OpenGL unpacking facility handles a
  number of different formats. Next, the data is scaled, biased, and
  processed using a pixel map. Depending on the data type, the results
  are clamped to an appropriate range and either rasterized to
  fragments or written in the texture memory for use in texture
  mapping.

  However, pixel-transfer operations (scale, bias, mapping, and
  clamping) are performed if the pixel data is read from the framebuffer.
  The results are returned to processor memory after they have been
  packed into an appropriate format.

  The pixel copy operation is similar to a combination of the unpacking
  and transfer operations, except that packing and unpacking is
  unnecessary, and only a single pass is made through the transfer
  operations before the data is written back into the framebuffer. 12

5.3.1. Texture Memory
    OpenGL Version 1.1 provides additional control over texture
    memory. Texture image data can be specified from either processor
    memory or from framebuffer memory. All or part of a texture image
    may be replaced. Texture data may be stored in texture objects that
    can be loaded into texture memory. Textures that have the highest
    priorities remain in the texture memory when there are too many
    texture objects to fit into texture memory at the same time. 13


                                   33
5.4. Fragment Operations
  A texel is generated from texture memory for each fragment and
  applied to the fragment, if texturing is enabled. If fog calculations are
  enabled, they are performed next followed by the application of
  coverage (antialiasing) values, if antialiasing is enabled.

  Next comes scissoring, followed by the alpha test (in RGBA mode
  only), the stencil test, and the depth-buffer test. If in RGBA mode,
  blending is performed. Blending is followed by dithering and logical
  operation. All these operations may be disabled.

  Depending on the mode of operation, the fragment is then masked by
  an index mask or a color mask and drawn into the appropriate buffer.
  Masking occurs after the stencil and depth tests, if fragments are
  being written into the depth or stencil buffer. The results are drawn
  into the framebuffer without performing the dithering, blending, or
  logical operation. 14

5.5. Odds and Ends
  Matrix operations deal with the current matrix stack, which can be the
  modelview, the projection, or the texture matrix stack. The following
  commands are applied to the top matrix on the stack:
  glMultMatrix*(), glLoadMatrix*(), and glLoadIdentity().           The
  following commands are used to create a matrix that's multiplied by
  the top matrix, they are as follows: glTranslate*(), glRotate*(),
  glScale*(), glOrtho(), and glFrustum(). When the modelview matrix is
  modified, its inverse transpose is also generated for normal vector
  transformation.

  The commands that set the current raster position are treated exactly
  like a vertex command up until when rasterization would occur. At this
  point, the value is saved and is used in the rasterization of pixel data.
  The various glClear() commands bypass all operations except
  scissoring, dithering, and writemasking. 15

5.6. Note From the Team
  This chapter was, almost in its entirety, copied as an excerpt from the
  Red Book for OpenGL and is sited as a Reference as indicated by the
  endnote at the end of each section. As the team working on this
  project continued in its quest to develop this software application, it
  became increasingly clear that the understanding of the order of
  operations is essential to fully understanding the key processes that
  OpenGL goes through. For this reason, the team felt it was beneficial
  and essential to include this part into the design document.


                                   34
                         CHAPTER 6: System Models
6.1. Use Case
   A scenario is an instance of a use case. It represents a concrete
   sequence of interactions between one or more actors and the system.
   For this system, there are essentially two actors. The first actor is the
   team of Developers, who, for this chapter, will be henceforth called
   „Developer‟. The second actor is the user of the system, who will be
   called „Operator‟.     This system is defined by four use case:
   3DWorldIcon, ExecuteCommands, TestSystem, and DevelopeSystem.
   Each use case will be described in detail following the use case
   diagram below.



                             3DWorld




                                 3DWorldIcon



         Operator

                                ExecuteCommand




                                                          Developer
                                  TestSystem



            Test
         Coordinator
                                 DevelopSystem




FIGURE 6. USE CASE DIAGRAM




                                       35
6.1.1. Use Case Description

  6.1.1.1. 3DWorldIcon
      Use case name           3DWorldIcon
       Participating actor    Invoked by Operator
                              Invoked by Developer
       Entry Condition        1. The Operator or Developer activates
                                 the “3DWorldIcon” function on the
                                 computer terminal. 3DWorld
                                 responds by presenting a command
                                 line for the user.
       Flow of events         2. The user provides the command line
                                 with the real world coordinates of
                                 the shape of the world to be
                                 implemented.
                              3. The world is generated based upon
                                 the coordinates provided. The
                                 system also invokes the Execute
                                 Command use case.
       Exit Condition         4. Once the input coordinates are
                                 entered, this use case is terminated
                                 and ExecuteCommand is invoked.
       Special Requirements   The user must have privileges to the
                              system and have understanding as to
                              how the system is generated based
                              upon his or her inputs.




                                36
6.1.1.2. ExecuteCommand
    Use case name         ExecuteCommand
   Participating actor    Invoked by Operator
                          Invoked by Developer
   Entry Condition        1. 3DWorldIcon invokes the “Execute
                             Command” function once the
                             3DWorld has been generated by the
                             initial conditions provided by the
                             user in 3DWorldIcon.
   Flow of events         2. The user provides the commands via
                             keyboard inputs. These inputs
                             affect the overall shape of the
                             designed world. Multiple events
                             occur that transform the world
                             based up the commands being
                             executed by the user.
   Exit Condition         4. The user selects a predetermined
                             command key to terminate the
                             program.
   Special Requirements   The user must be provided with the key
                          for command execution.




                           37
6.1.1.3. TestSystem
    Use case name          TestSystem
    Participating actor    Invoked by Developer
    Entry Condition        1. The Developer activates the “Test
                              System” function to ensure proper
                              functionality of the system during
                              development.
    Flow of events         2. The Developer determines the
                              minimum system requirements
                              based upon design requirements.
                           3. The Developer drafts the test
                              procedures manual.
                           4. The Developer invokes the
                              3DWorldIcon use case and verifies
                              proper functionality.
                           5. The Developer invokes the Execute
                              Command use case and verifies
                              proper functionality.
    Exit Condition         6. When the Developer determines all
                              minimum system requirements have
                              been met.
    Special Requirements   The Developer must have the Test
                           Procedure Guide to ensure system
                           requirements.




                             38
6.1.1.4. DevelopSystem
    Use case name          DevelopSystem
    Participating actor    Invoked by Developer
    Entry Condition        1. The 3-D World requires development
                              or system modifications.
    Flow of events         2. The Developer determines that the
                              system is in need of further
                              development or a necessary
                              modification.
                           3. The Developer makes the necessary
                              changes or updates to the system.
                           4. The Developer documents the
                              changes made to the system and
                              provides comments within the
                              source code.
    Exit Condition         5. The Developer has properly
                              documented the changes made to
                              the system and has commented the
                              source code of such changes.
    Special Requirements   None.




                            39
6.2. Activity Diagram
   The Activity Diagram represents the data flow or the control flow
   through the system. Each transition represented here is triggered by
   the completion of the previous action associated with that particular
   state, also known as, an action state.

6.2.1. System Activity System

            System Access
               Granted




              Obtain user
            guide (optional)




              Logon to
               System




             Icon Double            3DWorldIcon
               Clicked                invoked




                                     Coordinate
                                    points entered




                                       Execute       Move through
                                      command           world
                                       invoked



                                      ‘Esc’ key
                                       entered




                                      Logout of
                                       system



FIGURE 7. SYSTEM ACTIVITY DIAGRAM



                                         40
6.3. State Diagram

6.3.1. Operate System

                                           f

                                                        x_ccw
           Double                          b
          Click Icon
                                                        x_cw
                                           l
                                                                               Redraw
          Enter Points                                  y_ccw                  World
                                           r

                                                        y_cw
           Generate
            World                          u

                                                        z_ccw
                                           d
            Enter
          Command
                                                        z_cw
                                           s

                                                    q           Exit
                                                                World




FIGURE 8. OPERATE SYSTEM STATE DIAGRAM

6.3.2. Develop System


                             NewCode
                            Development


     Determine                                          Add comments      Document
                                                        to source code   newCode or
    requirement                                                          modification


                              Modify
                            ExistingCode



FIGURE 9. DEVELOP SYSTEM STATE DIAGRAM



                                               41
42
                     Appendix 7: Test Procedures
7.1. Test Overview
   The Test Coordinator shall be responsible for all test procedures. Test
   procedures are necessary for the purpose of analyzing the system and
   to detect and differences between requirements and observed
   behavior.
7.2. Test Procedures

7.2.1. Introduction
    These testing procedures shall be adhered to for each test phase.
    There will be 3-phases of testing: Individual Component Test, Overall
    System Test, and Modification System Test.             The Individual
    Component Test will follow the completion of a standalone function
    within the system development. If a function does not standalone, it
    will be incorporated into testing with the next available development
    that would render standalone functionality. The Overall System Test
    will be conducted upon completion of the overall project. Finally, the
    Modification System Test will be conducted after each modification
    after the Overall System Test has been conducted.

7.2.2. Relationship to other Documents
    This test procedure manual will incorporate every pertinent aspect of
    the overall system and include relevant details from the Design
    Proposal, as well as, the information contained within this Design
    Document.

7.2.3. System Overview
    The 3-D World will be tested in accordance with the minimum system
    requirements outlined in Chapter 1 of this document. As optional
    requirements are added, these features will be test as well. The 3-D
    World, shall be tested for functionality to be certain the execution
    commands listed in the State Diagram for System Operations are all
    operational.

7.2.4. Features to be Tested/not to be Tested

   7.2.4.1. Features to be Tested:
        3DWorldIcon invokes a command line when double clicked
          3DWorldIcon accepts user input for the coordinates necessary
           to generate the world
          3DWorldIcon generates the world as expected based upon user
           inputs



                                   43
                 ExecuteCommand accepts „s‟ to begin accepting maneuver
                  commands
                 ExecuteCommand functions properly for all maneuvering
                  commands
                 ExecuteCommand terminates program when „q‟ is entered as a
                  command (quits program)

   7.2.4.2. Optional features to be tested if implemented
       Free floating environment (anti-gravitational environment)
       360 rotation about the z-axis
       Cross platform demonstration on a Silicon Graphics system
       Variable speed control

   7.2.4.3. Features not to be tested
       Texture mapping and special effects
                  Reason: This is an inherent feature of OpenGL. Though
                   texture mapping and special effects will be utilized, their
                   unique abilities are only noticeable through masterful,
                   artistic design capabilities. We prefer not to be graded upon
                   our artistic abilities.
             User Manual
                  Reason: The User Manual will be published as a final
                   deliverable during Senior Design II. It will be available for
                   users of the system but there is no critical reason as to why it
                   would need to be “tested”.

   7.2.4.4. Optional features not to be tested
       Enhanced texture mapping and special effects
                  Reason: Same as stated in 7.2.4.3.

7.2.5. Pass/Fail Criteria
    The pass/fail criteria will be determined for each feature being
    tested. These features shall be functional to the point that they are
    obviously apparent in nature. A failure of any critical component
    shall be modified and corrected. A failure of an optional feature will
    be noted but less emphasis will be placed on continued efforts to try
    and resolve the problem. This decision will be based upon time,
    money, and the inputs and advice of the Developer for that particular
    part of the project. A failure still constitutes a successful test.
    However, the test did not perform as expect, therefore resulting in a
    failed test result. Testing shall cease once all critical features have
    passed and all optional features have passed or been determined to


                                           44
    be terminated by the Test Coordinator based upon the inputs of the
    Lead Software Developer.

7.2.6. Approach
    Testing shall be accomplished to ensure the wide range of features
    implemented in this project design have successfully met there
    objectives. The critical points being tested are those that involve the
    following:
         Demonstrate the functionality of initializing the program from a
          desktop icon
         Demonstrate entering the coordinated points for the design
          shape of the world
         Proper development of the world based upon the points
          provided by the user
         Maneuverability: left, right, forward, backwards, rotate counter
          clockwise in the x-axis, rotate clockwise in the x-axis, rotate
          counter clockwise in the y-axis, and rotate clockwise in the y-
          axis. Option: demonstrate ability to move up, down, rotate
          counter clockwise in the z-axis, rotate clockwise in the z-axis,
         Proper color mapping that identifies floors, walls, and ceilings
          as such
    Other features to be tested will be based upon those additional
    options outlined in section 1.2 as determined necessary by the Test
    Coordinator. In the event that one or more of the following features
    are not tested, it will be documented and noted.
         Enhanced texture mapping and special effects
         Free floating environment (anti-gravitational environment)
         360 rotation about the z-axis
         Variable speed control
         Cross platform demonstration on an Silicon Graphics system

7.2.7. Suspension and Resumption
    Suspension of the test process shall be the result of a failed test.
    The test will be documented and noted as a successful test and
    labeled as “FAILED”. Based upon the status of the feature being
    tested, whether critical or optional, the Test Coordinator will make a
    decision, based upon the inputs of the Lead Software Developer, to
    proceed with development, postpone further development, or to
    terminate any further development. If testing is terminated and it is
    determined that further development is required, the Test


                                     45
    Coordinator will determine what parts will be tested again when
    testing resumes.

7.2.8. Testing Materials (Hardware/Software requirements)
    The following materials will be required for the testing process.

   7.2.8.1. Hardware:
         Windows Based Machine
             I.67 GHz Athlon XP 2000+
             Nvidia GeForce4 TI 4400 (128M DDR)

   7.2.8.2. Software:
       Microsoft Visual C++ 6.0
         OpenGL (graphics libraries)
         GLUT for Win32 version 3.7.6
             glut32.dll
             glut32.lib
             glut.h
    See section 3.2 for additional hardware materials and/or software
    applications that may be required for testing if optional features are
    developed.




                                        46
7.2.9. Test Cases
   The following test case scenarios encapsulate the bulk of the system
   capabilities. Systems that are optional or non-critical will be tested as
   needed if the Test Coordinator deems the process necessary.
   7.2.9.1. Test Case 3DWorldIcon_NormalUse
       Test case name          3DWorldIcon_NormalUse
       Entry Condition            Invoked by an Operator (user) who is
                                  familiar with the system and has system
                                  access
       Flow of events             1. The user double clicks on the
                                     “3DWorldIcon” to activate function
                                     on the computer terminal. 3DWorld
                                     responds by presenting a command
                                     line for the user.
                                  2. The user provides the command line
                                     with the real world coordinates of a
                                     square to implement the shape of
                                     the world to be generated.
                                  3. The world is generated based upon
                                     the coordinates provided. The
                                     system also invokes the Execute
                                     Command use case.
       Exit Condition             This test case is terminated once the
                                  input coordinates are entered and
                                  ExecuteCommand is invoked.
Special Requirements           The user must have privileges to the
                               system and have understanding as to how
                               the system is generated based upon his or
                               her inputs.




                                    47
7.2.9.2. ExecuteCommand_NormalConditions
    Use case name          ExecuteCommand_Normal
    Entry Condition        This test case is invoked by the
                           3DWorldIcon after it receives the initial
                           inputs for the design of the world
                           based upon user input.
    Flow of events         1. The Operator (user) clicks on the
                              generated world window to ensure it
                              is the active window.
                           2. Verify that the world generated is
                              relevant based upon user inputs in
                              3DWorldIcon.
                           3. The user types the letter „s‟ to start
                              the maneuverability function of
                              “ExecuteCommand”.
                           4. The user tests each critical key for
                              maneuverability. f-forward, b-back,
                              l-left, r-right, x-x_rotation_cw, c-
                              x_rotation_ccw, y-y_rotation_cw, u-
                              y_rotation_ccw.
                           5. Collision Detection will be
                              demonstrated by trying to walk
                              through a wall.
                           6. Verify proper color mapping that
                              makes it easy for the user to
                              assimilate between the floor, walls,
                              and ceiling.
                           7. Verify proper rendering of scaling,
                              transformations, and rotations, are
                              accomplished based upon the
                              command that is executed.
    Exit Condition         The user presses the „q‟ key to quit the
                           program.
    Special Requirements   The user must be provided with the key
                           for command execution.




                             48
7.2.10. Testing Schedule
    The following will be the expectant time line for all scheduled
    testing. The Test Coordinator will organize and manage all testing
    to be conducted. If a test is not conducted, for whatever reason, it
    shall be noted along with the reason for not conducting the test.

     7.2.10.1. Schedule

                 Key Date                      Test Description

                      21 July 2002 Test prototype
               1 September 2002 Test baseline system
             30 September 2002        1) Test subroutine for acceptance of
                                         multi-polygon designs.
                                      2) Perform testing of the test
                                         case3DWorldIcon_NormalUse.
                  1 October 2002 Begin single feature functionality to
                                 include: all critical maneuverability
                                 keys, collision detection, texture
                                 mapping, color mapping, and special
                                 lighting.
                30 October 2002 Test all single feature functionality
                                operations:
                                      1) Critical maneuverability keys
                                      2) Collision detection
                                      3) Texture mapping
                                      4) Color mapping
                                   Perform testing of the test case
                                   ExecuteCommand_Normal.
               7 November 2002 Test all optional features considered
                               for development
              15 November 2002 Perform final system test.
              16 November 2002 Conduct dry run for review board.
        18 - 27 November 2002 Prepare for and conduct the final
                              design review with review board.

FIGURE 10. TEST SCHEDULE




                                      49
50
                       Appendix A: Glossary of Terms
A.1. Definitions16
    The following list of definitions is an excerpt from the Red Book for
    OpenGL and is sited, inclusively, via the endnote (endnote 16) at the
    end of the section heading.
aliasing
    A rendering technique that assigns to pixels the color of the primitive being
    rendered, regardless of whether that primitive covers all or only a portion of the
    pixel's area. This results in jagged edges, or jaggies.
animation
    Generating repeated renderings of a scene, with smoothly changing viewpoint
    and/or object positions, quickly enough so that the illusion of motion is achieved.
    OpenGL animation is almost always done using double-buffering.
antialiasing
    A rendering technique that assigns pixel colors based on the fraction of the pixel's
    area that's covered by the primitive being rendered. Antialiased rendering reduces
    or eliminates the jaggies that result from aliased rendering.
bitmap
    A rectangular array of bits. Also, the primitive rendered by the glBitmap()
    command, which uses its bitmap parameter as a mask.
bitplane
    A rectangular array of bits mapped one-to-one with pixels. The framebuffer is a
    stack of bitplanes.
buffer
    A group of bitplanes that store a single component (such as depth or green) or a
    single index (such as the color index or the stencil index). Sometimes the red,
    green, blue, and alpha buffers together are referred to as the color buffer, rather
    than the color buffers.
C
    God's programming language.
C++
    The object-oriented programming language of a pagan deity.
color map
    A table of index-to-RGB mappings that's accessed by the display hardware. Each
    color index is read from the color buffer, converted to an RGB triple by lookup in the
    color map, and sent to the monitor.
current raster position
    A window coordinate position that specifies the placement of an image primitive
    when it's rasterized. The current raster position and other current raster parameters
    are updated when glRasterPos() is called.




                                            51
double-buffering
   OpenGL contexts with both front and back color buffers are double-buffered.
   Smooth animation is accomplished by rendering into only the back buffer (which
   isn't displayed), then causing the front and back buffers to be swapped. For
   additional information, see glutSwapBuffers().
edge flag
   A Boolean value at a vertex, which marks whether that vertex precedes a boundary
   edge. glEdgeFlag*() may be used to mark an edge as not on the boundary. When a
   polygon is drawn in GL_LINE mode, only boundary edges are drawn.
eye coordinates
   The coordinate system that follows transformation by the modelview matrix and
   precedes transformation by the projection matrix. Lighting and application-specific
   clipping are done in eye coordinates.
framebuffer
   All the buffers of a given window or context. Sometimes includes all the pixel
   memory of the graphics hardware accelerator.
geometric model
   The object-coordinate vertices and parameters that describe an object. Note that
   OpenGL doesn't define a syntax for geometric models, but rather a syntax and
   semantics for the rendering of geometric models.
geometric primitive
   A point, a line, or a polygon.
image
   A rectangular array of pixels, either in client memory or in the framebuffer.
image primitive
   A bitmap or an image.
index
   A single value that's interpreted as an absolute value, rather than as a normalized
   value in a specified range (as is a component). Color indices are the names of
   colors, which are dereferenced by the display hardware using the color map. Indices
   are typically masked rather than clamped when out of range. For example, the index
   0xf7 is masked to 0x7 when written to a 4-bit buffer (color or stencil). Color indices
   and stencil indices are always treated as indices, never as components.
jaggies
   Artifacts of aliased rendering. The edges of primitives that are rendered with
   aliasing are jagged rather than smooth. A near-horizontal aliased line, for example,
   is rendered as a set of horizontal lines on adjacent pixel rows rather than as a
   smooth, continuous line.
local light source
   A source of illumination which has an exact position. The radiating light from a
   local light source emanates from that position. Other names for a local light source
   are point light source or positional light source. A spotlight is a special kind of local
   light source.




                                            52
matrix
   A two-dimensional array of values. OpenGL matrices are all 4 × 4, though when
   stored in client memory they're treated as 1 × 16 single-dimension arrays.
modelview matrix
   The 4 × 4 matrix that transforms points, lines, polygons, and raster positions from
   object coordinates to eye coordinates.
modulate
   A method of calculating color values during texture application, where the texture
   and the fragment colors are combined.
normal
   A three-component plane equation that defines the angular orientation, but not
   position, of a plane or surface.
object
   An object-coordinate model that's rendered as a collection of primitives.
object coordinates
   Coordinate system prior to any OpenGL transformation.
parameters
   Values passed as arguments to OpenGL commands. Sometimes parameters are
   passed by reference to an OpenGL command.
pixel
   Picture element. The bits at location (x, y) of all the bitplanes in the framebuffer
   constitute the single pixel (x, y). In an image in client memory, a pixel is one group
   of elements. In OpenGL window coordinates, each pixel corresponds to a 1.0 × 1.0
   screen area. The coordinates of the lower-left corner of the pixel are x,y are (x, y),
   and of the upper-right corner are (x+1, y+1).
primitive
   A point, a line, a polygon, a bitmap, or an image. (Note: Not just a point, a line, or a
   polygon!)
projection matrix
   The 4 × 4 matrix that transforms points, lines, polygons, and raster positions from
   eye coordinates to clip coordinates.
rasterized
   Converted a projected point, line, or polygon, or the pixels of a bitmap or image, to
   fragments, each corresponding to a pixel in the framebuffer. Note that all primitives
   are rasterized, not just points, lines, and polygons.
rendering
   Conversion of primitives specified in object coordinates to an image in the
   framebuffer. Rendering is the primary operation of OpenGL - it's what OpenGL does.
RGBA
   Red, Green, Blue, Alpha.
RGBA mode
   An OpenGL context is in RGBA mode if its color buffers store red, green, blue, and
   alpha color components, rather than color indices.



                                            53
single-buffering
   OpenGL contexts that don't have back color buffers are single-buffered. You can use
   these contexts for animation, but take care to avoid visually disturbing flashes when
   rendering.
spotlight
   A special type of local light source that has a direction (where it points to) as well as
   a position. A spotlight simulates a cone of light, which may have a fall-off in
   intensity, based upon distance from the center of the cone.
tessellation
   Reduction of a portion of an analytic surface to a mesh of polygons, or of a portion
   of an analytic curve to a sequence of lines.
texel
   A texture element. A texel is obtained from texture memory and represents the
   color of the texture to be applied to a corresponding fragment.
textures
   One- or two-dimensional images that are used to modify the color of fragments
   produced by rasterization.
texture mapping
   The process of applying an image (the texture) to a primitive. Texture mapping is
   often used to add realism to a scene. For example, you can apply a picture of a
   building facade to a polygon representing a wall.
texture matrix
   The 4 × 4 matrix that transforms texture coordinates from the coordinates in which
   they're specified to the coordinates that are used for interpolation and texture lookup.
texture object
   A named cache that stores texture data, such as the image array, associated
   mipmaps, and associated texture parameter values: width, height, border width,
   internal format, resolution of components, minification and magnification filters,
   wrapping modes, border color, and texture priority.
transformations
   The warping of spaces. In OpenGL, transformations are limited to projective
   transformations that include anything that can be represented by a 4 × 4 matrix.
   Such transformations include rotations, translations, (nonuniform) scalings along the
   coordinate axes, perspective transformations, and combinations of these.
viewpoint
   The origin of either the eye- or the clip-coordinate system, depending on context.
   (For example, when discussing lighting, the viewpoint is the origin of the eye-
   coordinate system. When discussing projection, the viewpoint is the origin of the
   clip-coordinate system.) With a typical projection matrix, the eye-coordinate and
   clip-coordinate origins are at the same location.




                                            54
window coordinates
   The coordinate system of a window. It's important to distinguish between the names
   of pixels, which are discrete, and the window-coordinate system, which is
   continuous. For example, the pixel at the lower-left corner of a window is pixel (0,
   0); the window coordinates of the center of this pixel are (0.5, 0.5, z). Note that
   window coordinates include a depth, or z, component, and that this component is
   continuous as well.
wireframe
   A representation of an object that contains line segments only. Typically, the line
   segments indicate polygon edges.




                                           55
56
                           Appendix B: Acronyms
B.1. Acronyms List
2-D   Two Dimensional
3-D   Three Dimensional
API   Application Programming Interface
CASE Computer Aided Systems Engineering
CASE*Method         A structured approach to engineering systems in a data processing
                    environment
DDR Double Data Rate (Memory)
GCC GNU Compiler Colection
GL    Graphics Libraries
GLUT Graphics Library Utility Tookit
RAM Random Access Memory
RGBA Red, Green, Blue, Alpha
UML Unified Modeling Language
UNIX Operating System developed by programmers at Bell Laboratories in Murray Hill,
     New Jersey in 1969




                                          57
58
         Appendix C: Executing Commands in 3-D World
C.1. Explanation
  The following is the necessary list of commands necessary for moving
  about within the 3-D World. Additional commands may be added and
  will be included in the revision of this document at the end of Senior
  Design II. In addition to this list of commands, the user of the system
  will also have to be briefed on the required control access to the
  system, as well as, how to launch the program once system access is
  achieved.    Further guidance will be necessary once the system
  becomes operation for multifaceted polygons.
C.2. List of Commands
  w - move forward
  s - move backward
  i - look up
  k - look down
  j - turn left
  l - turn right
  mouse – looks up and down and turns left and right
  esc key - exits program




                                  59
60
                                          Reference:

1
         Richard Barker, CASE*Method – Tasks and Deliverables, (Belmont, CA: Addison-Wesley
Publishing Company, 1990) Pg. 1-3.
2
        Bruegge, Bernd & Dutoit, Allen H, Object-Oriented Software Engineering, (Upper Saddle River,
New Jersey, Prentice Hall, 2000), Pg. 172.
3
        Barker, Pg. 9-3.
4
      Roy R. Friedman, “How Bresenham’s Algorithm Draws Lines Quickly,” MiniMicro Systems,
November 1983, Pg. 204.
5
        Mason Woo and others, OpenGL® Programming Guide, The Official Guide to Learning OpenGL,
Version 1.2, 3rd ed., (Boston: Addison-Wesley, 1999), Pg. 656.
6
        Ibid.
7
        Ibid, Pg. 594.
8
        Ibid.
9
        Ibid, Pg. 595.
10
        Ibid.
11
        Ibid, 596.
12
        Ibid.
13
        Ibid, Pg. 597.
14
        Ibid.
15
        Ibid, 598.
16
        Ibid, Pg. 685.




                                                 61

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:11/6/2011
language:English
pages:67