For this final assignment, you will add one or more features to something you built previously in the class. The main idea is to build on the concepts we've learned in class, but you have a lot of flexibility in your choice of what to do. I have some suggestions and guidelines below, but you can also choose to do something else, as long as you get approval from me by 5pm on Wednesday, 2/24.
You may work in a pair on this assignment. If you do, only one person should submit the group's work, and you will both receive the same grade (unless I have some good reason to do otherwise). I will expect pairs to accomplish something twice as sophisticated as I would expect one person to do on their own.
During our class's final period, you will present a demo of your project to the rest of the class. Plan to show us your rendered output or an interactive demonstration of the behavior of your program, as well as a brief guided tour through your code, explaining how the most important new features work.
Your submission will be evaluated based on the following factors, in descending order by importance:
The first factor above is most important. A program that runs correctly and error-free will generally earn a better grade than an incredibly ambitious program that crashes and is only partially completed. Of course, given two programs side-by-side that run perfectly and are equally well-designed, the one that accomplishes more (as a result of more original work by the author) will receive the better grade.
So what's this deal about originality? You will be evaluated only on the new code that you write, and the resulting behavior due to that code. Your project may recycle old code from class, from your homework submissions, or even from the book or the book's example code. But any code you recycle will be disregarded in the evaluation of the sophistication of your work. So small changes to code that you've submitted before, or that I wrote, or that came from another source, will not count for a lot.
If you do something that the book already provides example code for — for example, rendering fractals with WebGL — you'll need to make a significant improvement on it to get full credit.
Keep in mind that you must cite the sources of all ideas and code that you get from somewhere else; you should do this both in comments in your code and also in your writeup.
Your submission will consist of three sets of files, submitted on Canvas:
As always, everything you hand in must have your name on it (which includes both partners, if you work in a pair).
If you reuse a file from a previous project, even with modifications, please leave it with the same name. If you use helper code that I gave you (like gfx_helper_plotting.py), please do not modify the helper code, but do include it in your submission, and leave the filename alone. (The only exception to this is the book's helper code in the Common directory. Just like in HW7, I will run your project in a directory that has Common next to it in the directory hierarchy.)
Test your work before submitting it, by copying all the files that you submit to a new directory, and checking whether your program runs properly there.
Don't worry if Canvas renames your files; there's nothing that any of us can do about it.
Your project will likely be based on one of the three renderers from the course: the software-based projection renderer (HW5), the software-based raytracer (HW6), or the hardware-based / WebGL projection renderer (HW7).
Whatever you do, it should be principled and based on established techniques; in general, the point is not to invent brand new things, but instead to figure out how to implement already-existing ideas.
Your submission must include a writeup that describes and explains your work. Write it in a plain-text file called README.txt, with at most 80 characters per line, no tab characters, and no ugly text wrapping. (URLs may violate the 80-character limit; don't wrap them.)
The writeup must contain the following:
Here's a brief example.
Raytracer with Implicit Surfaces
By Jadrian Miles
For Comp 630 (Computer Graphics) @ Phillips Academy w/ Dr. Miles, period 4
2016-03-01
Demo program runs directly from the command line as "python main.py". Render
takes about 1.5 hours; please see demo.pdf for high-resolution screenshots.
--------------------------------------------------------------------------------
PROJECT CONTENTS
Documentation:
- README.txt : This document.
- screenshots.pdf : Screenshots of the demo program run at high resolution.
Original / modified code:
- main.py : Demo program that loads and renders a scene.
- shapes.py : Classes for implicit-surface shapes.
- raytracer.py : The raytracer.
- test_scene.py : A simple scene for testing.
- scene.py : A sophisticated demo scene.
Recycled starter code:
- camera.py : The Camera class, for specifying camera pose & properties.
- lighting.py : The Light class & subclasses, for types of lights in the scene.
- surface.py : The Surface class, for surface properties of objects.
- transforms.py : 3-D linear transforms.
Unmodified helper code:
- scenegraph.py
- _scenegraph_base.py
- gfx_helper_plotting.py
- gfx_helper_script.py
--------------------------------------------------------------------------------
My raytracer supports Phong lighting (ambient, diffuse, and specular) and
reflections for objects that are defined with implicit surfaces. Because each
object is defined by a continuous function, its surface, and the normals on it,
are smooth and precise. The demo program shows reflections and lighting effects
in a scene with two spheres (one of which is distorted into an ellipsoid), a
torus, and four cubes (three of which are distorted into wide, flat boxes to
form the walls of a room).
The surface properties vary among the objects. The floor is highly specular
but non-reflective, and has different colors for its specular and diffuse
components. The torus is almost a perfect mirror --- notice the self-
reflections on the inner surface.
I'm not going to describe implicit surfaces for real, because this is just an
example writeup. If I did, though, my explanation would cite the source from
which I learned *this* important property of implicit surfaces [1], as well as
any original academic papers that I read [2]. It would also cite the source
from which I learned *this other* necessary implementation idea [3]. And it
would definitely cite the tutorial that I used to figure out how to do all this
stuff in Python [4] with numpy [5].
If I were writing this for credit, it would probably be a good idea for me to
write several more sentences of explanation, so that I convey to my teacher that
I understand this stuff.
--------------------------------------------------------------------------------
References:
[1] E. Angel and D. Shreiner. "Curves and Surfaces". In "Interactive Computer
Graphics: A Top-Down Approach with WebGL", 7th ed, pages 796–805. Pearson,
2015.
[2] H. Jensen, S. Marschner, M. Levoy, et al. "A Practical Model for Subsurface
Light Transport". In "Proc. ACM SIGGRAPH", 2001, pages 511–518.
[3] A. Author. "General Representations of 3-D Implicit Surfaces". Online at
http://www.answers-to-all-your-graphics-homework.org/keep-dreaming.html .
Accessed 2016-02-23.
[4] M. Howard, L. Fine, and C. Howard. "Inheritance in Python OOP". Online at
http://lmgtfy.com/?q=python+inheritance . Accessed 2016-02-24.
[5] "Numpy Already Does That For You". Online at
http://www.haha-you-thought-THAT-would-be-in-the-documentation.biz .
Accessed 2016-02-28.
The citation format that I have in mind doesn't have a single common name, but is broadly comprehensible and closely matches the styles I've seen used in a variety of applied CS journals. (I've made some adaptations for the fact that you can't sensibly italicize plain text.) The format is closely related to AMA format. As long as your style is consistent and doesn't vary grossly from my example, you're fine. Here are some things meant to be conveyed by my example:
This assignment is worth 20 points.
Because the assignment is so open-ended, the grading criteria are relatively vague. Nevertheless, here's a breakdown:
| Criterion | Points |
|---|---|
| Follows the guidelines for filenames, README content, citation style, etc. | 2 |
| Code style is consistent and clean, code is well organized, and comments are used liberally to explain what's going on. No extraneous code executes. | 2 |
| Demo program runs properly. | 1 |
| Demo program exhibits the important properties of your feature. | 1 |
| You participated fully in the demo session during Extended Period Week. | 1 |
| Quality of execution: all features are fully and effectively implemented. | 8 |
| Sophistication: you chose an interesting and challenging feature to work on. | 5 |
| Total | 20 |