Project List

Project 1

In OpenGl, create an architectural drawing using orthographic projection in either 2D or 3D.

The orthographic projection should be defined in terms of the viewport width and height.

The architectural drawing should display four views of a simple building. The four views are : 1. front of building, 2. left ( or right) side of building, 3. top of building, 4. back of building.

Minimal requirements for building definition

Use of 2D polygons to define the building. The front of the building is made up of a rectangle (containing a centered door- a smaller rectangle) and a triangle for the roof. The side of the building is made up of a rectangle (containing two equally spaced windows- smaller rectangles) and a quadrilateral for the roof. The back of the building is made up of a rectangle (containing an offset door-a smaller rectangle) and a triangle for the roof. The top of the building is made up of two quadrilaterals. If this is unclear I can draw, very unartistically, the views in class.

Polygons must be filled and colored.

You may hard code the polygon vertices to the viewport dimensions with the understanding that all views are displayed in a window of size (400, 400). That is, each view is displayed in a ~(100,100) area. This is really not a good solution and won't give you a chance to play with transformations.

Refer to glPolygonOffset(), in the Red Book, to determine how to place a door polygon on a wall polygon!

Minimal requirements for viewport

The views should be placed in the viewport in the following order : upper-left : view 1, upper-right : view 2, lower-left : view 3, lower_right : view 4. Each view should be centered in its respective quadrant. The viewport should be nicely subdivided to offset each quadrant using thick lines, polygons, different background colors, or some other technique of your choice.

Improvements

Handin - printout the first page of your source  code (for my comments and grade assignment) and drop lab folder (source code only!) on moodle. Your folder must be named exactly as CS300Project1YourName, where you supply your own name for "YourName".

Each team must write a one page paper (minimal) describing their design and how each member contributed to the final product. A hard copy of the write up should be turned in with source code.

Hints

Vertex arrays are really helpful. If you go the 2D route, translation and rotation can save you from having to redefine similar polygons used in the same or different view(s). If you go the 3D route then you definitely want to use translation and rotation.

Project 2

In OpenGl, create an animated 3D hierarchical object.

A hierarchical object is one in which parent object transformations (in part or all) are applied to children objects. It is best to think of a hierarchical object represented in a tree structure. The figure of a person could be represented in a tree with the head as the root, the trunk as the child of the root, the right/left upper arms as children of the trunk, the right forearm as a child of the right upper arm and so on. Transformations to the right upper arm would also, in part, be applied to its child, the right forearm. Certain transformations such as scaling might be isolated to just affect a particular object.

You may be as creative as you like in defining a hierarchical object : it might be an animate object (biped, quadraped, uniped(?), etc.) or a jointed inanimate object (robot arm, etc.). In both cases the object should be recognizable as a real world object, not just a hodge-podge of jointed shapes. In both cases you should restrict the transformations applied to the object so that its behavior is a reasonable facsimile of its real world behavior; i.e. real elbows can't rotate 360 degrees.

Animating the hierarchical object requires the object to go through a sequence of predefined transformations. You might decide to create a biped that is running, walking, or dancing, as examples.

Minimum requirements for hierarchical figure definition

Smooth, filled and colored 3D polygons must be used. Surface normals for each polygon must be defined. You may use the GLUT solid objects with predefined normals (makes life easy). The figure must contain at least eight separate objects. These eight objects must define at least 4 parent/child relationships. Example : two upperarms/two forearms, two thighs/two lowerlegs. Some transformations applied to parent objects must also affect its children. You must use pop and push to manage the matrix stack. You must use translation and rotation transformations. Use of scaling is your choice.

Minimum requirements for the scene

A least one positional light must be used (diffuse or ambient). Material properties must be defined for scene objects (minimally diffuse). You must use the depth buffer. You must use double buffering. If you scale objects you must renormalize surface normals. You may use a parallel or perspective projection. Examples are given below.

In main

glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);

Globals and init

//set up material colors

