add a function to define colors using X11 color values (0-255) to avoid the integer problem. add a function to draw a flat quadrilateral (or even a polygon, if I can figure out variable arguments) that defines a normal for it. That way, the barn can have normals and be easily lit. determine bb and ref point for teddy bear, including the one in 03 and 06 and in tw. Maybe use the one in tw exclusively, to avoid redundancy? recode the mobile to emphasize drawing in your own coordinate system; we should be able to rearrange items on the mobile very easily. Document the bb and ref point for each piece add "scene" to 05-frustumPicture resolve light movement in 08-teapot and 08-teddybear eliminate redundant copies of teddybear code simplify coding in 09-spotlightDemo.cc and move unit square to TW complete 09-ordering fix 10-cokeSilhouette and 10-curveDraw. Can we make a curveDraw3D? rename files to have initial letters unshifted fix code in 11-cokeBottle, 11-flag, and 11-dome make a 07-VectorFun2D make a vectorDraw program for Robby make a twArrow function. Redo keyboard interface to make it easy to increment/decrement a value, using +/- keys. Implement a function to move the VRP closer/farther from the center. fix error in 18-shadowDemo. look at coding of 15-movingMobile, similar to the earlier one. write up "checklists" and "ordering requirements." For example, bounding box has to be specified before twMainInit. (Should they be combined?) keyboard callback to advance animation by one frame demo showing the difference between zooming and moving closer, maybe using two windows? Consider twPushMatrix and twPopMatrix that counts the depth, and an twDisplayEnd() function that checks the count and also does the swapBuffers and stuff. Consider getting rid of twVertexArray and simply requiring the bounding box to be specified in twMainInit. XX Code the bicycle start database with polyhedra and colors/materials XX tutor with texture mapping combined with materials. Assume gray light. write man pages for all tw functions and install on all clients. note: for reasons I don't understand, you must have a depth buffer if you use twDrawString. change twSolidCylinder so that its drawn the same way as twCylinder. Also, change the name, since OpenGL uses "solid" to mean "not wire" swap the barn code in TW for the one in 03-Fence, since the latter is better. take over glutInit and supply -gldebug automatically. rewrite drawunitsquare to do texture coordinates. Actually, it does, but each tiny triangle is a copy of the whole texture. Maybe change it to use linear Bezier routines to generate vertices and texture coordinates? why does texture-mapping change the drawing color? figure out what the heck I was doing with the texture mapping onto a cylinder (see ~/distrib/cylinder-flag.c). It had to do with the bounding surface idea generalize twLoadTexture to allow arguments for GL_REPEAT/GL_CLAMP, GL_DECAL/GL_MODULATE/etc. and GL_LINEAR/GL_NEAREST. Either that, or re-modularize it. recode moving mobile like the stationary one in twSaveFrame, use glGet(GL_VIEWPORT) to find out what the window size is, instead of requiring the user to tell us. Yilun says that twDrawUnitSquare flips the texture (like scale -1) when we cross a coordinate axis. Investigate. Fix compiler warnings in tutors/shapes Fix errors in VectorFun2D and VectorFun3D. Figure out how best to use those demos. Check with Nate Robins and Michael Sweet about including their work in TW. fix Nate Robbins texture-mapping tutor, since the images are upside down. Figure out how to create a TWFILEPATH, which is a list of directories to look in. Default value will be $TWHOMEDIR/textures and $TWHOMEDIR/objects, since those are the two places where files might be dynamically loaded from. Can also add $TWHOMEDIR/f05 and $TWHOMEDIR/f06 to it. Maybe use kpathsearch, but that seems to be Tex-specific. Many, many programs use colon-delimited paths to load stuff from; there must be an easy library function for this. Implement an "architectural display" mode, where the figure is viewed from +X, +Y, +Z and (+X,+Y,+Z), as in Maya. It would make certain screen shots much easier to do. Go through everything in the readings, including all the code. Lectures should be summaries and exercises. Put the robot in TW, so we can discuss the modeling/modularity ideas there. Decide whether assignments with required figures and creative figures are worth 200 points or 100 points. Talk about perp product and how to compute normals. Also, document the GLM code that does normal computation and smoothing. Implement drawTexUnitSquare that draws a unit square with texturing. Eylul suggested this. implement a glmReverseNormals for objects (such as the sax) that seem to have the normal vectors reversed. talk about culling faces for pictures on the wall as well as the walls themselves. talk about modularity with respect to objects in the scene: putting the sheet music with the piano, or even the poster with the wall. Talk about using loops and other abstractions to do repetitive structures, such as mullions on a window. Talk about Dan Cliburn's navigation code. Talk also about his maze-building code. Talk about having more than one animation moving simultaneously, with independent starting and stopping. I imagine a demo in which the keys from 0-9 turn on 10 different parts of the mobile. Talk about having stuff move with the camera (e.g., crosshairs or the balls that Agnes used). Teach the TW geometry code when teaching geometry. Named constants for texture IDs? Why doesn't "back up" work anymore? Implement a simple "frame" figure that is just three lines radiating from a point (red along x, green along y, and blue along z) to make it easier to figure out the frame. Maybe unit-length lines? It would take two minutes to implement. Change the material and lighting tutor to use both of the TW shortcuts: twColor and twGrayLight. Put in two objects (a sphere and twDrawUnitSquare), with different materials. Change all uses of twColor to require a four-place array, since the manual says that it assumes such an argument, and it would really stink to have something access the "fourth" component of a twTriple and get some weird value. However, it's distressing not to be able to check that the w component is equal to one, so it would be nice to have some kind of global assertion (default true) that transparency is not being used. Then twColorOkay could check that w=1. For now, I'm going to continue to take the risk that using twTriple will be okay. Do some head tracking with the wiimote or the Mac's built-in camera. Daniel Bilar sent me a link to a video about it. Also, look at PyMol!