Fly me to the teapot

CSE 557 Final Project – Winter, 2006
Leith Caldwell

The challenge

The goal of this project was to create a small-scale, interactive, three-dimensional simulation involving the principles from earlier in the course. The focus was largely on two things: creating interactivity with the principles of the course; and implementing a particle system, which I was not able to work on earlier.

Since this is essentially building a virtual world from the ground up, the project was constrained to illustrate as much as possible while realising its own limitations and allowing for high extensibility.

The how

That's right. A floor.

The approach I took was literally 'from the ground up'. The idea was to add elements to the scene piece by piece, building up the complexity as I went by adding the scene, the ship, some objects in the scene, the ship's movement (a set path to start with, freedom of movement as an extension), the particle system and a few types of particles, a few forces to act on the the particle system, collision detection and destructibility of scene objects.

I started by bulding the window interface, then adding in a basic tessalation of quadrilaterals for the floor plane and a light source. This involved:

Around in a circle, like so.

After that I added the ship and a few objects (box, sphere, cone and teapot) to the scene. Initially the ship model was ported as simply as possible, however later it was necessary to abstract it out and give it further attributes (like up, facing and position vectors) in order to make camera and particle calculations simple and manageable.

Initially the ship path was set up as a simple translate to the orbit distance and orbit height then rotated about the y-axis vector (0, 1, 0), however this was changed to more appropriate transformations based on the attributes of the ship object later on. This step was:

Bombs away...

Next came the particle system. Since I had not been able to exlpore particle systems in the Animator project, this was an important focus to abstract properly and understand how the system worked over time. This system contains an arbitrary number of particles, an arbitrary number of forces, state variables for keeping track of how many forces and particles are active at any given point in time, and a reference to the Scene object that contains objects implemented as particles in order to do collision detection. This involved:

Each particle in this system has a type, mass, position vector, velocity vector, force accumulator and 'active state' variable. They also have life and fade speed variable for particles that dissolve (for example exhaust fumes), although these were unused in this project.

The first particles that I added into the system were simple points in order to correctly trace their motion in the scene, although this was relatively quickly shifted to spheres to allow for a better perspective view. While I was aiming to create these particles to look as much like the bombs from the game which the ship model was based off of, initial attempts added too much complexity to render in acceptable time.

In order to save calculation time, only 'active' particles and forces are considered when cycling over each list. The number of active particles and forces are maintained in the particle system, however there is no separate list. Further work could include the inclusion of this.

Left: no wind. Right: wind.

In order for the particles to move appropriately, basic forces were needed. The system contains a couple of 'hard-wired' forces and provides a framework for adding other forces to the scene. I only implemented constant forces and forces with viscous drag, although there are attributes and references in the force structure to allow for spring forces as well. The 'hard-wired' forces are gravity and the initial velocity of the particle. In the case of the bomb, this initial velocity is the velocity of the ship.

I implemented:

The next thing to implement from the goal set was collision detection. Collision detection with the floor is implemented as simple planar intersection, and allowed basic explosions to be implemented at the points of intersection. Collision detection with scene objects is a harder problem and one that is only partially addressed by this solution.

Each object in the scene that is implemented as a 'object particle' gained the various attributes of a particle, including those inherited from SceneElement, an abstraction drawn from the Ray Tracer project. This allowed the object particle to have a bounding box (not a tight bounding volume) and to perform bounding box intersections with other particles (like bombs, or explosion particles). Presently this intersection only returns true if the particle intersecting is within the bounding box of the object particle.

For this implementation this meant that the explosion particles would not pass through the object particle, which in the scene is the box.

Just a little more...

Fog, sky and funky camera angle!

In addition to implementing the initial goal list, I also extended the program in several ways, each of which has keyboard controls to toggle them or switch to them:

In addition to these the light was able to be turned on/off, as well as toggling a sphere positioned at the light source and adding a spherical 'sky' enclosure to the scene, however these were considered to be part of the initial goal implementation.

Changes to the original plan

During the development of this project, a few things became clear about the original plan that needed to change.


The Camera
Originally there was to only be one camera view, sitting behind the ship in 'third person'. However, while other camera viewpoints were considered to be extra, it was necessary to have at least a roaming view to explore the scene.

The plan was to be able to 'destruct' some or all of the objects in the scene through projectiles from the ship. Apart from a box implemented as a particle towards the end of the project, it was evident that without re-implementing the methods provided by OpenGL for spheres, cylinders, cones, teapots and so forth, it would be impossible to extract the necessary information (vertex set, trimesh faces, etc.) in order to destruct the scene objects in any plausible manner. It was decided to implement basic explosions (previously an extension) as an alternative.

The result

After all that, I have a working interactive simulation. As previously mentioned, there are always more things to add to a simulation in order to make it more realistic, more feature-rich, more controllable or just more fun. The simulation is three-dimensional, uses hierarchical modelling and uses various affine transformations, for example viewpoint calculations.

The end result includes an abstract particle system, including classes for both particles and forces, which was a driving factor in the development of this project. This system implements two different kinds of forces, as well as introducing gravity and correct velocity and acceleration calculations.

This ship simulation program also has a number of features and extensions which are 'almost' included, if you can see it. The solution is abstracted enough and contains enough information to implement many of the extensions in the next section.

There is always more you can do

This list is by no means comprehensive, but includes a number of things that could be implemented in fairly short order as well as several things that would take a lot more thought and effort. Each of these of course could be tweakable in some fashion via input from the user. Possible extensions:

The really ambitious might want to take on creating new scenes entirely, such as the levels in the space-mines from the game Descent, from which the ship model was originally inspired.

Resources & Related work

This project drew on several areas for code materials and ideas. The model used was my space-ship from the Animator project. The bounding-box intersection code was based off of the Ray Tracing project. Some of the windowing functions and set-up of the GLUT interface were based off of an earlier project. Several online tutorials were useful for learning to implement some features, in particular NeHe was rather valuable.

Almost everyone has now at some stage seen examples of three-dimensional environments and what they're capable of. One of the most pervasive examples of this would be games. Creating a virtual world, populating it with objects, lights, natural phenomena and 'charactes' is as simple or as complex as the designer chooses to make it. Under the constraints of this project, it may be more realistic to look at some of the 3D games being produced in the late 1990s for a basis of comparison.


Thanks to Rob Nash and Dave Bargeron for putting up with my emails at all hours of the night, and thanks to Brian Curless for allowing me the opportunity to explore a little of what I can do with a simulation and for teaching me Graphics this quarter.