Life is a Space Odyssey: Midterm Progress Report

From EQUIS Lab Wiki

Contents 1 Project Description 2 Changes to the User Interface 3 Project Milestones & Schedule 3.1 Initial Stages of Development 3.2 Revised Stages of Development 3.3 Final Schedule 4 Technology 4.1 Sound in LIAV 4.2 OgreODE 4.2.1 New Variables 4.2.2 Defining the Physics 4.2.3 The Space & StepHandler 4.2.4 CAXWorldODEObject & CAXAvatar 4.2.5 FrameListener & Terrain 4.2.6 Architecture 4.3 Google SketchUp & Ogre 4.3.1 Changes to LIAV to Use SketchUp Models 4.4 Terrain Generation 4.5 Implementing A Custom Skydome 5 Interaction With Other Groups

Project Description

Our project is the conversion of Life is a Village (LIAV) into a lunar lander simulator. The user will attempt to land a lunar lander on a target located on a 3d terrain. They must navigate the terrain to locate the target and avoid crashing while monitoring their fuel usage. The user must be careful to control their speed in order to land on the target at a reasonable speed to prevent crashing. The lander will be subject to gravitational forces, as well as forces exerted by the engines. The user will control the forces exerted by the engines in order to pilot the lander.

Changes to the User Interface

The user interface will be radically different in appearance than LIAV. The LIAV terrain will be replaced by a Martian terrain, complete with mounts, plains, and deep craters. The regular skybox will be replaced with a skybox showing a view out into space. All trees and villagers will be removed. The robot avatar will be replaced with a lunar lander model from the Google 3d Warhouse. The HUD will be changed to show the speed of the lander, the current fuel available, and the height from the surface. Sound will be added for ambience, as well as the engines on the lander and landing.

Project Milestones & Schedule

Initial Stages of Development

Stage 1	Stage 2	Stage 3	Stage 4
ODE physics engine	Add HUD	Transition from deep space to planet surface	Add obstacles
New terrain	Thrusters to handle ship rotation		Collision detection with airborne objects
Lander model			Sound HUD

Revised Stages of Development

Stage 1	Stage 2	Stage 3	Stage 4
ODE physics engine	Add HUD	Transition from deep space to planet surface	Add obstacles
New terrain	Thrusters to handle ship rotation		Collision detection with airborne objects
Lander model			Sound HUD

Final Schedule

Stage 1	Stage 2 - March 10th	Stage 3 - March 16th	Stage 4 - March 19th
ODE physics engine	Physics model for lander	Keyboard control for in-game thrusters	Basically complete! Fun to play? Game-like?
New terrain	Camera behaviour	Interactive sound with real sounds	Crash landings
Lander model	Integrate terrain with OGRE	Landing target	Joystick controls
Working sound in-game		HUD for fuel, speed, height	Jet thruster flames

Technology

Sound in LIAV

The sound in LIAV is handled by the CAXSoundManager and CAXSoundSource classes. These provide a C++ wrapper for OpenAL and the ALUT toolkit, including object representations of sound sources and a sound listener, simplified loading of sound files, and compatibility with some Ogre classes such as vectors.

In simplified terms, sounds are associated with places, and as the user moves through them they are "rendered" to the correct speakers to provide 3D sound. To do this, sound files are loaded into OpenAL sound buffers, which are then tied to a certain location in space where the sound will originate from (a CAXSoundSource). Sound sources are not directional, and will decrease in apparent volume as the user moves away from them in any direction.

The user is represented by a Listener embodied within the CAXSoundManager, which contains a position and an orientation. This represents the user or avatar's "virtual ears" in the space, and so must be kept synchronized with the avatar's position and orientation. It is important to note that orientation includes both a "forward" direction vector and an "up" direction vector, up being required to resolve the ambiguity of an avatar that might be able to perform rolls about the forward axis. In LIAV up is always simply (0, 1, 0), however in a flying or underwater game this would have to be calculated in each frame.

The only significant work required to get the sound running was to update the CAXGameState's UpdateAvatar method with calls to CAXSoundManager, to update the Listener's position and orientation to match the avatar's. Further information about the fix is available Getting Sound Working In LIAV.

At this point it is not expected that 3D sound will be required for Life is a Space Odyssey. The only sources of sound would be the rocket engines (location is the same as the avatar, so the sound never changes in relative position) and background music which is not located spatially within the actual game. Thus no further changes are expected to be performed on the sound code in the completion of the project.

OgreODE

In order to add proper physics we chose to use OgreODE a Open Dynamics Engine (ODE) wrapper. This physics wrapper supports all ODE primitives and adds prefabricated objects like vehicles, as well as providing rag doll support. The OgreODE download contains three tutorials/demoes, a simple scene that shows all the functions inside OgreODE ( primitives, collisions, joints, rag-doll physics, a car), a landscape showing use of the terrain scene manager in OgreODE, and finally a racing demo.

