Practicum

Schedule

The schedule is subject to change.

12

date		topic	reading	reference
03	Sep	Subdivision overview	SIGGRAPH 2000 course A definitive reference, though a bit advanced to use as a tutorial	slides | notes
10	Sep	Subdivision curves		slides | notes
17	Sep	Subdivision curves	SIGGRAPH course Sec. 2.4	slides | notes
24	Sep	Blender assignment		assignment
1	Oct	[no class—4620 midterm]		slides | notes
8	Oct	Subdivision Modeler assignment		assignment
15	Oct	Design discussion		ms0 details
22	Oct	Design meetings		slides | notes
29	Oct	Milestone 1 discussion		slides | notes
5	Nov	Milestone 1 meetings		slides | notes
12	Nov	Milestone 2 discussion		slides | notes
19	Nov	Milestone 2 meetings		slides | notes
26	Nov	Thanksgiving		slides | notes
3	Dec			slides | notes
	Dec	Final presentations		slides | notes

Milestone 0: Design document

15 Oct

Today we discussed the design document due next week for the subdivision modeler. This 4–5 page document should cover the following aspects of your plans for your project:

1. Which extensions and refinements you are planning (be very specific).
2. The software architecture you will use to implement the basic requirements. This includes the main classes in your program and your plans for implementing each of the requirements within that structure. Particular features to plan carefully for: undo; animation; animated drawing; rendering to movies.
3. The data structures you'll use to support the more involved parts of the project, in particular efficient editing of subdivision surfaces.
4. Your plans for the user interface. How will you handle selection and manipulation of vertices, edges, and faces? How will animation work? How will the UIs of your extensions work? Provide mocked-up screenshots, sketches, or other images to show what the UI will be like.

Subdivision Modeler assignment

8 Oct

Basic requirements:

1. Application mechanics
   • Full save/load support for entire scene state
   • Import of OBJ meshes
   • Many-level undo for all operations that affect the scene in any way.
2. Edit triangle mesh geometry.
   • Allow selection of sets of vertices, edges, and faces
   • Interactive editing of vertex positions
   • Recommended: Allow for storing extra named attributes with vertices, edges, or faces. This can increase modularity by avoiding the need for the mesh code to be aware of all possible attributes that might need to be stored.
3. Loop subdivision surfaces.
   • Interactive editing of control vertex positions positions with continuous view of effects on limit surface.
   • Sharp edges
   • Approximation of limit surface, including pushing vertices to limit surface and computing limit normals for rendering.
4. Animation
   • Interactive specification of transformations at key frames over time.
   • Smooth interpolation of transformation parameters (will not work well for some rotations).
   • Rendering from separate, animated camera
   • Support for rendering a movie to MOV, AVI, or other format.

Sample refinements:

1. Export limit surface in Ray format or other useful formats.
2. Other subdivision rules (e.g. Butterfly).
3. Soft selections for mesh editing.
4. Animation using linear blend surfaces (morph targets).
5. Variable sharpness edges.
6. Rendering extensions: bump mapping, reflection mapping.
7. Quaternion interpolation of rotations.

Sample extensions:

1. Multiresolution editing with edits at finer levels defined in terms of tangent frames from coarser levels.
2. Animated deformers to be applied to the output mesh.
3. Mesh editing: add vertices, split faces, swap edges, etc.
4. Adaptive meshing for approximation to limit surface.
5. Texture coordinate editor that allows vertices to be laid out in 2D, then generates texture coordinates by subdivision.
6. Displacement mapping, producing nice adaptively tessellated surfaces for rendering.

You are required to implement the basic requirements plus:

• Group of 3: one extension + 1 refinement
• Group of 4: one extension + 3 refinements
• Group of 5: two extensions + 2 refinements

Refinements and extensions can be from these lists or they can be your own inventions of similar scope. For the final hand-in you will demo your modeler to the whole class, and also hand in a short rendered animation produced using your system.

Checkpoints:

0. design document including data structures, class structure, and UI design.
1. basic mesh editing working (including undo), and basic subdivision working.
2. all basic requirements satisfied.
3. final presentation including extensions and refinements.

Grading is 15% each for 0, 1, 2, then 55% for 3. For each milestone we will have an individual meeting with each group, to be scheduled via CMS.

FAQ:

• How exactly should the limit surface work?

  There are many ways to do this, and here is one: Draw the control mesh over the limit surface approximation mesh, either transparently or just as a wireframe. The approximation mesh's vertices should be pushed into their correct positions on the limit surface (not just moved according to subdivision rules - see pp. 69-72 of the SIGGRAPH course notes). Also, you should allow the user to specify the number of subdivision levels to use for the approximation mesh. More levels leads to a smoother approximation of the limit surface, but slower rendering. In any case, if the user edits the control mesh, the approximation mesh's vertices should be updated efficiently and correctly to approximate the updated limit surface.

• How should sharp edges be drawn for the limit surface?

  Sharp edges should be sharp, meaning the normals should not be smoothly interpolated at their vertices.

• What actions need to undo-able?

  In short, all of them! All transformations, mesh edits, animation changes, and anything else that affects what is saved to the scene file should be undo-able. Actions that do not affect the scene file, such as changing selection modes (assuming you even use face, vertex, and edge selection modes), may be omitted. However, if you have a well-designed undo-system, you may find that undoing such actions is pretty simple and useful.

• What is the 'named attributes' suggestion about?

  So this was really more of an architectural recommendation. If you have some system where you can generalize vertex attributes (position, color, UV, whatever), then certain tasks such as serialization will be a lot easier. For example, if you're serializing a vertex, instead of having to write:

  v.writePos();
  v.writeColor();
  v.writeTexCoord();
  ad infinitum...
  

  You can just write:

  for( VertexAttribute attr : v.getAttribs() ) {
  	attr.write();
  }
  

  Something like that. It should make life easier.

Blender assignment

24 Sept—due 1 Oct

The first one-week assignment is to get you working in groups, and to familiarize you with the workings of at least one modeling tool. We'll use Blender, an open-source modeling package that is installed under /usr/local/cs465 in the Rhodes 455 lab (or can be downloaded from blender.org).

The first part of the assignment is to organize into groups of 4, plus or minus 1.

The second part of the assignment is to open up Blender and fiddle with it for a while. Browse the user manual, follow along with some tutorials. Play with the subdivision tools. Think about how the designers solved the problems inherent in providing the user an interface to complicated structures like meshes, motion over time, and large collections of buttons and controls. Do you like their solutions?

The third part of the assignment is to create a model with a hierarchy of transformations. It could be whatever you want—a stick-figure person might be a canonical example—and it does not need to be fancy; simple boxes or blobs for the parts are fine. It just needs to have parts (e.g. the legs) that can be moved independently by adjusting the transformations, and some of them need to contain other subparts (e.g. legs containing lower legs).

Hand in the resulting .blend file on CMS. Don't forget to form groups in CMS so that we know who's working together!