CS 424: Computer Graphics, Fall 2021
Lab 6: Starting the Midterm Project
This week's Thursday lab period will give you a chance to start planning and working on the midterm programming project. The project is a larger and longer-term project than the sort of short exercises that we usually do in lab.
No work will be collected or graded for Lab 6. The completed midterm project will be due on Thursday, October 28 and will count for 10% of your final grade for the course. Lab 9 On October 21 will also be used for working on the midterm project.
The Midterm Project
The midterm project is the one part of the course where you are required to work in a group. You will work in a group of two or three people. We will work out the membership of the groups before the lab.
The project has two parts. The first part is is to design and implement a scene graph API for OpenGL 1.1. Your group will work together on this part, and everyone in the group will get the same grade for it. This group grade will be the larger part of the grade (maybe 7 points out of 10). The second part of the project is to write example programs that use the API. Each person in the group is responsible for writing one program and will get a separate grade for that program. What the programs do is up to you, but, together, they should demonstrate all of the capabilities of the API. Ideally, a program should do something that is interesting on its own (like a hierarchical animation).
Presumably, you will be working in JavaScript and will implement the API as a collection of JavaScript classes in one or more .js files. The programs that use the API will be .html files, which will use <script> elements to load the .js files. They will also load my glsim.js, and you are welcome to use my basic-object-models-IFS.js and polyhedra.js if they are needed by your API. Note that you can als0 use my camera API, which is part of glsim.js.
Your scene graph library will let programmers create 3D scenes by constructing a data structure that represents the content of the scene. Your API will define the classes that are used to create the data structure. The API might also include functions for rendering the scene from the point of view of a camera and for setting up lighting.
You can spend the Lab 6 period working on the overall design of the API, deciding how you will coordinate with your group, and maybe getting started on the programming. Note that you can take some ideas from my simple 2D scene graph API, scene_graph_2d.js, that you used in Lab 3. However, you will not be able to simply convert it to 3D.
You will be working in JavaScript and will be writing JavaScript classes. Keep in mind some of the major differences with Java classes: There is only one constructor for the class, and it is named constructor. Instance variables are created by assigning values to them, usually in the constructor. Any reference to instance variables or instance method must use the special variable this. There are no access modifiers like public or private. The declaration of a method begins simply with the name of the method and a list of paramters. For examples, see scene_graph_2d.js.
One requirement for your API is that is must support having a camera as a node in the scene graph. (See Subsection 4.4.2.) To make that work, a scene graph will have to be a tree, and you will need parent pointers in the nodes. Note that setting the value of a parent pointer should be part of adding an object as a child of another object. Because the scene graph is a tree, you won't simply be able to link multiple copies of an object into the graph, so I would also suggest having a copy() or clone() method, to make it easy to add multiple copies of an object to a scene graph. When copying a node that has child nodes, you need to make copies of the child nodes as well; this is done simply by recursively calling the copy method in each child node.
Note that I do not require you to implement moving lights (Subsection 4.4.3) because the limited number of lights available in glsim makes it difficult to do so.
Another requirement, of course, is that you fully document your APi with comments in the source code. More generally, you should follow all the rules of good programming style.
Design Issues
You will need to make some design decisions as you build your API. Here are some of the things that you should think about:
- Basic Objects. What basic objects will the API support and how? You will probably want to have things like cubes, spheres, and cylinders. Will you have a different JavaScript object for each basic object? Or maybe one BasicObject class, with an instance variable to say which particular basic object it represents? Or maybe just a class to represent IFS-like models like those provided by basic-object-models-IFS.js? Will there be polyhedral objects? Objects made of lines or points instead of triangles? For objects like spheres and cylinders, will you will rely on transformations to set the size and shape, or will you provide constructors with parameters to set some properties of the objects?
- Other objects. How easy will it be for a programmer to construct other objects, if they want something that is not available as a basic shape?
- Representing Transformations. Will you use separate nodes to represent modeling transforms, as was done in my 2D API? Or will you allow every kind of node to have transform properties, as is done in three.js? (In three.js, the base class, Object3D, has both transform properties and a list of child nodes, so every node has those. Subclasses add geometry and material.) Will you have one or more classes to represent transforms, or will the data for transforms be stored as simple properties of scene graph nodes? Will you allow rotations about arbitrary axes, or just the x-, y-, and z-axes?
- Materials. You should probably rely on GL_COLOR_MATERIAL and let glColor* set the ambient and diffuse colors. But you will have to decide whether to also allow specular color, which would have to be set using glMaterialfv().
- Textures. Will you support image textures, and how?
- Global properties. Some properties of the drawing won't be in the scene graph (unless maybe you make a special kind of root node or a separate Scene class to hold them, or maybe make them properties of a camera). This includes, for example, lights, background color, and ambient light. Will you provide any support for these aspects of a scene, or will you just provide a scene graph and leave the rest up to the programs that use the API?
Note that you should not try to do everything! You are not expected to include all possible features in your API. Developing a full-featured graphics API is a major project, and this is just a small midterm project that counts for only 10% of the course grade. You will want to get something working and then add features as you have time.