COS 426
Assignment 3: Scene Maker
Assigned 10/16/98
Due 10/29/98 11:59pm
15 points

In this assignment you will write a scene modeler using Inventor. After the last assignment, you are probably really tired of typing in vertex coordinates by hand. With this program you will be able to create, write, read and modify complex scenes using a graphical user interface. Inventor gives you (among many other facilities) easy ways to create, modify, save and restore, and render a hierarchical scene graph. Using your program, you will be able to instantiate primitive objects (cubes, cones, cylinders, and spheres) group these objects, move them around, apply material properties, and interactively explore the scene that you create.

Readings:

To learn all about Inventor, read The Inventor Mentor, which can be accessed online through Insight, or can be purchased at the bookstore. We suggest reading the material for the required features, implement them, and then, for each optional feature that you choose to implement, read the related chapter. In general, you can skip the sections marked Advanced.

For the required features you will need:

For the optional features:

Chapters 4, 7, 13. While you're reading the book, you may wish to try out some of the examples, make a few changes and see how they work. All of the examples from the book are available in the directory:

/usr/share/src/Inventor/examples/Mentor/C++/

You may also wish to have a look at some of the example models in the directory:

/usr/share/data/models

These models can be viewed with several programs, each of which has different features (gview is most like the program you will create):

/usr/sbin/ivview, /usr/sbin/SceneViewer, and /u/cs426/bin/gview.

Now that you have some understanding of how Inventor scene graphs work, sit down and design a reasonable organization of your scene graph. You may want to make simplifying assumptions. Some possibilities:

All objects correspond to a subtree: you have a separator root, the first child will always be a transform node, possibly followed by a material node, with the shape node (or group node) the last child
All objects have a transformation node and a material node present
The first level of the graph has only "utility" nodes (Camera, Selection, EventCallbacks, etc)

It is very important that you do this design step BEFORE you start coding. Think about all the behavior of your program (what happens when you paste objects? what happens when you ungroup? how many nodes can affect a certain object (transformation, material, texture, rotationXYZ for animation, etc) Can nodes be shared? Sharing is nice, but it is very easy to introduce bugs if you use it. ) It will be very hard (and very error-prone) to change the underlying assuptions about your scene graph after implementing a good part of the code.

Required Features (10 points):

Rapidapp UI: a viewer, menus for load/save, new object, etc.
Be able to create objects (cubes, spheres, cylinders, cones) and position, scale, and rotate them in 3-space.
Select single objects / multiple objects. When one object is selected you should show some object properties (name, world coordinates of bounding box center, bounding box dimensions). Selected objects should be highlighted.
Names: all your objects should have names. Newly created objects should get default names (eg. cube1, cube2, sphere1 , group1, ...) and the user should have the option to change current names.
Group several objects to create a new one. Ungrouping should do something sensible with the properties (eg. if the whole group was green and the individual parts did not have materials, after ungrouping each part should be green)
Transform (move, rotate, scale) the selected object.
Edit the material for the selected objects (you should be able to change the material for several selected objects at the same time).
Write/read the scene graph to/from a file. It is ok to be able to read only the files that you produced, but you should reject other files gracefully.
Cut, copy, paste.
Implement a traversal function that visits your scene graph and writes an indented tree of the object names. This is useful for debugging your scene graph.
Turn in an inventor file that represents a scene similar to the one you created for the previous assignment.

Optional features:

(1) Don't forget the art contest.
(1) Be able to load an arbitrary Inventor scene graph and treat it as an object. If it is a scene that you created it should be inserted as a new group object (which you could later ungroup).
(1) Render a frame using the current camera and save the image to disk.You may wish to use an off-screen buffer.
(1) Undo / Redo.

(1) Unlimited Undo / Redo.

(1) Apply textures to objects.
(1) Dialog allowing user to specify texture parameters (like texture transform fields)
(1) Be able to record a set of camera positions.

(1) Interpolation between camera positions.
(1) Make a fly-by movie of a scene by saving frames for each interpolated camera position.

(1) Allow shared instancing in your scene graph. When the user tries to change the property of an object that appears in several instances, ask if just the instance that was selected is to be changed, or if all instances should be changed at the same time.
(1) Be able to produce VRML 2.0 files (using available IV->VRML1.0->VRML2.0 converters)

(1) Be able to produce VRML 2.0 files directly from your code (without using any 3rd party converter)

(2) Snap to 3D grid: when you move/scale an object, the center/ top/ bottom (let the user chose) of the bounding box should be aligned with the grid.
(2) Objects with simple animations (eg. rotation around some axis, swing between 2 positions, etc.)
(3) Have a separate window showing a graphical representation of your scene graph.

(2) Be able to edit it the scene graph in the other window (like gview does).

(5) Create a cool 3D interactive game, e.g. 3D pong or 3D break-out.
(?) Any other feature you can think of.

Warnings:

Inventor uses ROW vectors to represent points (as opposed to GL and the rest of the graphics world who use COLUMN vectors). This means that to transform a point, you multiply vector * matrix (the matrix goes on the right, not on the left as in GL). Also when descending the scene graph, transformations are accumulated by multiplying with the new matrix on the left. So ... when in doubt, transpose!
Inventor doesn't particularly like you to modify its scene graph while it's traversing it. If you want to do anything useful from an EventCallback node, all the immediate children of all the ancestors of the callback node have to be unaffected. To ensure this, you could place the EventCallback node as the last child on the first level of the graph, and have all object subtrees have their roots on levels>1.
Use LOTS of assertions, particularly when typecasting objects. Inventor will happily core-dump (without giving you a reason) when you typecast a class to an incompatible type. We will penalize programs that core-dump without giving a reason, so ASSERTIONS ARE YOUR FRIENDS.

Tips: