Portfolio 4: Make Your Own Workbook
Portfolio 4 is a “final project” designed to allow you to pick a topic and explore it deeply. It is meant to be flexible in terms of topic and style. However, because of the tight time frame, we need to limit the ambitions and scope.
Here are the project dates (in bold), as well as dates for other “class events”
- Monday, April 14 - P3 due
- Tuesday, April 15 - P2/P3 celebration in class
- Thursday, April 17 - Proposal draft including the pre-meeting Portfolio 4 Initial Idea (due Thu, Apr 17)
Friday, April 18 - Proposal “approvals”- Thursday, April 24 - Progress report Portfolio 4 Progress Report (due Thu, Apr 24)
- Tuesday, April 29 - In class “show and tell”
- Friday, May 2 - Project Due date
- Sunday, May 4 - Final Exam
- Wednesday, May 7 - noon - “drop dead deadline” (I need to get grades in!)
These dates are explained below (under milestones).
Some Ground Rules / Questions
Topics: You may pick any topic from the list below, and adapt it (subject to approval). The list of topics is kept slightly narrow to keep the focus on things I think can make realistic projects given the time frame.
Collaboration: You may (are encouraged to) work with a partner. You must specify that you are working together as part of the proposal. If you commit to working as a team, both teammates will get the same grade, and you cannot split your team after the proposal phase. The expectations for pair projects is slightly higher than for individual projects, but not 2x (part of the learning is the experience of working in a team). Each person will be expected to provide an explanation of how the work was done.
Common Topics: Different people/teams may choose the same topic. In fact this is encouraged (having multiple people do similar projects is a good thing).
Project Types
Three project types:
- DB: Demonstrate the Basics: Explain the basics of a topic we didn’t cover in a workbook. Should include “interactive diagrams” to illustrate the key ideas. If it’s something that THREE does, you should show both how to use THREE as well as what is going on under the hood. If it isn’t in THREE (or you think it is more instructive to make your own implementation), that’s OK.
- the focus is good demonstrations of the concept that illustrate it
- II: Implementation in Infrastructure: Work through an implementation challenge using “the course infrastructure” (which includes three) and document in a way that will allow future students to use what you did.
- the focus is an implementation that works in the infrastructure
- IC: Implement the Concept: Implement a basic version of something and explain it. This is similar to #1, but more of a focus on a good “toy demo” where you implement the basic method (with explanations). The focus here is on your own implementation of a basic method, even though it’s probably not something you would implement yourself in practice. We don’t expect a practical implementation - the target is an “expository implementation”.
- the focus here is the implemenation of the concept (a basic implementation), with enough demonstration to show what the implementation can do
The project types are important for scoping (choosing what is important to do), and evaluation.
Some topics might be work for multiple type - so picking and being clear is important.
For example, for “physically-based local lighting models”, it could be any of the three types:
- EB - show how to use the THREE built in models, with demonstrations of the effects that show the differences.
- II - show how to write shaders that build on THREE’s built in models (for example, to write a procedural shader that uses THREE’s lighting)
- IC - implement a physically-based shading model yourself (and demonstrate how each aspect contibutes to the appearance)
Project Ideas
These are roughly organized by the “most logical project type”. The list is based on the “most upvoted” general ideas, with me trying to think what might actually be breakable into a small enough piece to be meaningful in the short time we have.
DB: Demonstrate Basics: most of these are implemented in THREE (or a basic implementation isn’t hard), so you can focus on demonstrating it well in a manner that helps understand the concept.
- sweeps, lofting, generalized cylinders (not sure if this is in THREE) - and maybe simpler versions (three at least has lathe) - this might be more in the 3: Implement Concepts category.
- B-Splines (might be all in 2D)
- Subdivision surfaces / smoothing
- Parallax mapping
- Physically-based shading (the math behind what three does)
- Programming in “raw” webgl - to teach people about the low level library (and why we don’t want to use it in class)
- Point Sprites and imposters (easy to do in THREE, but giving examples of the hows and whys, and good examples that show what it can be useful for)
- Skinning - a good interactive diagram of the 2 joint case, showing off the problems/solutions of the basic methods, how things show up in THREE, etc. Less about the authoring issues (use simple shapes where the weights are easy), but show how changing the weights changes the appearance.
- Noise functions - illustrating the concepts with an interactive demo (frequency mixing etc) combined with explanations of the intuitions for using it and how they work. You might make your own implementation - or take a standard one. The implementation does not need to be in a shader.
Implementation in Infrastructure: Most of these involve building something into THREE and/or the course framework. They are less hard conceptually, and more challenging in terms of building software within the existing systems
- Camera controls
- Procedural shader that uses three’s lighting (preferably by using three’s fragment architecture so we can build off of their implementation of lighting)
- Reading motion capture (BVH) files and showing them on simple “skeletons”
- Scene level anti-aliasing (not even sure how to do this - render off screen (to texture) and downsample?)
Implement Concept: For these, it should be possible to build your own basic version to show off the ideas.
- physical simulation (make a mass/spring simulator, show what can and can’t be done with it, experiments to show why simple methods don’t go very far)
- subdivision surfaces (see what parts are easy/hard to implement - gets at fancy mesh data structures)
- deferred shading - it should be possible to create a “toy” version, but maybe not within three
- deformation-based modeling (like cages (harmonic coordinates) or free-form deformations)
- Rasterization and anti-aliasing (especially for partial fill at edges/lines) (some animated diagrams showing individual pixel decisions)
Too hard to break into a small piece:
- font rendering - this would show off the concept of hinting, and the special tricks used to both define shapes and deal with anti-aliasing
Milestones
Participating in the milestones along the way is required. We will consider failure to meet a milestone when we do the evaluation of the final project.
Milestone 1: Project Proposal
Key to making this project work is for you to commit to a topic, and for us (student and Professor) to agree on a set of expectations. The better we can spell out (1) the technical topic and plan; (2) the expected deliverables; and (3) the evaluation criteria, the more smoothly the project will go. The trick is to define a plan that can actually be accomplished in the 2ish weeks you have to do the project.
The idea is that I (Professor) will meet with each person/team, we will work out a plan, and then you will write down this plan, and we will iterate until I approve it.
We will have the proposal discussion meetings on Thursday, April 17th (instead of class).
- I encourage you to come to office hours, or communicate with me before hand to talk about ideas.
- You must have an initial project idea before we meet. Describe your project idea on the form: Portfolio 4 Initial Idea (due Thu, Apr 17). Consider 3 questions: (1) what is the topic; (2) what do expect the “deliverable” to look like; and (3) how will you evaluate it. If you don’t have a project idea, I will give you one.
- Sign up for a 10 minute slot on this spreadsheet. We’ll discuss your idea, and refine it into a proposal.
After we meet, I will ask you to write a more detailed plan (details to be provided later). The idea is we can iterate to make things well specified.
Milestone 2: Progress Report
With a short time frame, it will be important that you start quickly, and get some initial work done to see if any problems come up. There is a form at: Portfolio 4 Progress Report (due Thu, Apr 24)
A few sentences should be sufficient.
If you are having problems and won’t meet you goals, make an appointment to talk to the Professor or TA.
Milestone 3: In-Class Demonstrations
We will have people show off their projects in class on April 29th. (I want to save the last day of class for exam review).
You must have something to show. We might not get to everyone, but if we don’t show your project, we will ask you to provide pictures and a description after class.
While this won’t be formally graded, we will take notes that will effect our final evaluation.
Milestone 4: Final Project Handin
The project is due the last day of classes. (this is a day after the last class). Friday. May 2.
You will turn your project in by (1) pushing to the GitHub classroom repo we created for you and (2) filling out the self evaluation form on Canvas.
If you turn your project in on time, we will provide you with feedback and allow you to respond to the feedback (turn in an improved version). Note: the idea is that we will let you make “small” fixes, not major changes.
It is better to turn something in on time (and make fixes) than to turn in something better but late. If you know that you want to make fixes, describe them in the self-evaluation form (there will be an explicit question for that).
Milestone 5: Absolute Final Deadline
We need to have final grades turned in before graduation, so people who are graduating can know their grades. This means that we really need the final versions of everything by Wednesday, May 7 before noon.