GLfloat field_diffuse[4] = { 0.5, 1.0, 0.6, 1.0}; //slightly green running surface

GLfloat trunk_diffuse[4] = { 0.5, 0.7, 1.0, 1.0}; //a blue jersey

GLfloat body_diffuse[4] = {0.98, 0.7,0.8, 1.0}; //pink skin tones

//set up lighting, smooth shading, depth tests, normalization

void init(void) {

GLfloat light_position[] = { 0.2, 0.5, 2.0, 0.0 };

GLfloat light_ambient[] = {0.8,0.9,0.98,1.0};

glClearColor (0.5,0.7,1.0, 0.0);

glShadeModel (GL_SMOOTH); //smooth shaded polygons

glLightfv(GL_LIGHT0, GL_POSITION, light_position); //light position

glLightfv(GL_LIGHT0,GL_AMBIENT, light_ambient); //a slightly red ambient light

glEnable(GL_LIGHTING); //enable lighting

glEnable(GL_LIGHT0); //enable the first light = light0

glEnable(GL_DEPTH_TEST); //depth test performed

glEnable(GL_NORMALIZE); } //if scaling is used then renormalize normals

In display

glMaterialfv(GL_FRONT,GL_DIFFUSE, body_diffuse); //define color of next object (and all others without definition)

glutSolidCube(1.0);

....................................

glutSwapBuffers(); //at end of display function

Minimal requirements for animation

You must define several new GLUT callback functions : GlutIdleFunction, GlutVisibilityFunction. The idle function defines the sequence of animations that the object goes through. The visibilty function defines when the object is visible.

You must add a menu to the Glut window environment for your application. Minimally the menu will allow the user to stop/start the animation and quit the application. You must write a function to handle menu selections.

You may add keyboard functionality if you so desire.

Examples follow.

In main

................................

glutIdleFunc(Animate);

glutVisibilityFunc(Visible);

glutCreateMenu(menuSelect);

glutAddMenuEntry("Marathon Man", 1); //start animation

glutAddMenuEntry("Take a breather", 2); //stop animation

glutAddMenuEntry("Quit", 3); //quit

glutAttachMenu(GLUT_RIGHT_BUTTON);

....................................

Visibility function : this should be sufficient, moving is a GLboolean initialized to GL_TRUE, state is a predefined GLUT variable

void Visible(int state) {

if (state == GLUT_VISIBLE) {

if (moving) glutIdleFunc(Animate); } //if visible and moving then animate it

else { if (moving) glutIdleFunc(NULL); } } //if invisible and moving then stop animation

Animation function : this depends on what you are doing with transformations but here is a partial example that will give you the framework.

void Animate(void) {

if(forward && (vert < 60)){ //forward is a boolean defining a forward/backward movement, vert is used for //rotations

vert += 4; }

else if (forward && (vert >= 60)){

forward = !forward;

vert -= 4; }

else if (!forward && (vert > -60)){

vert -= 4; }

...................................................

glutPostRedisplay(); }

Handling Menu selections : here is a very basic example, it should get you going.

void menuSelect(int value) {

switch (value) {

case 1: moving = GL_TRUE; //start the animation

glutIdleFunc(Animate); break;

case 2: moving = GL_FALSE; //stop the animation

glutIdleFunc(NULL); break;

case 3: exit(0); break; } } //quit application

Handin - printout the first page of your source  code (for my comments and grade assignment) and drop lab folder (source code only!) on moodle. Your folder must be named exactly as CS300Project2YourName, where you supply your own name for "YourName".

Each team must write a one page paper (minimal) describing their design and how each member contributed to the final product. A hard copy of the write up should be turned in with source code.

Project 3

HUGE and IMPORTANT NOTE: No projects will be graded unless a "ReadME" file is included in the project upload folder. A readme file, in this case, explains user interaction controls and how to execute the program. Additionally, no projects will be graded if they contain "poorly" developed documentation or are non-modular in design - names of authors, purpose of program, known bugs, user interaction, method/function explainations, complex code segment explaination, variable explaination, etc. must be included in the documentation of your program.

