PROJECT1 Topics
Project Requirements
This project must be done individually.
There are three deliverables for each project: topic, design and
code.
Each deliverable should clearly include the date, class, and your
name. The papers will be collected in class or can be delivered
electronically via Blackboard. The code must be
delivered electronically via Blackboard.
- A "Topic" paper, under a page long, describes what you plan to do.
- Describe exactly what you're planning to accomplish. A screenshot
(which can be from a website or paper, as long as it's clearly
referenced) might a good aid. If the method is described
in a book or website, a citation is very appropriate.
- The purpose is mostly for us to negotiate on the scope of the
project, so for your own sake please be clear what you're building.
- The topic paper is worth approximately 10% of your project grade.
- A "Design" paper, about one page long, describes what you plan to do and how you plan to do it.
- Describe any changes from the topic paper.
- Describe the general outlines of the method. Not all the
details have to be laid out explicitly, but you should have a good
understanding of the basic pieces and how they fit together.
- If you plan on doing anything different from the "standard"
technique, please elaborate on your version and why you think this will
be better (or at least how it will be different!).
- Describe all the libraries you think you'll need, including OpenGL and GLUT.
- The design will be graded based on clarity, completeness, and appearence (in that order). The design paper is worth
approximately 30% of your project grade.
- Finally,
"Code", in the form of a working graphics program.
- Code counts as 60% of your project grade. The code will be graded based on:
- Correctness: how much of the delivered functionality actually works (most important).
- Clarity: how easy the code is to read and understand, including documentation (very important).
- Appearance: how smooth, polished, and impressive the visuals are (important).
- Completeness: how much of the promised functionality is actually there (important).
- Formatting: how well the code conforms to these requirements (important).
- A typical program might include a few hundred lines of new code, although the length is not very important.
- All the project source code, input files, and documentation should be in one zip or
tar-gzip (created with "tar czvf <lastname>_cs481_proj1.tgz *")
file.
- A
very short README file is required,
giving at least the author(s), date, version, and purpose of the
program. If you made any changes to your topic or design, the
relevant changes should be listed in the README.
- The README must list the other libraries used, and where to get
any nonstandard (i.e., not in default RedHat install) libraries.
If you expect me to have a hard time building your code, you may
include a Linux or Windows executable in addition to the source
code. If you expect me to have a hard time even running your
code, include screenshots or movies in addition to the source code.
- A LICENSE file specifying the legal rights to your code. I prefer
to release my code to the public domain, but you could use the GPL
license, BSD, or even "Copyright <your name> 2005. All rights
reserved.".
- If your code is derived in any way from any other package, you MUST at least clearly cite that package
in the source code comments and README file. Any project whose
real functionality comes mostly from code you did not write will be
considered cheating and dealt with severely. You are of course
allowed to copy small pieces (e.g., calls to complicated operating
system interface routines) from documentation and examples, although
anything substantial should be cited. Re-using your own code from another class or project is very highly encouraged.
- The preferred form for code documentation is just a set of comments in the library header file (ideally, in doxygen
format).
- When
it's easy, portable cross-platform code is preferred. Any known
platform limitations should be listed clearly in the README.
- If
the program includes a user interface, please indicate how to use it in
the README: what the mouse buttons do, how the keyboard works, and how
to get the program to demonstrate what it's supposed to do.
Possible Project Topics
Choose any one of these topics, or make up your own topic. If these
seem too big, feel free to simplify them in your "topic" paper; if
these seem too simple, feel free to add features. Be aware that the
simpler project will be graded more strictly; while a more ambitious
project will be given some leeway (but of course, it's still got to
work!).
- Implement display-time Constructive Solid Geometry (CSG) on
the
graphics hardware using backface culling and the Z buffer. You
must use CSG
to build and display at least one interesting (possibly hardcoded)
object containing: at least one intersection or subtraction, and at
least one union. This actually isn't as hard as it sounds as long
as the shape is hardcoded. (Google, Goldfeather's Algorithm Paper)
- Grad students: add at least one interesting
twist. For example, you could add the ability to
interactively move intersection cutting planes through the CSG object,
to display CSG objects constructed from nonconvex primitives, or the
ability
to read a CSG object from a file (harder than it sounds!).
- Implement any flavor of quality shadows for a moving (possibly
hardcoded) object. We'll be looking at both shadow maps and
shadow volumes, so those would be good choices. Note that painfully fake shadows (e.g., the really easy shadows that are
only cast onto a flat floor) are not acceptable.
- Grad students: analyze and correct at least one artifact of shadows.
For example, implement any soft shadow algorithm, any method to hide shadow map pixels, or work out how
to handle shadow volumes when the viewer is inside the shadow volume.
- Implement any type of cellular automata (e.g., Conway's Game of Life) on the graphics card using a pixel shader.
- Grad students: support reading the cellular automata ruleset from a file--e.g., using Wolfram numbering. Animate the cellular automata over some interesting shape (e.g., a torus).
- Implement reaction-diffusion textures (of any type) on the graphics card.
- Grad students: use multigrid to compute reaction/diffusion
textures interactively (i.e., at reasonably high resolution at a
reasonable framerate).
- Implement a walkthrough of a city model of reasonable size. Must include at least textured ground, several multistory buildings, and some freestanding foliage.
- Grad students: implement (possibly painfully fake) reflection and shadows.
- Implement any interesting or reasonably useful non-graphics
application on the
graphics card. For example, implement fluid dynamics, wavelet
compression or decompression, Fourier transform, etc. on the graphics
card. Writing a compiler for a simple language would be extremely
impressive.
- Grad
students: tune your application until it is faster on the graphics card
than on the CPU (or faster than 2 gigaflops), even counting upload/download time.