CS 184: COMPUTER GRAPHICS


CS 184 HOME < - - - - > CURRENT 

The Course Project

CS 184 is now officially a DESIGN-Course!
ABET requirements specify, that such courses:
-- have a  DESIGN-Project  and
-- teach and test  Technical Communication Skills.

DESIGN-Project  must have
-- some clear task or goal,
-- some constraints or specifications,
-- some trade-offs between different possible solutions.
==> Try to think of something that you would like to do,
       and then make up a plausible task specification that has your project as the answer.
       ( This is like Jeopardy where you need to find the Question!  :-)

Here are some basic example ideas, to get your own thinking going:

ARTICULATED, KINEMATIC ASSEMBLIES:
Design an articualted robot or creature (pogo-stick, humanoid, ant, centiped ...) that moves (walks, crawls, hops, rides on a bicycle or unicycle ...) across some surface (plane, B-spline, subdivision surface, fractal landscape ...), and where the locomotion follows a point on that surface controlled by the mouse/cursor. see:
http://www.cs.berkeley.edu/~ug/slide/gallery/kleinbottle/index.shtml
http://www.onemotion.com/flash/spider/
http://www.foddy.net/GIRP.html


Design some articulated creature that climbs some 3D "graph" structure (simple telephone pole, binary tree, 3D lattice, complex 3D graph ...)

Design a wheel-chair that can move up and down some typical stairs.

Design a transformer that converts from some shape A into some shape B that have quite different capabilities.

PRECISE USER INTERACTIONS:
Design some interactive game that forces the user to adjust the 6 DoF of a polyhedral object in R3 to move through a cut-out template in a thin plate.

Design some interactive game where the user is trying to doc two space ships in a precisely defined orientation against each other.

GEOMETRICAL OPTICS + RENDERING:
Model the reflections and refractions in a polyhedral glass container filled (partially) with water
-- in particular the RCO in the Pacioli painting (geometry data is available).
Place it inside a cub-shaped "Cornell-box" with a window to study realistic reflections of that window.

Model a more complicated "framed" object like Leonardo's pseudo-rhombicuboctahedron in a smoke-filled room,
with a single strong light source casting dramatic shadows and dispersive light beams in the smoke.

Model some anamorphism, where a "weird" painting, when seen as a reflection in a highly polished cylinder or sphere,
reveals itself as a "normal" portraint or object.  Construct a suitably distorted "weird" painting.

Model some implausible 3D geometry (e.g. infinite staircase) -- and try to design and render a 3D scene so it looks the same from a specific view center. 
Identify what you need to do to achieve the same visual effects (shadow, global illumination, reflection/refraction?) and aesthetic (non-photo-realistic rendering?)


Model complex lens assembly of a real camera; use refractions and reflections to trace eye rays; create images with lens-flare etc...
see: "A Realistic Camera Model for Computer Graphics” by Craig Kolb, Don Mitchell, and Pat Hanrahan.

ADVANCED RENDERING:
Merge your GPU shader knowledge with your raytracer knowledge, and implement a custom shader for raytracing a specific scene of your own design. 
Identify procedural elements well suited to raytracing on the GPU, such as CSG of simple primitives and fractal geometry. 
Let the user explore and edit the scene in real time.

DECORATED SURFACES:
Design a smooth, highly symmetrical (subdivision) surface of higher genus with some Escher-like tiling pattern on it.

Build an interactive modeling system for smooth surfaces of resolution (vases, columns, lamps...) with different materials and surface decorations.

PROCEDURAL SCENE GENERATION:
Implement a renderer for a "powers of ten" style scene, with details ranging in scale by a hundred orders of magnitude.  Use procedural modeling techniques to ensure the lower levels have interesting, relatively-dense interesting details, so the user can zoom in most places and see something.  Use aggressive culling and optimization to keep rendering time down.


