WPI Computer Science Department

Computer Science Department
------------------------------------------

CS 543 Homework 1 Fall Semester 2013
Due by Tuesday, September 24, 2013 submitted by class time (10/100 points)


Homework 1: PoliBook, an interactive polyline viewer and editor

Homework 1 Overview

The aim of this project is to get you comfortable with working in 2D using OpenGL 4.0. You will be setting viewports, world windows, drawing and tiling polylines, rendering fractals and exploring keyboard and mouse interaction routines. You will create a program Polibook which views polyline files in interesting ways and also allows you to interactively draw your own polylines onto the screen. Here goes:

Step 1: Read more polyline files in GRS format:

Starter code is provided to ensure that your code runs on the zoolab machines right away. You can get the HW1 starter code [ HERE ] Use this starter code to develop your programs. The following polyline files are in the GRS format:

dino.dat
birdhead.dat
dragon.dat
house.dat
knight.dat
rex.dat
scene.dat
usa.dat
vinci.dat

The structure of GRS files is:


First, modify the starter code to read in one of the GRS files. The plan is that when you re-compile it, the polyline file is drawn on the screen. There are a few things you should note for your implementation.
  1. Be careful with how you pass parameters to the glViewport( ), Ortho2D( ) commands. Make sure you understand how they work.
  2. The "extent" line of the GRS file will be used to set the world window i.e. passed to Ortho2D( )
  3. If you look at the vertex coordinates of some of the GRS files, they are specified in floating point numbers, so you'll have to use float or double formats as appropriate. For instance, the x and y coordinates of the vertices of dino.dat are integers, while the vertices in the other GRS files are floating point numbers.
  4. Note that a lot of the GRS files start with comments. You can either manually cut those out or read them in and dump them in your program.
  5. The format for dino.dat is a little different in that it doesn't have the window dimensions (or comments) right at the top. Therefore, off the bat, a program which reads other GRS files without problems will have new problems with dino.dat file. You can either throw in a dummy extents window at the top of dino.dat or come up with a solution that works. Hint: a world window of (0,640,0,480) should work!!
Homework 1 diagram

Summary of Your program behavior
The figure above shows the layout of a polyline viewer you should produce. At the top of your viewport, 10 thumbnails (9 thumbnails of polylines above + 2 occurrences of vinci.dat) of the polyline files should be lined up. These 10 thumbnails should ALWAYS be visible at the top edge of the viewport whenever your program is running. The larger drawing area below the thumbnails is the main drawing area in which all drawing will be done. On start up, choose one of the polyline files to draw in the main drawing area as a default. The thumbnails AND main drawing automatically resize if the viewport is expanded or resized.

Clicking on any thumbnails lined up at the top should make the corresponding polyline file the current drawing and draw a larger version of the polyline file to fill the main drawing area while maintaining aspect ratio. This is also known as the 'p state'. More details on the program behavior is given below. Your program should also have the following behavior and user (keyboard and mouse) interaction capabilities when you run it:

Event: A key is pressed:

Polyline drawing diagram

Note: States (p and t) are polyline viewing states in which you can draw polyline files stored in a .dat file. States (e, m and d) are polyline drawing states. State e is the initial drawing state and states (m and d) are only accessible from state e. In the drawing states, you should be able to accept and draw new polylines onto the screen, but your program does NOT have to be able to edit the provided ones (e.g. dino.dat, usa.dat, etc). You also don't have to be able to save or write out the polyline file drawn on the screen to a file. You may choose to do that but no extra credit will be given. Make sure that reshape works for all states (p, t, e, m, d and g). i.e. if the user grabs the lower right corner of the window and increases or reduces the screen window size, whatever was drawn in it before (and thumbnails) is redrawn to the largest possible size, without distortion (i.e. always maintain correct aspect ratio for each polyline file when drawn either as thumbnails or in the main drawing window).

Important Notes: No deprecated OpenGL commands, fixed function commands (glBegin, glVertex, etc) or immediate mode drawing commands should be used in your program. All drawing should be done using shaders, retained mode, Vertex Buffer Objects, and glDrawArrays similar to the code in your textbook (and in the starter code)

Submitting Your Work

Your final submission must be configured to work and fully tested in the zoolab. Points will be docked for submissions that do not compile or require ANY modifications to compile. The starter Visual Studio package provided is configured to work in the zoolabs. It is strongly advised that you use the starter package to avoid porting problems at the end. Porting OpenGL code is non-trivial due to platform differences. Make sure to double-check that everything works before submitting. Submit all your executable and source files. Put all your work files (Visual Studio solution, OpenGL program, shaders, executable and input files into a folder and zip it. Essentially, after your project is complete, just zip the project directory created by Visual Studio. Submit your work through turnin. Do NOT email me or the grader your homework!!

Create documentation for your program and submit it along with the project inside the zip file. Your documentation can be either a pure ASCII text or Microsoft Word file. The documentation does not have to be long. Briefly describe the structure of your program, what each file turned in contains. Explain briefly what each module does and tie in your filenames. Most importantly, give clear instructions on how to compile and run your program. MAKE SURE IT RUNS before submission. Name your zip file according to the convention FirstName_lastName_hw1.zip

General Hints

Here are a more few hints you might find useful:


[Feedback] [Search Our Web] [Help & Index]

[Return to the WPI Homepage] [Return to CS Homepage]

mailto:emmanuel@cs.wpi.edu