CS 348C Project Proposal

CS 348C - Modeling in Computer Graphics
Fall quarter, 1995
Coordinator: Apostolos Lerios

The project proposal is a 1-2 page document that describes the intended area of a student project, summarizes relevant published work, and suggests possibilities for the concrete goal of the project.


Intended area
Students must select an area related to geometric modeling and/or modeling of natural phenomena and processes. Different teams may work on the same area; however, the concrete goals of their projects have to be different. The topics list contains several suggestions on possible areas that a project may investigate. Also, the staff of Pacific Data Images has made the following suggestions: Although by no means they are required to do so, most students pick a topic related to the papers they researched for their in-class presentations.
Relevant work
Students must reference published work which relates to the concrete goal of their project. References outside the intended area, but relevant to the concrete goal, are highly desirable. In addition to merely listing bibliographical references, students must append a short (up to 10 lines) content summary to each referenced item.
Concrete goal
Students must propose a concrete focus of study within the intended area. For example, the students may opt to The students are encouraged to read carefully the "future work" sections of relevant published work for ideas. Also, it's a good idea to contact the authors of relevant papers and ask them if they have any particular projects to suggest.

Outline of sample proposal

[ Editorial remarks appear in square brackets. ]

[ This is just an outline. A full-length proposal should have a similar structure, but the students should elaborate more on their ideas. ]

Intended area
We would like investigate the modeling of plants.
Relevant work
[ Four sample references are shown; a full-length proposal should reflect a more extensive literature search. ]
Concrete goal
[ A full-length proposal should be more detailed than this rough sketch. Also, several alternative goals may be presented. ] We plan to implement a dL-system parser, which will improve upon the work of Prusinkiewicz in three areas:
  1. We would like to design a friendly user interface to dL-systems. That is, we would like to design an easy-to-learn-and-use specification language for entering the modules of the dL-system; these include productions, differential equation, their domains, and their boundaries.
  2. We would like our dL-system parser to be efficient and stable. That is, it should be able to robustly generate plants at interactive speeds so that the animator can comfortably experiment with the dL-system parameters. This way, (s)he may gain intuition on the effect individual system parameters have on the generated plants and thus quickly design desired plants.
  3. We would also like to extend dL-systems by allowing the user to specify continuous growth by arbitrary procedures, rather than mere differential equations. Such an extension raises several issues including the following: what is the proper user interface to such procedures (maybe PERL scripts)? How can the parser reliably predict when and if modules get (de-)activated?


The project proposal is not unlike a Ph.D. thesis proposal. Here are the requirements of the latter, as set forth by the computer science department and paraphrased for CS 348C:
On the one hand, this proposal is a contract. It commits the students to begin work in the proposed area and it binds the coordinator to advise the students in that area. On the other hand, it is just a proposal. There is no requirement that the students continue working in the proposed area. In fact, few students end up doing exactly what they initially propose. The students, with the approval of the coordinator, can change the area, goal, and scope of the project at any time.

Last update: 13 December 1995 by Apostolos "Toli" Lerios