New Variables

In order to properly incorporate OgreODE into our project we created three new variables.

      OgreOde::World        *mWorld;
      OgreOde::Space        *mSpace;
      OgreOde::StepHandler  *mStepper;

The world is OgreODE’s topmost object, which is comparable to the root in Ogre. Every object is added to that world and must follow that the world’s rules (physics).

Defining the Physics

To define the physics of the world, several parameters are set.

      mWorld->setGravity(Vector3(0,-9.8,0);
      mWorld->setCFM(10e-5);
      mWorld->setERP(0.8);
      mWorld->setAutoSleep(true);
      mWorld->setContactCorrectionVelocity(1.0);

The Space & StepHandler

The space (or collision space) is a collection of all the objects or geometries. Objects can collide within their space, with objects from other spaces, or not collide with anything at all.

The StepHandler handles the time in the world and is used to update events. It runs every now and then (e.g. once per frame) and determines which body moves where and what collides with what.

CAXWorldODEObject & CAXAvatar

In order to use OgreODE a new class, CAXWorldODEObject, was created to replace CAXWorldObject. As a result, entities now have a mass and geometry. The mass object contains the total mass of the object and the centre of gravity within the body frame, given as a Vector3. The geometry of an object can be one of several types, box, sphere, cylinder, or triangular mesh. If a box geometry is used it must be passed as 3d vector.

The class CAXAvatar now inherits from CAXWorldODEObject, instead of CAXWorldObject. The mass and geometry for the avatar are passed in the constructor. The constructor creates an OgreODE::Body, applies the mass and geometry, and attaches the body to the scene node. CAXWorldODEObject also includes methods to access the OgreODE::Body and apply forces to the body.

FrameListener & Terrain

The StepHandler is included as part of the FrameListener, to update the ODE world’s time steps. The CollisionListener checks for contact between two bodies and applies the appropriate forces as a result of contact. It can set the level of bounciness as well as the friction.

The terrain is added to the world and space objects, which enables collision detection between the lander and the terrain.

Architecture

Google SketchUp & Ogre

Google SketchUp is a free 3d modeling tool provided by Google. Google SketchUp has access to a large repository of free 3d models through the Google 3d Warehouse. In order to use SketchUp models with Ogre, a SketchUp to Ogre Exporter was installed. This consisted of a ruby based script for exporting a selection from a SketchUp scene to an Ogre .mesh xml file and an Ogre .material file. Following this export, the OgreXML convertor was used to generate an Ogre binary .mesh file which can be used in LIAV.

Changes to LIAV to Use SketchUp Models

In order to use SketchUp models in LIAV several small changes must be made. Most notably, if the default robot avatar is being replaced all animation for the avatar must be removed. The lunar lander model we used is static, does not contain bones, and will not change in-game, making animation unnecessary. As well, we found that the scaling and placement of the origin for the lunar lander model was not consistent between LIAV and SketchUp. As such, the model must be scaled up several times in LIAV and the model must be translated in SketchUp such that the base is at the global SketchUp origin, as expected by LIAV.

Terrain Generation

A custom terrain was necessary for our project to create an appropriate martian landscape. Using existing data available from Google Maps, we were able to create a custom height map based off real Mars mapping data. We generated this height map in Adobe Photoshop. We cropped our initial image to 513 pixels on each side, changed it to a grayscale image, and applied a slight gaussian blur to slightly smooth out the rough transitions the terrain heigh map would result in. We were easily able to modify the maximum and minimum heights by changing the brightness and contrast values, as well as editing terrain.cfg to change the maximum height. Our resulting image was a grayscale height map useable by Ogre, that when combined with our texture map gave us a nice Martian terrain. In order for the user to determine the height of the lander when playing we plan on adding additional depth cues to the terrain in the form of more detailed texture mapping or potentially shadows.

Implementing A Custom Skydome

Our project also required a custom space skydome, giving the users a view of the stars when playing. In order to do this, we first found an appropriate high resolution jpeg image to display on the skydome and created a custom material in the sky.material in the include directory. To create the custom material we used the following code.

      material CAX/SpaceSkyBox {
         technique {
            pass {
            lighting off
            depth_write off
            texture_unit {
                texture space.jpg 
             }
           }
         }
      }

In order to apply our material to the skydome, we modified CAXApplication. First, we removed the fog, as this was obscuring the visibility of the skydome. In the future, we would like to change the fog to create the appearance of a light dust over the terrain. Following this, we set the current skydome to our material and tweaked the parameters to ensure it properly wrapped the skydome and tiled the space jpeg image an appropriate number of times.

Interaction With Other Groups

Our interaction with other groups has been limited to providing documentation on getting sound working in Ogre, using OgreODE, and using the Google SketchUp Ogre Exporter. This documentation consists of step-by-step installation, configuration, and building instructions on the Equis wiki. These pages are easily editable and we will update them if we come across any new information when working on our project.