Box o' Balls (AKA 3D Asteroids Abortion) Key Function '1' Toggle gravity '2' Toggle between local and global gravity '3' Toggle air resistance '4' Toggle gravity well at center of box '5' Toggle gravity source from center of box 't' Increase gravity 'g' Decrease gravity 'y' Increase air resistance 'h' Decrease air resistance 'r' Viewpoint up 'f' Viewpoint down 'w' Viewpoint forward 's' Viewpoint backward 'a' Viewpoint left 'd' Viewpoint right ' ' Insert new random ball 'v' Remove most recently inserted ball 'u' Print this message 'KEY_UP' Rotate back in box's zy plane 'KEY_DN' Rotate forward in box's zy plane 'KEY_LT' Rotate left 'KEY_RT' Rotate right This thing is almost cool. Too much time on back-end, but still some nice effects I started out wanting to do a 3d rendered version of "asteroids". It was only going to have motion in 2d, but I wanted to have collisions and wrap around walls. I ended up with just a physics demo, basically, with some textures. It is written in ANSI C, and I tried to make it fairly light weight. It was probaly this that was my undoing. I ended up writting a lot of tools for doing vector math, and for drawing in different coordinate systems, but without much to show for it. I am, however, happy with the physics and the collisions. I didn't look up anything but the equations for the physics, and I derived the collision detection equations (more time wasted, I know). The way it works is there are basically three different engines, although two are really interconnected. One engine handles visible objects, one handles moving objects, and one handles collidable object. All the engines use a common data structure that holds shared information. The visible objects engine is basically the draw routine. It has objects registered with it that hold the shared data, a funtion to draw the object, and some information for the draw routine specific to this instance of the object. This alows for a common interface that can do just about anything. The draw info can hold size and shape data, or even another set of draw functions that can be caled based on a flag. Fo instance if a collision has been detected you can have the ship draw it self exploding. Brilliant, right? I know, I'm amazing. Another thing this lets you do is position lights in an objects draw function. I wanted the lasers to be translucent red cylinders or rectangles that emmited light. I was going to do this by limiting the number of shots on screen and positioning the lights in the center of the shot. The draw routine also acts as a controller for the physics engine. These are called before the objects are drawn in order to update the object's position. The Physics engine has objects that are moving registered with it. These objects have a list of force generators associated with them. This list can be arbitrarily long. The idea is that when a timestep occurs, the list is iterated through and the velocity vector is updated with the result of each force generator. Each force generator is a function and a link back to the shared object info. This gives us many ways to apply forces. The ones that I used in the demo are a gravity force generator that can do a global gravity, independent of the box's rotation, or a local gravity that uses the negative y direction of the box as down. Gravity is toggled with '1' and local gravity/ global gravity are toggled between with '2'. There is also air resistance that generates a force in the direction opposite the objects current velocity vector (toggled with '3'). There is also a gravity well and a gravity source that can be toggled at the origin. The gravity well pulls in to the origin and the source pushes out from the origin. The well is toggled with '4' and the source is toggled with '5'. Planets can be modeled with gravity that affects you as you fly by, perhaps toggled by flying within some spherical boundry. Can also do tractor beams, not to mention the obvious propulsion systems. The original idea was to incorporate some optional information about the generators position relative to the center (or cener of mass) of the object that would allow spinning for offset forces. This idea just looked like it would take too much time to design. Before the physics routine ends it calls the collision engine to handle any collisions that might have occured. I didn't handle collisions as well as I would have liked. The overall idea is fairly solid, but their were some design issues that showed up later that could have made the physics engine run nicer. One thing that is kind of annoying is that conservation of energy is not implemented. This leads to some counter intuitive things happening during a collision that a pretty glaring (big balls will stop on a dime on some collisions with small balls.) The basic idea for the way collisions are modeled is a collision hierarchy of bounding spheres. There is a single sphere that covers the entire object which holds a list of smaller spheres that can define the area more accurately and so on till you reach the level of deetail you would like. I'm using only one sphere for each ball, but the idea allows any number of shapes to be bound (complex models would probably require the development of a tool to handle bounding and also probably a new way of handling the data- the list idea has a lot of overhead). Collisions are kind of a kluge as far as the physics go, but they look good enough for me. I also implemented collisions with arbitrary (infinite) planes. I wanted to do finite planes, but I ran out of time(and then some). Planes are specified by a point and a normal. As for the scene, I was going for a transparent box that is bounded by planes. The box is rendered with transparent textures (that is actually a false color image of a solar flare if you are curious). I also drew a sphere around the whole scene and put a texture on its interior. The balls just bounce around in the box. I will avoid all the usual ribald puns involving balls and just say, have fun playing with my scene. Dana Mifflin