Answers in BLUE

Homework 4, due Thurs Sep 27 Solution

Hand in your solution on RPILMS. Each team should submit their solution under only 1 student's name. The other student's submission should just name the lead student. (This makes it easier for us to avoid grading it twice.) For programming exercises, hand in code and screen dumps. We won't run your code, but will use the screendumps to judge how it worked.

This homework is a chance to be creative.

In class, I've showed two extremes in efficiency for drawing.

  1. At one end, the program's display callback routine would have a loop to repeatedly call glTranslate, glBegin(GL_POLYGON), ... glVertex3f ... glEnd.
  2. At the other extreme, as in cube2.cpp, the program would call glDrawElements in in a display list in the setup. The display callback called only glCallList, once.

This homework is to test whether version 2 above really is faster. You are to:

  1. Write two test programs, each to read an integer N, and then draw N shaded polygons. N might be in the thousands. One program should follow the 1st strategy above, and the other the 2nd.
    In the latter case, a loop might be used to set up its arguments before calling glDrawElements once for all the polygons. You don't need to use glTranslate.
    Don't draw all the polygons exactly on top of each other. Offset them a little.
  2. Push each program to the limit with ever larger N, until something breaks. Perhaps the program crashes, or maybe it takes too long. Report whether version 2 really is faster. Force each image to redraw and report the time, as a function of N, for both versions.

Also report what type of system you're running on, especially the graphics card if you know it.

Total: 20 points.

See speedtest1.cpp, speedtest2.cpp, and speedtest3.cpp, which I discussed in class.

I saw that an explicit for loop with many iterations slowed things down a lot, but the display list didn't help; actually it slowed things a little on my machine. This is probably totally HW-dependent. YMMV