Out of Gas: A Race Until the End6.837 Computer Graphics Final Report Team Members:[Dave Chen] [email protected][Hau Hwang] [email protected][Jeremy Lilley] [email protected]"Out of Gas" is a racing car game developed in OpenGL and C++. The setting is a hilly, unpredictableterrain with many obstacles, which we render in 3D from a rapidly moving camera that tracks the car.We implemented a detailed physics simulation engine to control the movement of the car and othermoving objects across the terrain. This in particular includes height tracking, obstacle collisiondetection, and accelerations due to gravity. We also included an object-level culling algorithm, whichdivides the terrain into rectangular partitions and can omit or draw the obstacles in the rectangularpatches at different levels of detail depending on distance. Since this is a racing game, we optimizedheavily for graphics speed whenever possible, which prompted our development of a proprietarymodeling format based on OpenGL, and a suite of related support utilities. [Introduction] [Goals] [Achievements] [Individual Contributions] [Lessons Learned][Acknowledgments] [Bibliography] [Appendices] 1. IntroductionOver the first part of this semester in 6.837, we explored the graphics pipeline, but for the secondpart, we wanted to investigate it in a context that is all too familiar to us -- in the context of agame. Specifically, we built a 3D racing car game for our final project, set on a hilly terrain withmany obstacles. We wanted to allow a large degree of freedom for the user to drive all over and"see the world" from different peaks and valleys, and we wanted to make sure we could includeenough optimizations to allow a decent framerate. Throughout our game, there has been a large amount of effort in simulating the movement of thecar accurately and being able to track the surface of hills. We deal with variations in height withour height map and physical motion of moving objects with our physics simulation engine. Toview this better, we allow the user to dynamically move the camera in relation to the car, so thatthe player is not constrained to experiencing his collision with a rogue foodtruck from the typicalfirst-person view. We implement a number of graphics optimizations to increase the frame rate. This includesrendering obstacles at different levels of detail depending on distance, and culling objects outsidethe regular field of view. We also use sprites to avoid using many polygons for distant objects.Our game is written in C++ using the OpenGL libraries, so it can be made to run on manydifferent platforms, just in case not every player has an SGI O2. We use the GLUT toolkit formore flexibility with GL, and by also using the free Mesa3d GL emulation libraries, we were ableto target Solaris and Linux workstations as well, and use them in our development. 2. GoalsOver the course of the project, our goals changed as we saw what was more and less feasible toimplement in the allotted time. For instance, we expanded the project to better emphasize physicsmodeling and realistically simulating a car over a rugged terrain with obstacles. Meanwhile, weshifted away from some complex level of detail optimizations that could have easily been projectsin and of themselves. With that stated, this is a short list of what we wanted to accomplish in thecontext of our game. Speed - Any game needs to be able to render its frames quickly, but in the case of a racinggame, this goal is even more critical. We knew this was a necessity from the beginning, andmade many decisions based on this, including the use of OpenGL over OpenInventor as ourrendering language. Special graphics optimizations, particularly dealing with level of detail (LOD) - One of thechallenges in any outdoor graphics rendering problem is coping with the number of small,distant objects, since there is less natural occlusion than in an indoor situation, which mayhave many relatively near-by walls that serve as visibility boundaries. There may be manycomplex distant objects, which while not occluded, may only take up a few pixels on thescreen. Our goal was to implement some optimizations that allow us to add more detail andto make the game more realistic. Some of these include: Rendering objects at multiple levels of detail [Shade96] Polygon caching by generating sprites [SS95] - we discovered that this could easily bea final project in and of itself. Nevertheless, we did create sprites for the backgroundand scenery. Using speed in rendering decisions - for lack of a good heuristic of what to drop whendriving at high speeds, we chose to concentrate more on object-level culling. Object/higher-level culling - While not explicitly a goal at first, we wanted to avoidunnecessarily sending extra polygons to the graphics libraries. This led to apartitioning algorithm that also became the basis for how LOD is implemented. Physics Modeling - This was not explicitly a goal at the time of the original projectproposal, but as it progressed, the realistic simulation of car movement became one of themore interesting parts of the project. Large variations in terrain height - We decided that a rugged terrain would not only bemore exciting to develop, but it would also allow us to better show off our physics engine.This caused us to place a large emphasis in building a reasonable height map. However, itmade other graphics optimizations more complex. 3. AchievementsThe main achievement, of course, is producing a game which matches many of our original goals.But that consists of many different parts. Below, we split them into the Game engine, Graphicsoptimizations, Modeling, and Physics:1. GameGame engineDisplayed below is a dependency diagram for some of the objects handled by the game. Thisdiagram shows various ‘‘things’’ that are part of a driving game and how they relate to oneanother. At the top is the Game object, which is the center of the game engine. It sets up theGLUT call-backs, initializes the display, starts making frames per second measurements, andcreates a Race object. The Race object creates a Map object, some MovingObjects, and somePlayers. It then cycles through calling the Physics engine, asking Players to update, andadjusting the camera. A Player object is conceptually the entity that controls a car object. Associated with a playerare Player Properties. This object specifies the name of the player along with the player’scontrols (keyboard, AI, network, etc.) A
View Full Document
Unlocking...