The Midterm Project

You are encouraged, but not required, to work with a partner on the midterm project. Ideally, you should find a partner before coming to the lab on Thursday.

The project is to design and implement a scene graph API for OpenGL 1.1. 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. In addition to the library, you should write several example programs that demonstrate its capabilities. Deciding exactly what capabilities to include is part of the project.

You can spend the period today thinking about the overall design of the API, deciding how you will coordinate with your partner (if you have one), and maybe getting started on the programming. To start, the scene graph will be mostly geometry, that is basic geometric objects and transformations. As we work through the next month of the course, we will encounter more things that might be added to the scene graph, including cameras, lights, materials, and textures. You can use the 2D API from Lab 3 as a starting point for ideas, but that was a simple 2D API, and you will not want to use exactly the same structure.

You will probably want to work in Java. If you know C++, you can consider using that. It would be difficult to do the project in C, unless you know C very well. A scene graph is a linked, hierarchical data structure containing nodes of several different kinds. In Java and C++, you can define classes to represent the different kinds of scene graph node. It is more difficult in C, where you would need to do rather technical work with pointers, structs, and memory allocation. (Still, if you are interested in knowing how it would be done in C, come in and discuss it with me.)

Assuming that you are working in Java, I suggest that you create a package to hold the classes that define the scene graph. Each class or interface should be in its own file. You should include appropriate Javadoc-style comments in the code, and you should use the Javadoc tool to create the API documentation for the project. (You can generate the Javadoc in Eclipse.)

If you do decide to work in a different programming language, we will have to discuss what would be the best structure for the code.

Design Issues

You will need to make many design decisions as you build your API. We will be discussing many of the issues in class as we work through Chapters 3 and 4. Here are some of the things that you should think about:

• Tree or Dag? A fundamental decision is whether your scene graph will have the structure of a tree. In a tree, a node can have only one parent; in a general dag, a node can have several parents. There are real advantages to using a tree—especially if you are going to allow cameras as nodes in the structure. However, if you do use trees, it's a good idea to have a "clone" or "copy" method in your nodes that will recursively create a copy of the node and its children. A clone operation will allow you to easily add several copies of a compound object to the scene. Also, for a tree-structured scene graph, it is common to include a parent pointer in each node, which points to the parent of that node in the scene graph.
• Basic Objects. What basic objects will the API support and how? You will want to at least have things like cubes, spheres, and cylinders. (If you like, you can use my TexturedShapes class to actually draw the shapes; they are similar to GLUT shapes, except that, unlike GLUT shapes, they support texturing.) Will you have a different class for each type of basic object? Or maybe one BasicObject class, with an instance variable to say which particular basic object it represents? Will there be polyhedral objects? Objects made of lines or points instead of triangles?
• 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? How about support for some kind of indexed face set?
• Representing Transforms. Will you use separate nodes to represent modeling transforms, as was done in my 2D API? Or will you allow transforms to be associated with any kind of node? (You could do that, for example, by putting the support for transforms in the abstract base class for all node types.) Will you have classes to represent transforms, or will the data for transforms be stored as simple properties of scene graph nodes?
• Cameras. Will you have nodes to represent cameras? A camera object usualy represents a viewing transformation along with a projection. (A basic camera class for OpenGL is defined in Camera.java.) Putting a camera into the scene graph would allow it to be transformed like other objects, and even to be part of a compound object so that the point of view can move along with the object (like the viewpoint of the driver of a car). If you have cameras, you need a way to render the scene from the point of view of a given camera.
• Materials. How will material properties be represented? Will every object have material properties (as was done for color in my 2D API)? Will material properties be inherited by child nodes, or will they only apply to a single node? What are the default material properties?
• Textures. Will you support image textures? How will you get the images into your system?
• Lights as nodes. Will there be nodes to represent lights? As with cameras, that would allow a light to be placed in the scene and subject to transformations, even as part of a compound objects.
• Global properties. Some properties of the drawing won't be in the scene graph (unless maybe you make a special kind of root node to hold them, or maybe make them properties of a camera). This includes, for example, background color, ambient light, and lights that are independent of the view. 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 programmer?

Note that you should not try to do everything. You are not expected to include all possible features in your API. If your design is flexible, you should be able to start with a basic set of features and add more later, according to your available time and interest.