CS 791 Project
The goal of the project is to conduct a significant exploration of
a single topic in the field of non-photorealistic computer graphics,
geometry, and ornament.
Most likely, this exploration will take the form of an implementation
of an algorithm or technique. It may be possible to produce a
paper or carry out an experiment as a project in this course, though
these will be held to a higher standard. The project is not required
to contain any new research, though new research is certainly encouraged.
You are welcome to work in pairs for the final project. Pairs will
be expected to do more work than students working alone, but definitely
not twice as much work; maybe more like 1.25-1.5 times as much. Thus
there is some benefit to teaming up.
The proposal (19 March)
The first element of the project is the proposal. The proposal should
outline the scope and goals of the project, and give a clear idea of
what will be done.
There is no fixed page limit for the proposal; it should be exactly
as long as is necessary. If you want to shoot for a target, two or three
pages seems like a reasonable size. Be sure to include images
and a bibliography if necessary. Body fonts
should be between ten and twelve points in size, and text should
be set single-spaced in one column. Use one inch margins all around.
The content of the proposal is not entirely fixed. You should use
whatever organization you feel will best motivate the subject and
communicate your goals. But here are some main points that you
should be sure to cover (adapted from Tim Brecht's
CS856 project
guidelines):
- The problem statement or idea
- What problem is being
studied or addressed?
- Motivation
- Why is this problem interesting? Why is it deep?
Who cares about this problem, and who will benefit from
a solution?
- Goals/Objectives
- What is it you are going to do? How
will you or anyone else be able to tell if you've attained your
goals?
These don't have to follow the format of the objective
list in CS488/688. But you should try to give a concrete
set of properties that your final product will have.
- Approach or techniques used
- How are you going to do this?
What algorithms or techniques will apply? What hardware
and software will you use? How do you plan to evaluate
that your project is performing as expected?
- Milestones
- Short term: things that will definitely get done.
- Medium term: things you'll do if everything goes well.
- Long term: things to do if everything goes very well.
You won't be expected to complete all of these milestones;
you should think about writing a proposal for which you
can meet all the short term ones and some of the medium term
ones. The purpose of this section is more
to show that you've thought through the implications of
this work and have ideas about what directions your project
could take in the future.
You can start working on your project as soon as you've submitted
your proposal, or even before. Only in the most extreme cases
will it be necessary to change to a completely different topic.
It's much more likely that I'll simply offer a few minor adjustments
or pointers to relevant work,
and that the work you've done until that point will still be
applicable.
In-class presentation (30 March – 1 April)
There is no preset format for your presentation. The general
goal is to introduce and motivate the problem area, describe the
scope and aims of your project, show current results, and discuss
future work. Here are some additional collected notes:
- The point of the presentation is not to tell us about the
paper your work is based on (if there is a paper). I want
to know what you did. Yes, you'll need some introductory
material about the topic and the paper, but that's not the
focus.
- You should certainly start with an overview of the topic
and some motivation for why you did a project on it.
Unlike
a similar presentation in other courses, it should be easier
to motivate your work because you can include pretty pictures.
- I won't expect you to have finished your project, but I'd
like to get a clear sense of what you've accomplished and
what you're planning to accomplish in the time remaining.
Show results that you've got, either images, animations, or
live demos (have the images handy in case the demos don't
work).
- Try to include some discussion of what you've learned and
what you would do for future work. While working on the
project, did you identify opportunities for new work in this
area? Do you have a long-term vision for the Ultimate Killer
Demo?
The write-up (21 April)
Your final project submission should be in the form of a paper
write-up. Use the same formatting guidelines that were given for
the proposal, or analogous HTML formatting.
Again, there is no predetermined length for your
paper; it should be exactly long enough to contain everything
you need to say. As a guideline, I'll recommend a 5–10 page paper,
including images. Of course, part of your mark will come from
the quality of your write-up, so try to find a suitable level
of detail.
You should organize your paper in whatever format best communicates
its ideas. Here are some suggestions for main points to discuss:
- Introduce and motivate the topic. Why is this an interesting
problem? Why is it challenging? What are the historical
antecedents (i.e., examples of this medium before
computer graphics)? If you're developing a novel idea,
what was the inspiration?
- If you're working on a novel idea, discuss related work.
If you're implementing an existing paper, you don't need
to simply copy in the paper's related work section, but
you're welcome to incorporate references to related systems
that the paper missed or that have been created since
its publication.
- Describe your implementation.
- If you're implementing
an existing paper, you don't need to rehash the paper's
algorithm, but you should still describe what you did.
In particular, it will be interesting to know what wasn't
obvious from reading the paper. What did you have to
figure out for yourself? What was confusing or incorrect
in the paper?
- If your work is novel, pretend that you're writing a
SIGGRAPH paper. You'll want to describe your implementation
in enough detail to let others reproduce it. In SIGGRAPH
reviews, they used to use the metric "can the work be reproduced
by a skilled graduate student?".
- Show results. Include enough results to demonstrate the
different features of your system and to prove that the
features work. It's also interesting to include examples
where your system performs poorly as a demonstration of its
limitations. If you're results are primarily interactive or
animated, you can still include screenshots or still frames,
but you may also provide videos or demo programs along with
the paper.
- Discuss future work.
- Part of future work is the stuff you
meant to implement but didn't get around to. How would
you need to change your program to get these other features
working?
- Another aspect of future work is new ideas that occured
to you while working on the project. Now that you're finished,
what possible extensions have you identified?
- I'm also very interested in longer-term ideas. Ignore
the project time-frame. What new directions could you take
with the this work if you had a whole term? A year?
Is there a PhD topic lurking in your project?