ANIMATION:
Apply Mocap data (http://mocap.cs.cmu.edu/info.php) and hand editing from AS#9 to make a cool short movie clip (with sounds).

Design some two- or multi-legged creature that can do some tricks, such as doing a backwards somersault (need to put some physics into this!).

SIMULATION:
Make an interactive simulation of some simple spring-mass system (e.g., some truss or bridge, or a block of Jello).
Show the responses to forces interactively applied by the user (load on bridge; a spoon hitting jello).
For the jello example, the simulation can be enhanced with some fancy rendering of light passing through the jello.





We will try to fulfill the 
Technical Communication Skills  requirement
by having you give a short (2-4-minute), formal, oral presentation before you demonstrate your projects.
This oral part will count for 20% of your project demo grade.
It is an important skill to be able to present your ideas and accomplishments to your peers and future bosses.
==> We will talk more about this in future lectures.



Schedule:

As#10 = PHASE_1:
Form your teams: 1, 2, or 3 persons; select a tentative design task; write a short proposal
(100-300 words)
Due Friday April 15,
11pm  (worth the first 5% of project grade).
==> Quick feedback before 11pm, April 20, to let you know whether your project has the right scope.


As#11 = PHASE_2:
Every participant must have a link to a (shared) proposal on their web page.
Revise your project proposal; clarify technical challenges.
Show some evidence (a picture)  that serious programming has started.
Here is a possible template for your refined proposal:
-- Descriptive Project Title
-- 1 to 3 sentences what this projects is all about.
-- List the technical challenges (1 to 4) that you will address
-- For each challenge give a 1-2 sentence statement (with a possible reference) how you will approech this challenge.
-- Show a raw, undecorated picture of your main character;
or your race track; or your game-scene;
    or the test scene for your fancy renderer; o
r a control polygon for your high-genus subdivision surface...
==> Only propose things that you already have an idea how you will approach them!

Due Saturday April 23, 11pm  (worth another 10% of project grade).
==> Quick feedback before 11pm, April 27, -- only if we find that you are on a bad trajectory;
       More detailed grading of your As#12, will take about a week.


As#12 = PHASE_3:
Intermediate Progress report:  Show evidence of the basic core of your project working.
(more details will be forthcoming).
Due Monday May 2, 11pm  (worth another 15% of project grade).
Every team must prepare a brief (1 page) progress report [plus some pictures] and post it on their web page.
This report should convincingly demonstrate that you are about half-way done with your programming effort.

Grading guidelines for As#12:

15 points is absolute maximum for this assignment ( = A+).
 
10 points are given if the following points have been answered completely and competently:

For each of the technical challenges listed in As#11, tell us:
-- to what % you think you have solved the problem,
-- one sentence what you have accomplished (and how),
-- one sentence what remains to be done.
 
3 more points are given for reasonable visual documentation of the following:
For as many challenges (p) as there are persons (p) on your team you should be about 66% done by 5/2/2011;
for those p challenges you should add one image or short animation each that demonstrate the claimed achievement.
-- i.e. a vibrating grid for a ??-simulation;
-- or a box sliding around a track for a racing game;
-- or some rays going through some glass body for a fancy ray-tracer;
-- or some GUI to manipulate a paddle for some interactive ball game, etc ...
 
1 or 2 more points are given for exceptionally good documentation of either kind.


As#13 = (final) PHASE_4:

Project Demonstrations: Tuesday and Wednesday, May 10/11, 2011  in  330  Soda Hall

Each group MUST demonstrate their final project.
Sign up for a Project Demo time slot
The sign-up schedule needs to be interpreted with some flexibility:
Please be in the room and have your demo ready to run 10 minutes before the start of your assigned demo slot.
Print out and bring along  your partially filled-in  "p-Person Project Score Sheet":
1-Person Project Score Sheet  --  2-Person Project Score Sheet  --  3-Person Project Score Sheet
as well as a paper copy of your Final Project Report (see below).

First you will give your prepared (and hopefully rehearsed) "Elevator Story" about your project.
Then you will start the actual demo, showing that the various achievements claimed actually work.
This part of the demo will be partially driven by the instructors, who may ask for things like:
"turn off the fancy texture, so we can see better the underlying geometry" or "show the simplest case of a refracted ray."
Of course, you can give a more detailed (prepared) story, but it might be interrupted or redirected by Q&A.


Oral Presentation at the beginning of the Project Demo:

This is a high-level, formal presentation (with no interruptions) in which you
tell us briefly what the project is all about and what your contributions were;
  assume we have no prior knowledge of your work!
Time limit:   1-person team: 2 minutes;  
2-person team: 3 minutes;   3-person team: 4 minutes;
Every team member must speak for at least one minute, telling us about her/his specific contributions.


Final Project Report:

Every team must bring a paper version of their final project report to the session when they demonstrate their project and hand it in (together with their filled out Project Score Sheets). These reports are strictly limited in length. Including all images, they are limited to 2 pages for 1- and 2-person teams, and to 3-pages for 3-person teams.
They must contain:
 == The names, cs184-account numbers, and the e-mails of all the team members.
 == The project title.
 == A brief description of the scope and goals of the project.
 == A discussion of the technical challenges tackled:
Each report should focus on P to P+2 challenges, where P is the number of persons in your team.
For each challenge, describe the technical problem that needed to be solved and the way in which you solved it (or what the key stumbling block was that did not allow you to solve it properly). Include a convincing medium size figure that serves as a reminder of your demonstration during your demo time slot in which you show us your solution. -- A good mix would be to use about 50% of the available page space for text and the other 50% for images.
For multi-person projects, please explain who were the team members primarily focusing on each particular challenge.


Also -- before you come to give your project demo -- place the same Final Project Report electronically as As#13 onto your website
and submit your code on unix at the same time.



CS 184 HOME < - - - - > CURRENT 
Page Editor: Carlo H. Séquin