Programming assignment 4 - Scene Graph Manager

In this assignment, you'll refine your Assignment 3 project to make it a full blown scene graph manager. Your new system will continue to read input files in .obj format, and now it will allow you to build scene graphs using them, and render the results. You'll continue to use the camera control from the previous assignment, but you will do this using transformation within the scene graph. Your scene graph will also support simple animations.

Rendering

You will need to render the scene graph in every frame in your display callback. This will entail a depth first traversal of the graph as we've described in class, managing a transform stack. You should still be able to use the rendering modes from your previous assignment, but you should be able to change the rendering mode on an object by object basis as well as globally.

These are the rendering modes from the previous assignment.

• Point mode: Just draw the vertices.
• Wireframe mode: Draw the edges of the mesh.
• Solid mode: Draw filled triangles.
• Shaded mode: Basic lighting, see below.
• Face normals: Add a toggle to display the face normals.
• Vertex normals: Add a toggle for the vertex normals as well.

Hierachical modeling and motion control

You should implement all camera and object motions as well as placement of lights using a scene graph. All drawing should be done by a generic traversal of the graph to draw it. Changes to what is drawn are accomplished by changes to the scene graph. You should have several types of scene graph nodes:

• Object nodes: These are nodes that represent a coordinate frame in your graph. If you want to build a world that consists of two object, for example, you can make a world object node, link object nodes for each of the two objects, and each of these in turn will link to geometry nodes for the geometry in its object.
• Geometry nodes: This is a container for the object descriptions parsed from the .obj files. You must always have an object node defined to link to a geometry node, i.e. geometry nodes are just ways to put actual geometry into an object node. These will always be leaves in your overall scene graph.
• Transformation nodes: These nodes define transformations between object nodes. Transformation nodes can link to/from both object nodes and other transformation nodes.
• Attribute nodes: These nodes define other attributes of object instances such as rendering mode that apply to entire object instances and not individual pieces of geometry (such as a vertex normal).
• Light nodes: These nodes can be linked into the scene graph via transformation nodes just like object nodes, but they won't serve as parent nodes to other nodes in the graph. A light node represents an OpenGL point or directional light and can be positioned using transform nodes.
• Camera nodes: These nodes contain parameters for the OpenGL projection matrix for a camera in an eye space local to the camera node. It also contains parameters for the viewport on the screen that the camera's view should appear on. Like light nodes, these are positioned and linked into the graph using transformation nodes, and no children are linked to them. For simplicity, we will not require that your project work with multiple cameras at once, although you are free to implement that capability.
• Motions: To implement motions in your scene graph, you'll want to update selected transformation nodes every frame. You should be able to specify interactively a rotation amount per frame and a translation amount per frame. You may restrict things so that at most one of these can be specified for a particular transformation node if you like. This will make the ordering of operations totally controllable using the scene graph structure.

User Interface

Note: If you are having problems with crashes using glui on the lab machines, try building your code with this makefile. It does appear we are having problems with g++ on the lab machines again.

In order to alleviate the limitations of the glut GUI, we will be using the GLUI widget package. This is a simple gui package that allows many input capabilities that are not possible with glut and that will allow us to replace the text based inputs from the previous assignment with input from an appropiate widget. The glui package and example programs are available here. To build, untar the file, then go to the src directory, and type "make". They should build as distributed on the lab linux machines. The library will be put in the lib subdirectory, and the example program executables will be in the bin subdirectory. We are working to get a standard installation of this library on the lab machines, but in the meantime you can build and link to your own copies.

You should implement interactive commands to accomplish the addition of nodes of the types described above to a scene graph. You should be able to create and delete object, geometry, transformation, attribute, and light nodes and to set and change their key parameters interactively with a mouse and keyboard. All nodes should have identifiers that you can use to modify or delete them once created. Note that deletion of nodes should only be allowed where it makes sense, deleting a node from the middle of a graph may not be allowed if it isn't clear what the resulting graph would be. You should also use widgets to allow interactive controls for motions and other requirements described above.

There are a number of ways widgets can be used to implement interactive control. Selections from menus, subwindows for text entry and many other options will be available, as demonstrated in the glui example programs. You are free to choose a user interface style that you like as long as you provide the required capabilities.

Extra credit

• Material files: One of the optional parameters in an .obj file is a material file, which contains color and lighting information for the materials used in the mesh. You could read out that information and feed it to OpenGL's lighting system to see the object as designed.
• Other camera controls: Orbit cameras are great for looking at an object, but you are probably familiar with various other first and third person camera control systems from games. Feel free to try some of these.
• Camera inertia: Some users find it more natural if the camera keeps rotating around an object after they've released the mouse, as if they had spun a globe. If you implement such functionality, make sure to slow down the rotation gradually over time, so the object eventually stops spinning.

Notes:

• You should use your project 3 code as your starter code.
• As usual, you'll turn this in using Canvas. Also as usual, you can develop your application on whatever operating system you like, but before you submit it, you must make sure that it builds and runs properly on the department Linux machines! All grading will take place on these machines, so if your code doesn't work on them, you're in trouble.

  Other caveats about turning the project in are the same as the previous project. To repeat:

  Make sure that all the necessary code is submitted, as projects that don't build are worth nothing! Make sure you have included your name and UTCS ID in a comment at the top of each of your files. Also, include a readme explaining the usage of your program, including any menu options or keyboard commands. If you use any slip days, be sure to put that in your readme and email the TA as well. To get a grade on this project, you'll need to sign up for demo session with the TA after you've submitted your code. This is when you'll run through all the functionality in your project, and the TA will be able to verify that everything is working as it should. This is also your chance to show off your extra features and slick interface!