In OpenGl, create a 3D world through which an observer may navigate.

Minimum requirements for 3D world

The world is obviously bounded by the clipping planes, and if the observer crosses a clip plane then nothing in the world is visible. Construct a boundary for your world within the projection's clipping planes. It will be easier to specify an orthogonal projection for your world : the test for intersection will not require testing against sloping clip planes but only against horizontal/vertical clip planes. The observer should not be allowed to move outside of the world's boundaries. Identify your boundaries using some mechanism of your choice, i.e. perhaps some very thin rectangles positioned as the floor, right, left, and back sides, or perhaps a simple grid of vertical and horizontal lines, anything that gives a visual clue as to the world boundaries. Texturing the boundaries would be a nice touch.

The world should contain at least three different obstacles that the observer can navigate around. The obstacles can be any 3D object of your choice. You should try to use at least one of the analytical objects from the glut or glu libraries as an obstacle. Obstacles can be complex hierarchical objects. The obstacles must be placed within the boundaries of the world and at different positions in the world. You should probably make the obstacles stationary to control the complexity of navigation.

Not a requirement but try to get the following going: At least one obstacle is specified with a bounding box that constrains the navigator from moving through the obstacle. The boundaries of the box will need to be checked each time the viewpoint position is modified. You can specify a bounding box for an analytical object based on its maximum width, height, and depth - the inside bounding box test will be simplified and this is a reasonable heuristic.

You may allow the navigator to move through the other obstacles; some neat effects are possible here.

Smooth, filled and colored 3D polygons must be used. Surface normals for each polygon must be defined or predefined by the object definition (glut/glu objects). Textured objects may be used.

A least one positional light must be used (ambient-diffuse/specular) that moves with the navigator. Other lights may be used for special effects within the world. Material properties must be defined for scene objects: try to include at least one highly specular object as an obstacle. You must use the depth buffer. You must use double buffering.

Minimum requirements for navigation

You must use the gluLookAt command to move the navigator through your world. The command captures the observers position, (ex,ey,ez), where the observer is looking (cx,cy,cz) and the up vector postion (upx,upy,upz). You should probably leave the up vector specified as (0,1,0) but it would be fun to play with this. Use keyboard controls to modify the observer's position and where the observer is looking. You might constrain the observer to look only within a 180 degree arc from their current position ( so they can't look over their back). You should provide a key control to return the navigator to a default position and line of sight.

Note: as you play with the gluLookAt command realize that just moving the observer's position or just the line of sight will cause objects to move out of the observer's view. This should be expected.

Demo

Be sure your demonstrator completely understands the navigation capabilities of your program. The demonstrator should compose a sequence of movements through the world demonstrating the world boundary collision test, any obstacle collision tests that are implemented, and an obstacle navigation.

Texturing

There are quite a few texturing examples in the openGL text. These examples build the texture within the program. If you don't want to deal with image files then just play with these. You will find several texturing examples in a Texture folder on the server. Find some better files or make your own: only two of the .tga files are nice (image1 and image4). Quite a few of the .rgb files are nice and all of them looked cool when using the GL_SPHERE_MAP attribute.

Handin - printout the first page of your source  code (for my comments and grade assignment) and drop lab folder (source code only!) on moodle. Your folder must be named exactly as CS300Project3YourName, where you supply your own name for "YourName".

Each team must write a one page paper (minimal) describing their design and how each member contributed to the final product. A hard copy of the write up should be turned in with source code.

Project 4 (link)

Handin - printout the first page of your source  code (for my comments and grade assignment) and drop lab folder (source code only!) on moodle. Your folder must be named exactly as CS300Project4YourName, where you supply your own name for "YourName".

Each team must write a five page paper (minimal) describing their design and how each member contributed to the final product. A hard copy of the write up should be turned in with source code.