NEW: Tips and clarrifications NEWER: When you "Show light maps" turn off linear interpolation. That is, use GL_NEAREST as the filtering modes. The reference solution now does this. There was also a bug in the reference solution when you looked from under the table. That has mostly been fixed - some aliasing artifacts still remian.
As Lithtech does all the lighting for you, we'll step outside for this stage and work with OpenGL to use some lighting techniques discussed in the course. You might prefer to think of this as programming assignment 2, rather than project stage 2.
You will be provided with a project skeleton that draws an simple room with a table and some paper planes flying around in it. The room is completely unlit. Your job is to light it.
There is a reference solution available that implements tasks 1 and 3, but not 2. To move around, button one down causes the view to move around the room, button 3 down causes the view to move closer or further from the center of the room (like zoom) and a few keys probably do something too.
The skeleton uses FLTK, the graphics toolkit used in CS 559, to look after all the user interface issues. It uses OpenGL for the rendering. It is written in (barely adequate) C++, and uses the STL (just a little). The skeleton has all the infrastructure to do the required tasks, such as the user interface buttons and the state management functions. It doesn't have the core code required to actually implement the tasks.
You are free to rewrite any part of the skeleton, or even work in a different graphics or user interface language. However, the scene you demonstrate should look like the one in the skeleton - it's that way for a reason.
As before, there are multiple tasks to perform. Your group gets points for each task and those points are evenly divided among the group members. The maximum for any individual is 50.
Each static (not-moving) polygon in the environment that has the does_light_maps flag set should be lit using light maps when the light map interface button is down. There are several details:
Note that currently the skeleton has planes as being lit with light maps. If you just do this part of light maps, then you should turn light maps off for the planes in room.cpp at the point when the plane meshes are created.
Make sure that light maps are enabled for the planes, and update the light maps as the planes move. You should see significant changes in the maps as the plane moves. On several planes the angle between the body of the plane and the light changes significantly, resulting in large illumination changes. Note also that the planes have a fixed map resolution.
To do this you need to change the texture pixels on each frame and tell OpenGL that it has new pixels. You could also keep deleting and creating the texture object, but that is not necessary.
Each plane should cast ground-plane shadows onto only the wall, floor and ceiling of the room. They should not cast shadows into each other or the table. In fact, ignore the table for this task.
This task is not explicitly supported by the skeleton, but just use the infrastructure for shadow volumes (the interface, the flags, etc). If you do this and shadow volumes then you'll have to add something to the interface, and the two should not be used together.
By shadow volume basics I mean generate shadow volumes and use a stencil buffer multi-pass algorithm to render them. But, do not be concerned with the case of the viewer being inside a shadow volume. This means strange things will happen when the viewer is inside a volume, but that's OK.
The infrastructure is largely in place to so this. The planes and table should cast shadows, and if you do things properly they will cast shadows on each other and even self shadow. Do not be concerned with some aliasing artifacts that appear under certain circumstances (when the light source lies in the plane of a polygon, for instance).
In one rendering mode you are to render the shadow volumes themselves, and not the shadows. Mostly that's for your own debugging benefit, and our grading benefit.
Hint: The skeleton is set up to use the algorithm where you render the fully lit scene first, then render it with ambient lighting only in the second rendering pass. This is opposite to the way I taught it in class.
For an extra few points, deal with the situation when the viewer is inside a shadow volume. Some very helpful code, that detects ray-polygon intersections, is provided to help with this. You do, of course, have to figure out which ray and which polygons to intersect.
Clearly you can only do this if you have done shadow volume basics.
Partial credit will be awarded for partially functional solutions.
I will be willing to do extensive help sessions during my office hours if people show up and want to know how to do something. I just implemented this, to find out how hard it is, so I know how to do it all.
Again, work in your group directory however you see fit. Grading is again by demo with a little code inspection too, just to see how you're doing it. We'll use the same sign-up, in-person grading as before, but probably with different time slots.
You may submit your project late, with a penalty of 5% of your score per day or part thereof that you are late.