Project information

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.

I’m quite open as to what constitutes a topic for a project in this course. My teaching has been focused on geometry, symmetry, tilings, and more freeform element arrangements such as mosaics and stippling. But I’m interested in just about any topic in which computer graphics is used to artistic or decorative ends. If you have a favourite NPR paper you’d like to implement, feel free to contact me to discuss it as a possibility.

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 (July 17th)

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 CS 856 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 or outcomes 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. You can minimize your risk by getting the proposal to me early, or by asking me first whether the topic will work for a project.

In-class presentation (July 28th)

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 your 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 (August 25th)

Your final project submission should be in the form of a written report. 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 your 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?

  Don’t skimp on future work. It’s a demonstration that you’ve thought deeply about a topic, and that you can identify new opportunities through the lens of a CS researcher. It’s always possible that your project, or follow-up work identified in your report, could lead to a published paper down the road.