From vision to prototype - Virtual road racing. Eric Chung Anders Östlund

Transcription

1 Examensarbete utfört i Bildkodning vid Linköping tekniska högskola av Eric Chung Anders Östlund Rapport nummer: LITH-ISY-EX--05/3613--SE Handledare: Jonas Blom Examinator: Ingemar Ragnemalm Linköping:

2

3 Avdelning, Institution Division, Department Institutionen för systemteknik LINKÖPING Datum Date Språk Language Svenska/Swedish X Engelska/English Rapporttyp Report category Licentiatavhandling X Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LITH-ISY-EX--05/3613--SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version Titel Title Författare Authors Från idé till prototyp - Virtuell cykling From vision to prototype - Virtual road racing Eric Chung, Anders Östlund Sammanfattning Abstract Riding a stationary exercise bike regularly can lead to many health benefits such as stronger muscles, higher metabolism and reduced body fat percentage to mention a few. The biggest drawback is that training on a stationary exercise bike can be immensely boring with no stimulation or amusement factor. This thesis presents the development of a prototype, a road racing simulator that makes training on an exercise bike more stimulating. The prototype consists of an exercise bike and a computer game. It also features a network option, making it possible to race other users, multi player style. The purpose is to make home training on the exercise bike more amusing, enjoyable and maybe even challenging. The focus in this report lies mainly on the graphics and network parts but all steps in producing the prototype are described so the reader can get a complete picture of the project. Nyckelord Keyword graphics, network, Internet, physics, simulator, game, exercise bike

4

5 Abstract Riding a stationary exercise bike regularly can lead to many health benefits such as stronger muscles, higher metabolism and reduced body fat percentage to mention a few. The biggest drawback is that training on a stationary exercise bike can be immensely boring with no stimulation or amusement factor. This thesis presents the development of a prototype, a road racing simulator that makes training on an exercise bike more stimulating. The prototype consists of an exercise bike and a computer game. It also features a network option, making it possible to race other users, multi player style. The purpose is to make home training on the exercise bike more amusing, enjoyable and maybe even challenging. The focus in this report lies mainly on the graphics and network parts but all steps in producing the prototype are described so the reader can get a complete picture of the project. i

6 ii From vision to prototype - Virtual road racing

7 1) Introduction ) Background ) Purpose ) Goal ) Competitors ) Focus ) Report outline ) Prerequisites ) Problem analysis ) Exercise bike communication ) Cycling game ) Opponents ) Map creation ) Prototype requirements ) Requirements ) Requirements background ) Prototype design ) Introduction ) Application dependencies ) Engine design ) Client design ) Server design ) Editor design ) Communication with exercise bike ) Exercise bike ) Conditions for communicating ) Utilized hardware ) Communication ) Graphics engine ) Introduction ) Design ) Terrain ) Water Table of contents iii

8 7) Network engine ) Network engine design ) Latency ) Latency handling in the game ) Conclusion ) Physics engine ) Introduction ) Design ) Conclusion ) Results and future work ) Results ) Future ) Conclusion ) Glossary ) References A) Screenshots B) Introduction to computer graphics B.1) Graphics engine B.2) Geometry representation B.3) Graphics API B.4) Graphics pipeline B.5) Programmable shaders B.6) Optimizations C) Introduction to computer networks C.1) Introduction C.2) Protocol C.3) UDP and TCP D) List of requirements D.1) General D.2) Exercise bike communication D.3) Map editor D.4) Cycling game iv Table of contents

9 E) Requirements handling E.1) General E.2) Exercise bike communication E.3) Map editor E.4) Cycling game Table of contents v

10 vi Table of contents

11 1 Introduction This chapter will give an introduction to the project, explaining the background and goals as well as an outline for this report. It should give the reader an idea on why the project was regarded interesting and appealing enough to be undertaken instead of being discarded as a fruitless idea. 1.1 Background Since the bicycle was invented it has served as commuting vehicle, goods carrier and exercise equipment among other purposes. As exercise equipment, the bike is an excellent choice as the training is low impact, gentle on knees and joints and trains both cardiovascular and muscular system. This in turn leads to better general health, posture etc. Furthermore the positive effects in the long run lead to higher metabolism, higher stress barrier, feeling better and more, all the positive effects of regular exercise. Bicycle riding is however quite weather dependent, especially in northern countries with low temperatures, maybe snow and few hours of daylight during autumn and winter season. Not only does it make biking less enjoyable, it also makes the riding more accident prone due to lower visibility and poor road conditions. One of the alternatives to all this would be to ride indoors on a home exercise bike. No more need to dress up in layers of clothes, packing extra equipment such as tools and extra clothing, being wary of cars and other road-user. The downside to all this is that it is plain and simple boring. Many are the home exercise bikes that have been bought, used for a short period of time and then put away indefinitely. Chapter 1: Introduction 1

12 1.2 Purpose Since the positive effects of biking are so many but the use of home exercise bike is so unstimulating there is a need to alter these conditions. With the weather and geographic position being less cooperative the next best thing would be to make home training on the exercise bike more amusing, enjoyable and maybe even challenging. 1.3 Goal The goal of this project is realize a vision from our employer which is to create a prototype which offers the user a game-like experience on the bike while the player exercises, thus leading to a combination of enjoyment and well being. The user should feel enjoyment while riding and appeal for riding again to improve the results, ride that particular track in a shorter period of time, reach another goal. Several different types of riding will be possible in the game such as single race and race against computer generated riders as well as other human riders over the Internet, that way introducing an element of competition. Figure 1: The prototype 2 Chapter 1: Introduction

13 1.4 Competitors The products and systems, similar to our prototype, available on the market all have various drawbacks that, if remedied, would lead to overall better end products. Using the competing products as a reference, this project aims to create a prototype without the mentioned drawbacks. This would mean that the prototype has several advantages over the competition if it would enter the market. 1.5 Focus The focus in this report and the master thesis in all lies mainly in the chapters about graphics and computer networks. These are the areas where most research has been carried out during the course of the project. This is not to say that the other areas and subjects are unimportant, they have been milestones and parts, each contributing to the end result and final product of the exam work. An example of this would be the electronic communication between computer and exercise bike. Even though it did pose a challenge to get fully functional it was not one of the main subjects that were to be researched. 1.6 Report outline This section gives a short description of the chapters and appendices in this report to give the reader a quick overview. Also it helps the reader to easily find the chapter that is of particular interest at the moment Thesis The thesis is where the main part of the work has been committed. These describe the different parts of the project such as background, parts of the game and results. 1. Introduction The introduction gives a comprehensive description of the project. Chapter 1: Introduction 3

14 2. Problem analysis This chapter states and describes the problems that are to be solved through this project. 3. Prototype requirements The prototype requirements chapter states the requirements that needs to be met for the prototype to be considered finished. 4. Prototype design This chapter describes the prototype design and discusses the aspects related to it. 5. Communication with exercise bike Communication between exercise bike and game PC is described in this chapter. 6. Graphics engine This chapter describes the graphics engine and discusses the aspects related to it. 7. Network engine This chapter describes the network engine and discusses the aspects related to it. 8. Physics engine This chapter describes the physics engine and discusses the aspects related to it. 9. Results and future work This chapter summarizes the work and results from this project. 10. Glossary Terms and concepts used in this thesis are described in this chapter. 11. References This chapter states all the references used in this thesis. 4 Chapter 1: Introduction

15 1.6.2 Appendices The purpose of the appendices is to give additional information on different parts of the thesis, some describing the basics of a subject in particular while other act as a compliment. A. Screenshots Screenshots of the game can be viewed here. B. Introduction to computer graphics The basics of computer graphics are described in this appendix. C. Introduction to computer networks The basics of computer networks are described in this appendix. D. List of requirements This appendix holds a list of all requirements. E. Requirements handling Here the requirements are stated again and a brief description of how the requirements were handled. 1.7 Prerequisites Here are descriptions of the different components and equipment needed during the project to make a functional prototype. Only the most important, unusual equipment are mentioned instead of listing every appliance used. Exercise bike The exercise bike was provided by the employer and was used as a part of the prototype. A small control box mounted on the exercise bike regulates the pedal resistance. It also registers pedal speed and communicates with a small computer with an LCD display showing RPM, speed, time, distance, calorie information and resistance. USB experimental card This is a component specially designed for analyzing and regulating USB communication via analogue and digital channels. Chapter 1: Introduction 5

16 Electric components The components used consisted of resistors, h-bridge, wires etc. Analysing equipment Analysing equipment used consisted of oscilloscope and multimeter, used for reading signals to and from the exercise bike. 6 Chapter 1: Introduction

17 2 Problem analysis The basic problem is to create a prototype of a computer game where the user interacts with the game by using an exercise bike. To define in general terms what the prototype should do and not do a problem analysis was devised in agreement with our employer. The analysis showed that the prototype should be able to handle four different kinds of tasks. Communication between exercise bike and computer game should be possible. The game receives data such as pedalling speed from the bike and sends signals to the bike to control pedalling resistance. The prototype should include a computer game where the exercise bike is used as interaction device. Opponents in the game should be either computer generated or real users over a network. The prototype should give a user the ability to create environments and tracks used in the virtual races. Chapter 2: Problem analysis 7

18 2.1 Exercise bike communication Advanced exercise bikes have two things the computer can communicate with: Pedal speed and pedal resistance. Pedal speed Pedal speed is usually measured by the pedal revolutions per minute (RPM) and will be used in the cycling game to calculate the rider s velocity. Pedal resistance The pedal resistance is the resistance on the pedals and will be used to give the rider physical feedback, making it possible to feel the hills and slopes travelled in the game. As there does not exist any standards on how exercise bikes are built it is impossible to build just one application that would work on any arbitrary exercise bike. Not only is the physical structure different, the means of detecting pedal revolutions and adjusting resistance have multiple solutions. Since one of the main objects with this project is to create a fully functional prototype, work will be limited to just the particular exercise bike provided by the employer. 2.2 Cycling game The prototype should include a simple cycling game where the user can race on virtual tracks with a virtual cyclist. The speed of the virtual cyclist is direct related to the pedal speed on the exercise bicycle. The game will give feedback to the user by changing the pedal resistance depending of conditions in the game such as air, slopes and rolling resistance. The graphics of the game will be showing landscapes and object passing by in a realistic manner to increase the sensation of taking a real bike ride. 2.3 Opponents The cycling game should be extended with the ability to race against opponents. These opponents can be either computer generated or real users over a computer network, also riding exercise bikes. 8 Chapter 2: Problem analysis

19 2.4 Map creation The cycling game needs a variety of different maps that can be used for races. These maps should be created in a map editor and loaded by the cycling game. Chapter 2: Problem analysis 9

20 10 Chapter 2: Problem analysis

21 3 Prototype requirements This chapter discusses and categorize the requirements set on the prototype to handle the tasks described in chapter 2 - Problem analysis. 3.1 Requirements To ensure a prototype of high quality and functionality, requirements had to be set. When formulating these, the individual requirement s quality, importance, viability and other factors had to be estimated while considering the limited amount of time this project was allowed to take. Ideas and suggestions that did not become requirements are listed in chapter 9 - Results and future work. The requirements are categorized into two classes: Basic and Normal. The basic class is requirements that have to be fulfilled by the prototype by the end of this project. All requirements listed in this class are needed for the prototype to function as a whole, as was intended when writing the system analysis. The normal class is requirements that should be implemented into the prototype but can be excluded to meet the project deadline. Requirements in this class are features that would add more possibilities and variety to the end product. Aside from the way the requirements are categorized into the basic and normal classes, they are also divided into the groups: General, Exercise bike communication, Map editor and Cycling game. The complete list of requirements can be found in appendix D - List of requirements. Chapter 3: Prototype requirements 11

22 3.2 Requirements background In this section some background notes will be mentioned about the requirements listed in appendix D - List of requirements. The main object of this project is to get a functional prototype, therefore it was set as requirement #1. As it is quite vague and unspecific it was clarified by the following requirements #2 to #19. In the same way as was stated in section Focus, the graphics and network parts is where most work is required. That makes requirements #9 to #12 and #17 the most demanding to fulfill and also most important. 12 Chapter 3: Prototype requirements

23 4 Prototype design This chapter will present the prototype design based on the requirements in chapter 3 - Prototype requirements. 4.1 Introduction The problem analysis categorizes what the prototype should be able to handle into four different tasks. Communication with exercise bike Cycling game Opponents management Map creation To accomplish these four tasks the prototype was designed as three separate applications. Client The client application handles communication between the exercise bike and all cycling game related tasks. This includes rendering the virtual maps, the physics simulation and opponent management. Server The server application handles the communication between clients when a race is conducted over a computer network. Editor The editor application handles the creation of new virtual maps that is used by the client in both single and multi player mode. Chapter 4: Prototype design 13

24 4.2 Application dependencies The three applications described in the previous section have problems that they share. Graphics Both the client and the editor will need some kind of graphics support to render the virtual maps. Network Both the client and the server will need to communicate over a computer network during multi player mode. To implement different solutions to basically the same problem is not efficient so the prototype applications are designed to share implementations. The implementations are shared in a library called an engine that will be used by the three applications. The engine will handle things like graphics, physics, game state management, communication with exercise bike and network communication. Figure 2: Abstract representation of the dependencies between the engine library and the three applications: Client, Server and Editor. 14 Chapter 4: Prototype design

25 4.3 Engine design The heart of the engine is the game state manager, which keeps track of the current game state. This includes for example map name, single or multi player mode, list of all opponents and other game objects related to the map. The game state manager also handles the communication between the game objects and the sub-engines Game objects Figure 3: Overview of the engine components. The map consists of different game objects, e.g. water, terrain and cyclists, and each object has a graphics part and a physics part. The graphics part describes how the graphics engine should render the object. The physics part describes the physical properties of the object, e.g. position and motion. Not all objects are moveable so the objects are separated into two classes: static objects and dynamic objects. Static objects Static objects are objects that during game play will not move e.g. terrain, houses or trees. A tree may move in the wind but this is still considered as static object. Because these objects are static the physics part, especially the collision detection, can be simplified. Chapter 4: Prototype design 15

26 Dynamic objects Dynamic objects are objects that can be moved during game play, e.g. cyclists and cameras, by applying external forces. These forces are either applied by the map environment such as gravity or by user interaction Graphics engine The graphics engine is responsible for all graphics related tasks such as rendering the game objects and the client s game menu. The graphics engine is described in more detail in chapter 6 - Graphics engine Network engine The network engine is responsible for all network related tasks such as handling the communication between clients in the multi player mode. The network engine is described in more detail in chapter 7 - Network engine Physics engine The physics engine is responsible for all physics related tasks such as simulating gravity, wind and friction applied to the virtual cyclist. It also handles collision detection between cyclists and between cyclists and static objects. Because the user cannot steer with the exercise bike the physics engine will guide the virtual cyclist along a predefined path. The physics engine is described in more detail in chapter 8 - Physics engine. 16 Chapter 4: Prototype design

27 4.3.5 User interaction The engine uses two different kind of user interaction: Mouse/keyboard and bicycle interaction. Mouse/Keyboard interaction Handles communication with mouse/keyboard devices and the event generated from the devices are delegated to the application that uses the engine. Bike interaction Handles communication with the exercise bike including controlling pedal resistance and receiving pedal speed. Chapter 4: Prototype design 17

28 4.4 Client design The client application is very simple because all of the tasks the client should handle are implemented in the engine. It is basically a state machine where each state controls the execution flow of the engine in a different way. The states are: Menu state, single player state and multi player state Menu state Menu state is the state the client enters when the application starts and displays a simple menu. The graphics engine renders this menu and all other engine components are disabled. The menu enables the user to choose between single player or multi player mode. If single player mode is chosen the user selects which virtual map to race on and the client enters the single player state. If multi player mode is chosen the user selects which server to join and the client enters the multi player state. Figure 4: Overview of what components the client uses in the engine when in menu state. 18 Chapter 4: Prototype design

29 4.4.2 Single player state In single player state the map chosen by the user is loaded and all map related game objects are added to the game state. Then the client enters the single player game loop. The single player game loop performs three important steps, which are repeated until the user either finishes the race or quits the game. User interaction step In the user interaction step the pedal speed from the exercise bicycle is converted into a force vector, which is applied to the virtual cyclist representing the user. Depending on the physical forces applied to the virtual cyclist the pedal resistance on the exercise bicycle is changed. Physics step In the physics step the combined force from gravity, air and friction acting on the virtual cyclist is calculated in the physics engine and added to the force calculated in the user interaction step. This force is then converted into a motion and the cyclist's position in the game is updated. Graphics step In the graphics step all game objects that are visible are sent to the graphics engine for rendering. Figure 5: Overview of what components the client uses in the engine when in single player state. Chapter 4: Prototype design 19

30 4.4.3 Multi player state In multi player state the client connects to the chosen server and receives the current game state. The map and opponents specified in the game state are loaded into the client s local game state and then the client enters the multi player game loop. The multi player game loop extends the single player game loop with a network step. Network step The network step is performed before the three single player steps and synchronizes the client s local game state with the server game state. Figure 6: Overview of what components the client uses in the engine when in multi player mode. 20 Chapter 4: Prototype design

31 4.5 Server design The server is used to conduct races over a computer network between users. Because the network engine implements all the tasks the server should handle, the server application basically initiates the game state, by loading the map that should be used in the race, and the network engine will take care of the rest. The network engine is described in chapter 7 - Network engine. Figure 7: Overview of what components the server uses in the engine. Chapter 4: Prototype design 21

32 4.6 Editor design The editor will be a graphical front-end of the game state and its game objects. The user can add and remove the different static game objects to the game state and the changes will be visible immediately. In the editor the user can also add different paths the cyclist can follow in the race. All these map related data can then be saved to a file. The client and server application can then read this file and set up a race based on the created map. Figure 8: Overview of what components the editor uses in the engine. 22 Chapter 4: Prototype design

33 5 Communication with exercise bike This chapter describes the physical prototype, the parts used to make it and the connection between the parts. Finally the essential communication for the prototype is explained. 5.1 Exercise bike The regular stationary exercise bike for home training is most often a quite simple machine. The older models have a cord following a groove in the flywheel, the friction between cord and flywheel causing pedalling resistance. Aside from that they do not have many more features. The more advanced models on the home training equipment market today use magnet or fluid resistance and have at most a small computer. The computer handles data such as time, resistance level, RPM count and lets the user set resistance, training program etc. The exercise bike used in this project is fairly ordinary and has features mentioned. The resistance is adjusted by a motor turning a small wheel. Attached to the wheel is a steel wire connected to a rail of magnets. The distance between the rail and the flywheel regulates the resistance. Figure 9: The exercise bike and its important parts Chapter 5: Communication with exercise bike 23

34 5.2 Conditions for communicating To be able to create a realistic simulation, the prototype needs to be able to adjust the resistance as well as read the RPM value. On the exercise bike this was managed by the computer fitted on the bike, controlling electric components mounted on the frame of the bike. To make use of these signals in the prototype, the wires leading from the components are connected to a USB experimental card. 5.3 Utilized hardware Motor Mounted on the exercise bike, part of what is called control box in this report. A motor using a small wheel changing the distance between flywheel and a series of magnets varies the pedalling resistance. It also contains a part that illustrates the position of the wheel through a voltage value. RPM counter A magnet mounted on one of the cranks passing a sensor on the frame. Signals are sent from the sensor to the bike s computer and is converted to an actual figure that is the RPM USB circuit board A USB experiment interface board, the link between bike and PC. It has digital and analogue inputs and outputs, making it possible to analyze signals sent from the bike and adjust output signals needed to control the motor. 24 Chapter 5: Communication with exercise bike

35 5.4 Communication When the game is running, data is sent between game and exercise bike continuously. By using data from the RPM counter the game calculates velocity and distance travelled. This is illustrated on screen when racing in the game. When conditions in the game change e.g. the virtual cyclist approaches a hill or closes in behind another cyclist, then the resistance on the exercise bike will change accordingly. This is controlled by the game, sending signals to run the motor. Figure 10: The control box. Chapter 5: Communication with exercise bike 25

36 26 Chapter 5: Communication with exercise bike

37 6 Graphics engine This chapter will describe the graphics engine which handles all graphics related task in the prototype. The reader should have basic knowledge of computer graphics to fully understand this chapter. Chapter B - Introduction to computer graphics and Akenine- Möller[1] are recommended reading for a good introduction to this field. 6.1 Introduction The quality and performance of the graphics engine is an important part for whether the prototype will be a success or not because it is the first thing the user will notice and judge. To match the graphics quality of today s computer games the graphics engine will need to be extremely complex. It also has to be modular and easy to update to be able handle the fast changes in the graphics hardware industry. Otherwise the graphics will look very outdated in a few years. The easiest way to get a good graphics engine would be to license one of the commercial engines available, e.g. the Unreal engine[47] or Renderware[44]. Unfortunately this is not possible because the limited budget the project has. The free open-source alternatives, e.g. Ogre3D[37] or Irrlicht[24], could work but has to be modified to match the prototype requirements. This led to the decision to make an own graphics engine which would be easier and give more freedom in the prototype design. Chapter 6: Graphics engine 27

38 6.2 Design The graphics engine is designed to handle all graphics related task in the client and editor application described in chapter 4 - Prototype design. The graphics tasks can be categorized into the following parts: Game menu and game objects rendering. Figure 11: Layer representation of the dependencies from application to graphics hardware. Game menu To enable the user to choose between single player and multi player game mode, a game menu will be rendered by the graphics engine. This is done by the client specifying how the menu should look like and the graphics engine converts this specification to a set of textured 2D polygons which will be sent to the graphics hardware for rendering. See section Menu rendering for more details. Game objects When a certain virtual map is loaded by the client or editor application the graphics engine will render the game objects linked to the map. See section Map rendering for more details. 28 Chapter 6: Graphics engine

39 6.2.1 API independence The graphics engine is designed to be API independent and uses a plug-in interface which abstracts the different API s. This makes it easy to add new API s, e.g. new versions of DirectX or OpenGL, without changing the rest of the graphics engine. If there are new functionalities in the API, these are simply added in the plug-in interface and can be used by the rest of the graphics engine. Because of the API independence all API related object, such as textures, hardware buffers, shader programs has to be abstracted to a general implementation which is used by the graphics engine. In the plugins these general objects are converted into API dependent objects and are sent to the graphics hardware. «interface» VertexDeclaration «uses» «interface» Texture «interface» RenderSystem «uses» «uses» «uses» «uses» «interface» Surface «interface» Shader «interface» HardwareBuffer «interface» VertexShader «interface» PixelShader «interface» VertexBuffer «interface» IndexBuffer Figure 12: Design of the API independent plug-in interface. Render system The render system is the main part of the plug-in interface. It abstracts most of the API calls controlling rendering and render states. Chapter 6: Graphics engine 29

40 Vertex declaration Vertex declaration controls what kind of information the vertices should contain. A vertex can hold e.g. position, color, texture coordinates and normal vectors. Texture A texture is a set of pictures that are applied to graphics primitives. The texture part abstracts how these pictures are sent to the graphics hardware. Surface A surface is one of the pictures in a texture and is used both by the texture part and by the render system controlling individual surfaces. Shader A shader is a small program that is executed on the GPU on per vertex/pixel level. Two different kinds of shaders are abstracted: vertex and pixel shaders. Shaders are discussed in detailed in section B.5 - Programmable shaders. Hardware buffer The hardware buffers part abstracts two different kinds of graphics hardware buffers, vertex and index buffer. 30 Chapter 6: Graphics engine

41 6.2.2 Graphics hardware support The graphics engine has to support a variety of graphics hardware, from the Nvidia Geforce 2 release in the year 2000 to the Nvidia Geforce 6800 release in The capabilities of these hardware are very different and a map rendered with a Geforce 6800 should have significant quality improvement over the same map rendered with Geforce 2. To accomplish this the graphics hardware is categorized into classes and each class has its own implementation on how the map objects should be rendered. The current graphics engine has support for four different graphics hardware classes but this can easily be extended with the release of new graphics hardware and API s. The four classes are: FF, PP1, PP2 and PP3. FF FF stands for fixed-function and means that this class supports graphics hardware, which is not programmable and have to use the fixed-function/texture stages pipeline in the graphics pipeline. PP1 PP1 stands for programmable pipeline 1 and means that this class supports graphics hardware, which supports vertex/pixel shaders 1.1. See appendix B.5 - Programmable shaders for information about vertex/pixel shaders capabilities. PP2 PP2 stands for programmable pipeline 2 and means that this class supports graphics hardware, which supports vertex/pixel shaders 2.0. See appendix B.5 - Programmable shaders for information about vertex/pixel shaders capabilities. Chapter 6: Graphics engine 31

42 PP3 PP3 stands for programmable pipeline 3 and means that this class supports graphics hardware, which supports vertex/pixel shaders 3.0. See appendix B.5 - Programmable shaders for information about vertex/pixel shaders capabilities. Here is a list of graphics hardware from ATI and Nvidia and how they are categorized into the different classes by the graphics engine. Notice that the classes are backward compatible so a PP1 render implementation will work in PP1 class hardware as well as PP2 and PP3. Graphics hardware FF PP1 PP2 PP3 Nvidia Geforce 2 X Nvidia Geforce 3 X X Nvidia Geforce 4 X X Nvidia Geforce FX-series X X X Nvidia Geforce 6-series X X X X ATI Radeon 8500 X X ATI Radeon 9-series X X X ATI Radeon X-series X X X Table 1: Supported graphics hardware for the different classes. 32 Chapter 6: Graphics engine

43 6.2.3 Effect framework To handle the four different hardware classes described in the previous section the graphics engine has an effect framework, which specifies how a game object should be rendered. To make it easy to develop new effects the effect framework is driven by script files which contain specifications on how the effect should be rendered on the four different hardware classes. In these scripts each hardware class has a list of render passes that specifies what render states and shader files should be used to render the effect in each pass. The effect framework supports multi pass rendering because not all effects can be rendered with only on pass. Because these effects are external scripts they can be changed without the need to recompile the graphics engine. Figure 13: Example of an effect with two hardware classes. Notice that PP1 hardware will use the FF class to render the object. Chapter 6: Graphics engine 33

44 6.2.4 Scene graph The dynamic objects in the game have different kinds of relationships when they move, e.g. a camera can be linked with a cyclist and follow it along a path. To link these objects the graphics engine uses a scene graph. A scene graph is a tree where the objects orientations and position are represented in the tree nodes. If an object in a node changes its orientation or position all sub nodes will move in the same way. Figure 14: a) Part of the scene graph representing the relationship between the path, cyclist and camera. b) A camera following the cyclist to produce a third person view of the race. 34 Chapter 6: Graphics engine

45 6.2.5 Menu rendering The menu system used by the client support e.g. static text, buttons and edit boxes. What the menu will look like is specified by the client and the graphics engine converts this specification to a set of textured 2D polygons that is rendered. The menu system is designed to use different API specific menu systems to simplify the implementation, e.g. the UI framework in DirectX 9c is used Map rendering The process of render all game objects linked to a virtual map is separated into two steps: Optimization step and a rendering step. Optimization step In the optimization step the game engine creates a rendering queue from all the game objects in the game state. To create an optimal render queue the graphics engine sorts the objects in such a way so the graphics hardware state changes are minimized. The graphics engine takes three different criterion into account when the rendering queue is sorted. 1. The rendering queue is first sorted by shader programs so objects using the same shader programs are rendered at the same time. This will minimize the time it takes to change shader programs in the graphics hardware and increase overall performance. 2. The rendering queue is then sorted by textures stages. If objects share textures these should be rendered at the same time to minimize the time the graphics hardware spends changing texture states. 3. The rendering queue is then sorted by general render states, e.g. alpha blending and fogging. Objects that share render state should be rendered together because changing render states can decrease the overall performance significantly. Chapter 6: Graphics engine 35

46 Rendering step In the rendering step the graphics engine uses the rendering queue, created in the optimization step, to render the objects in the given optimized order by calling a specific render method in each of game object. This method controls how the game objects should be rendered including optimizations techniques such as view frustum culling and level of details. The current prototype has support for the following graphics objects: Terrain Object representing a simple terrain. How the terrain object is rendered is described in section Terrain. Sky Object representing a simple static sky. Vegetation Object representing vegetation such as trees, bushes and grass. Water Object representing a basic water model. How the water object is rendered is described in section Water. Road Object representing roads. Cyclist Object representing virtual cyclists. 36 Chapter 6: Graphics engine

47 6.3 Terrain In this section the technique used in the graphics engine to render terrain objects is discussed. The technique is developed to maximize GPU usage and minimize CPU usage Introduction Terrain rendering is an important part in games and other visualization applications. The terrain object will be the backbone of the virtual map and all other objects will be in some way related to the terrain object. Terrain representation Most current games represent terrain by a height field, which is basically a function of two position variables returning the height in two-dimensional space. The drawback is that the height field only can represent a single height at fixed even distributed positions which will rule out the possibility to represent caves and overhangs. A technique based of parametric curves and patches will solve this drawback but due to simplicity and the fact that the prototype does not need caves and overhangs, the focus will be only on height field based terrain algorithms. Figure 15: a) Contour of a terrain possible to be represented by a height field. b) Contour of a terrain not possible to be represented by a height field due to the multiple heights at a single x position. Chapter 6: Graphics engine 37

48 Terrain primitives A height field based terrain with 1024x1024 height values will need over two million triangles to be presented in full resolution. To render these triangles in a brute force manner is not very efficient. Instead some basic concepts, such as view frustum culling, occlusion culling and level of details (LOD), can be used to minimize the number of rendered triangles and improve the performance. View frustum and occlusion culling can be used to remove triangles that are not visible and a LOD-system will reduce the number of triangles that are visible but can be remove because they are far away from the viewer, these optimization techniques are discussed in B.6 - Optimizations. The terrain algorithm presented in this thesis uses view frustum culling and a simple LOD-system discussed in section Triangle reduction. Terrain algorithms Terrain LOD algorithms has been an area of research for many years and presented algorithms can be divided into two classes: Regular grid based[11][32][8][33] and Triangulated irregular networks (TIN) based[22]. Figure 16: a) Regular grid based terrain. b) Triangulated irregular network based terrain. 38 Chapter 6: Graphics engine

49 Regular grid based algorithms build the polygons mesh either by recursive quad subdivision[32] or by binary subdivision[11]. Either way the mesh generated will be far from optimal and a lot of unnecessary triangles will be created. Figure 17: Three LOD-levels based on recursive quad subdivision. Figure 18: Three LOD-levels based on binary subdivision. The TIN based algorithm does not have this problem with unnecessary triangles and builds a polygon mesh that is as close to optimal as possible. However the TIN build step is much more complex than in the regular grid case and the regular grid approach is perfect for quadtree optimization. This often leads to that the regular grid algorithms are faster than TIN based. In the remaining sections we will only focus on regular grid based terrain algorithms. Chapter 6: Graphics engine 39

50 Terrain cracks Many of the presented regular grid terrain algorithms divide the terrain into blocks and each block has a discrete number of LODlevels[32][8]. The first level in the terrain block is in full resolution and the remaining levels reduces the resolution in discrete steps. When two adjacent terrain blocks have different LOD-levels a T- junction will occur, which can lead to cracks in the terrain. A T- junction is a vertex positioned on the edge of a triangle. If the vertex does not have the same height as the triangle, a crack may be visible. Due to precision errors even if the vertex has the same height as the triangle a small crack typically a few pixels wide can be visible. Figure 19: a) T-junction. b) T-junction which is responsible for the terrain crack. 40 Chapter 6: Graphics engine

51 To eliminate these cracks there are different kind of approaches that can be used. One approach is to remove the T-junctions because this will obviously remove any cracks. This is used by De Boer[8] to split the edge triangles in the terrain block based on the LOD-level of adjacent terrain blocks. Another approach discussed by Ulrich[46] is to fill the crack with an extra set of triangles. This method tends to be very complicated because it is not easy to get the extra triangles to match the terrain correctly. Instead an easier solution where a set of vertical skirts are rendered to hide the cracks is used by Ulrich[46]. Figure 20: a) Cracks removed by eliminate T-junctions. b) Cracks hidden with vertical skirts. Terrain popping Terrain algorithms that use terrain block with discrete LOD-levels need to control when the LOD-levels are changed. This can be based on the distance between the terrain block and the viewer, so a terrain block is rendered with a greater resolution when the viewer approach a certain terrain block. This will introduce a phenomenon called popping which is a noticeable change in the shape of the terrain block when the block switches from one LOD-level to another. Chapter 6: Graphics engine 41

52 To minimize the visible poppings, Lindstrom[32] introduced another criterion when the LOD-levels should change which is based on the projected screen space error. The maximum height distance the triangles in the terrain block will move when changing from one LOD-level to another is calculated and compared to a threshold value, usually 2 or 3 pixels. If this max distance is lower then the threshold the LOD-level is changed otherwise not. This basic concept will reduce the visible poppings significantly but not completely. Figure 21: The δ-distance is projected into screen space and used as error metric. To eliminate poppings completely a morphing between LODlevels can be introduced. This has been implemented successfully in software by Hoppe[22] and in hardware, when the programmable graphics hardware was released, by Larsen[29], Wagner[50] and Vlietinck[49]. The terrain algorithm presented in this thesis uses a morphing technique that is calculated on the graphics hardware and is described in section Terrain morphing. 42 Chapter 6: Graphics engine

53 6.3.2 Algorithm background The algorithms from Duchaineau[11], Lindstrom[32] and Hoppe[22] were developed when the graphics hardware was far from what it is today. Graphics hardware with a GPU and support for programmable shaders was just a dream and the number of triangles these graphics cards could rendered per second is ridiculous low compared with today s graphics hardware. Therefore these algorithms had to minimize, very accurate, the number of triangles sent to the graphics hardware and all this had to be calculated on the CPU which killed the performance. Today it is a different story, the graphics hardware is capable of render many millions of triangles per second so the set of triangles sent to the graphics hardware does not have to be perfectly minimized. More important is to keep the graphics hardware busy and do as much of the calculation on the GPU so the CPU can focus on other important tasks such as AI, physics and networking. This new type of hardware made it possible to develop simple but extremely fast algorithms, e.g. Hoppe[23], Larsen[29], Wagner[50]. In the future when the graphics hardware get even more advanced it is likely that a combination of the old and new algorithms can be developed and executed entirely on the GPU with impressive quality and performance. The terrain algorithm presented in this thesis is based on many of the new algorithms but the concepts have been simplified and tweaked to achieve as good performance as possible Chapter 6: Graphics engine 43

54 6.3.3 Algorithm outline The algorithm we have developed is a regular grid based approach where the terrain is divided into terrain blocks in a similar way as De Boer[8]. Each block has a fixed number of LOD-levels and the LODlevel is calculated based on the distance from the viewer to the block. The performance of the algorithm is maximized by minimizing the CPU usage, terrain cracks and poppings are removed by using continuous morphing calculated in a vertex shader. The algorithm is a two step process with a preprocessing step and a rendering step. The preprocessing step prepares the terrain data and organizes the terrain blocks in a quad-tree to achieve efficient rendering. In the rendering step the terrain is culled with the view frustum and rendered with morphing calculated with a vertex shader. The different parts of the preprocessing and rendering step will be discussed in detail in the following sections Terrain storage Because the algorithm operates on static terrain datasets and the geomorphing and crack elimination is calculated on the GPU, the CPU does not need to have access to the terrain vertices. The terrain vertices can therefore be placed in fast graphics memory. The drawback is that most graphics hardware today is shipped with only 128MB or 256Mb onboard memory so this memory can not hold extremely large height fields. A solution to this problem would be to divide the terrain and load the pieces from disk when they are needed. This solution will reduce the performance because manage large datasets from disk is very costly. A better solution is to realize that the prototype does not need these extremely large terrains. A height field with 1024x1024 height values can represent a 50km by 50km large terrain with a descent resolution and this is more than the prototype needs. This height field will use approximately MB of storage space depending on the vertex size and can therefore be place in the fast graphics memory. 44 Chapter 6: Graphics engine

55 6.3.5 Triangle reduction To reduce the number of triangles rendered in every frame the algorithm uses two different techniques: view-frustum culling and a LOD system. View frustum culling View frustum culling is performed to remove large parts of the terrain that is not inside the view-frustum and hence not visible. For this kind of culling a quad-tree is perfect. Each node in the tree has a bounding box which contains a physical part of the terrain including the nodes sub-tree. The algorithm can cull large parts of the terrain very fast because if a node s bounding box is not inside the viewfrustum neither will any of the nodes children and the entire branch in the quad-tree does not need to be rendered. The quad-tree is built in the preprocessing step and used in the rendering step. Level of details The LOD system is based on a fixed number of discrete LOD-levels for every terrain block where each level reduces the number of polygons by a factor of four. To optimize this reduction for the GPU each LOD-level has a set of triangle indices that specifies which vertices in the terrain block that should be used in the rendering process. To eliminate the need for a unique set of indices for every terrain block each terrain block has a vertex offset into the terrain dataset stored in graphics memory. This reduces the number of set of triangle indices from m*n, where m is the number of terrain blocks and n is the number of LOD-levels, to n. Figure 22: a) Terrain block in LOD-level 1, 128 triangles. b) Terrain block in LOD-level 2, 32 triangles. c) Terrain block in LOD-level 3, 8 triangles. Chapter 6: Graphics engine 45

56 The algorithm uses the standard error metric where the distance from the viewer to the terrain block specifies which LOD-level each terrain block should be rendered with. Screen space projection error metrics[32] is not feasible because the algorithm uses a crackelimination morphing that demands that adjacent terrain blocks have a maximum LOD-level difference of one. Figure 23 demonstrates an example of the LOD algorithm with three LOD-levels. Terrain blocks further away than d 2 will always be rendered with LOD-level 3. When the distance to the block is equal to d 2 the block will switch and rendered with LOD-level 2 and when the distance is equal to d 1 the block changes to LOD-level 1. To eliminate terrain cracks and poppings the algorithms morphs between the different LOD-levels in the geomorph regions. This is discussed in section Terrain morphing. Figure 23: LOD-system with three LOD-levels. 46 Chapter 6: Graphics engine

57 The two triangle reduction systems combined In the rendering step the terrain is rendered by a traversing of the quad-tree to find which terrain blocks that are visible. If a terrain block is visible the LOD-level is calculated based on the distance to the viewer and the block is rendered using the triangle indices and the vertex offset into the terrain dataset. Figure 24: Example of the triangle reduction technique with three LOD-levels and a 90 degree field-of-view. Chapter 6: Graphics engine 47

58 6.3.6 Terrain morphing To eliminate popping and cracks in the terrain when the LOD-level changes the algorithm uses a continuous geomorphing technique. The geomorph technique will not remove T-junctions so cracks due to precision errors can occur. The algorithm has gone through extensive testing and the precision error cracks are almost impossible to notice so this is a problem the algorithm ignores to get as good performance as possible. This approach to ignore the T-junctions was used by Youbing[53] with good results. The geomorphing technique morphs the height of each individual vertex between the vertex height of the current LOD-level and the previous one used. The height of the adjacent LOD-level (h LOD ) has to be calculated for every vertex and stored in the vertex dataset so the GPU can access it. Figure 25: Calculation of h LOD is done with the formula: 0.5(h 1 + h 2 ). The morphing is based on the distance from the viewer to the vertex so the morphing will only occur when the viewer moves (vertex distance changes) because this makes the morphing harder to notice. To make the morphing even harder to notice the morphing is limited to be performed in a small geomorph region in the LOD-level area because this forces the morphing to take place far from the viewer and not up front. Figure 23 demonstrates the geomorph regions. 48 Chapter 6: Graphics engine

59 The morphing is calculated in a vertex shader with the following formula where lerp is a linear interpolation and clamp forces the interpolation variable to be between 0.0 and 1.0. See the HLSL reference[21] for more details. Chapter 6: Graphics engine 49

60 6.3.7 Terrain texturing To texture the terrain the algorithm uses a simple layer system, which is very similar to the texture splatting technique presented by Bloom[4]. Each texture is wrapped and has an alpha map that has the same size as the terrain. The alpha map specifies where the texture should be rendered. This means that the artist can paint the terrain with different textures to create the illusion of e.g. grass, sand and mountains. To minimize the number of render passes, multi-texture capability of the graphics hardware is used to render more than one texture layer in every pass. To minimize the rendering passes even further the algorithms calculates, in the preprocessing step, which texture layers being visible in which terrain blocks. If a terrain block only uses one texture it is a waste of render passes to render all the invisible texture layers. Figure 26: Two terrain layers are combined. 50 Chapter 6: Graphics engine

61 6.3.8 Performance To test the performance of the terrain algorithm an AMD Athlon with 512MB RAM and a Nvidia Geforce FX 5900 was used. Terrain block size To find the optimal terrain block size the algorithm was tested with the same terrain data and only changed the block size. The terrain data was a 512x512 height field with a single texture layer and the frame per second is calculated as an average. The test gave the following results: Block size Frames per second Triangles per frame 8x x x x x Table 2: Results of terrain block size test. The result demonstrates the importance with today s graphics hardware to have a good CPU/GPU ratio. With a small block size the CPU dominates the GPU because the CPU has to handle and cull a huge amount of terrain blocks and each block contain a too small batch of triangles that is sent to the GPU. This causes the GPU to idle between the render calls. With a large block size the GPU dominates the CPU because the quad-tree will contain a small amount of terrain blocks so the viewfrustum culling will be very inefficient and instead flood the GPU with too many triangles that are invisible. The perfect balance between CPU and GPU seems to be with a block size of 32x32 where the quad-tree can cull a large part of the terrain and the GPU will be kept busy between the render calls. Chapter 6: Graphics engine 51

62 Terrain size To test the performance of terrain algorithm with different terrain sizes the algorithm was executed with a terrain block size of 32x32 and only the resolution of the terrain was changed. The terrain is textured with a single layer and the frames per second is calculated as an average. The test gave the following results: Terrain size Frames per second 256x x x Table 3: Results of terrain size test. Triangles per frame The result shows that the triangle reduction system in the algorithm is doing a good job. Even if the terrain size is increased by a factor of four the number of triangles rendered each frame is just doubled. Adding more LOD-levels than three would decrease the number of triangles rendered even more especially for the 1024x1024 terrain. 52 Chapter 6: Graphics engine

63 Terrain layers To test the performance of terrain algorithm with different number of texture layers the algorithm was executed with the same terrain dataset and only the number of layers was changed. The terrain block size is 32x32 and the terrain size is 512x512. The test gave the following results: Terrain layers The Nvidia Geforce FX 5900 is capable to render four texture layers in each rendering pass and this is indicated by the results because there is no significant performance loss when the texture layers are increased up to four. The performance when the terrain is rendered with 8 or 16 layer is very dependent on how the layers are positioned because layers that are not visible in a certain terrain block will not be rendered. A terrain with 16 texture layers with graphics hardware capable to render four layers in each pass will not automatically need to render the terrain four times Conclusion Frames per second Table 4: Results of terrain layers test. The goal was to implement a terrain algorithm that was fast and well suited for the prototype needs. This was achieved by restricting the terrain to a certain maximum size and use the graphics hardware at its maximum. The layering technique gives the artist the opportunity to create terrains that are very detailed. Chapter 6: Graphics engine 53

64 6.4 Water In this section the technique used in the graphics engine to render water objects is discussed where a local reflections texture is created and ripples are simulated in a pixel shader Introduction In the past real-time application such as games used to visualize water by hand painted water textures and some kind of clever texture transformations to simulate wave and ripples. This all changed when the programmable graphics hardware where introduced which gave the game developers freedom to implement very realistic water effects. FarCry[13] released in 2004 is an example of a game that has very impressive water effects. Real-time water effects are usually a two step process. The first step is a representation of wave and water motion. The second step is a visualization step with reflection/refraction of the surrounding environment. Wave model Depending on what kind of water that should be simulated the wave model is quite different. Ocean water usually has rolling waves and lake water has small waves and ripples. The ocean wave model has been successfully been implemented in the past both for non-programmable graphics hardware Hisinger[20], Jensen[26] and for the programmable graphics hardware Isidoro[25], Johanson[27]. The prototype will only support lake water because the small waves and ripples can be simulated as a visual effect instead of physical change in the wave model. This will simplify the implementation and maximize performance[48][42]. 54 Chapter 6: Graphics engine

65 Visualization A simple way to represent reflection is to use environment mapping. The static environment is represented about a single point as a cubemap which is a 3D texture. The big drawback is that the environment has to be far away from the water to not cause visual errors so the cube map approach can basically only represent reflection of the sky. A better way that enables local reflection of the environment is the planar water surface approach[48][42]. The water reflection/ refraction is simplified by using a water plane, which tries to approximate the wave model with a flat surface. The environment above the water plane is rendered into a reflection texture and the environment below is rendered into a refraction texture. The two textures are then combined and applied to the water geometry representing the wave model. Figure 27: Water plane approximation of wave model. Chapter 6: Graphics engine 55

66 The relationship between reflection and refraction is called the Fresnel effect, which tells how much light is reflected in the boundaries between two materials. If the incoming angle of the light ray is greater than the critical angle (see Snell s law[51]) we get total reflection. Further details about the Fresnel reflection technique and how to simplify so it can be calculated in real-time on the GPU, see Wloka[52], Brennan[5]. Figure 28: a) α 1 is less then the critical angle and reflection and refraction will be combined. b) α 2 is greater then the critical angle and there will be total reflection Algorithm outline The water algorithm needs to be extremely fast so it does not kill the performance for the rest of the prototype. This is accomplished by creating an algorithm that produces good looking lake water with very simple calculations. The algorithm is based on Vlachos[48] and Pelzer[42] but optimized to take advantage of the fact that the cyclists are following a certain path. The water objects can be located in such a way that the camera never comes close to the water object or look straight down into the water. The wave model can be simplified to a visual effect simulating waves and ripples calculated on a per-pixel basis in a pixel shader. At long distances there are no noticeable difference with a real wave model that physically changes the waves. Refraction is also hardly noticeable because the long distance to the water from the cyclist will almost always produce total reflection in the water due to the viewing angle. 56 Chapter 6: Graphics engine

67 These two simplifications reduces Vlachos[48] and Pelzer[42] algorithms from a three or four pass rendering technique with complex Fresnel per-pixel calculation to a simple two pass rendering technique with almost local reflection and per-pixel waves and ripples First pass In the first pass the scene is rendered with a mirrored camera about the reflection plane to a reflection texture. Because the mirrored camera will be located under the reflection plane all geometry under this plane has to be removed otherwise it may be rendered into the reflection texture and cause unwanted visual artifacts. Figure 29: Rendering of the reflection texture using a mirrored camera and a clip plane. One popular technique to remove geometry is to use a clip plane which is basically a plane where all geometry is removed on one side of the plane. This is however only supported by newer graphics hardware so the graphics engine uses a method developed by Eric Lengyel[30]. Chapter 6: Graphics engine 57

68 This method is called Oblique frustum culling and maps the near plane of the view frustum onto an arbitrary user-defined clip plane. Because this culling method is based on basic frustum culling it is supported by all graphics hardware Second pass In the second pass the reflection texture created in the previous pass is applied to the flat water triangle geometry. Because the reflection texture is view dependent it can not be applied to the water geometry using a standard planar texture mapping. Instead projective texture mapping has to be used. Projective texture mapping projects the texture onto the water geometry by calculating texture coordinates based on the view and projection [12]. To calculate the texture coordinate for a certain vertex in the water geometry the vertex position is transformed into clip space using view M v and projection matrix M p. Then map the coordinate in clip space, where the coordinates are in the range -1 to 1, to texture space, where the coordinates are in the range 0 to 1. The clip space to texture space transform matrix will look like this: The complete texture projection matrix will be calculated with the following formula. 58 Chapter 6: Graphics engine

69 To create ripples a simple pixel shader is created where a bump map is used, which is applied in two layers with different scaling and translations. The bump map represents displacement vectors added to the texture coordinate calculated in the previous step. This will give us a slightly distorted texture lookup of the local reflections texture, which will simulate water ripples[42]. Figure 30: a) Bump map representing displacement vectors. b) Two bump layers with different translation. Chapter 6: Graphics engine 59

70 6.4.5 Performance To test the performance of the water algorithm we have used an AMD Athlon with 512MB RAM and an Nvidia Geforce FX The algorithm was tested with different kind of environments and the frames per second is calculated as an average. The test gave the following results: Geometry Water + Terrain 215 Water + Terrain + Trees + Road 143 The results demonstrates that the water algorithm is very dependent on how fast the surrounding environment is rendered into the reflection texture. Even if the triangle count increases in the environment the water algorithm is still pretty fast Conclusion Frames per second Table 5: Results of water performance test. The goal was to create a simple water effect that is rendered very fast. This was achieved by simplifying and optimizing a planar water reflection algorithm based on the prototype restrictions. Even if the algorithm presents realistic water effects there can be some improvement, e.g. a simple fresnel effect should be calculated in the pixel shader to simulate the sun light reflecting more realistic in the water. 60 Chapter 6: Graphics engine

71 7 Network engine This chapter will describe the parts of computer networks relevant to this project as well as the network engine. This involves the design of the network engine, latency and latency handling. To get an understanding for the basics of computer networks, refer to section C - Introduction to computer networks. 7.1 Network engine design The network engine used in the prototype has been created by using RakNet, a networking API developed by Rakkarsoft LLC with a focus on online gaming. RakNet was chosen due to its large amount of features, this opening up the possibilities to develop the prototype further after the exam project was completed. Another advantage RakNet has is the homepage, very thorough including tutorial, plenty of example code and forums frequented by many users including the author himself. One of the competitors was DirectPlay by Microsoft but since it is no longer developed it may be obsolete shortly [43][9]. RakNet uses UDP packets with the main reason being speed and, as they put it on the homepage, No games worth mentioning use TCP. To compensate for the drawbacks UDP has compared to TCP, security, sequence numbering and other problems are handled at a layer just above the UDP packets [43]. For more information on how TCP and UDP works, the reader is referred to section C.3 - UDP and TCP. Chapter 7: Network engine 61

72 For this prototype the client / server architecture is used, where the server acts as a hub and receives information from single clients. This information is then examined and if the packet s destination is other clients, the information is registered and then broadcasted. Since majority of traffic during game play are update packets from clients, the majority of packets are sent to the server and broadcasted from there. If the packet s destination is the server itself, the relevant information is kept and the packet dropped. With a total number of 32 players being able to participate in the game at a time, peer to peer is not viable considering that the player s data needs to be continuously updated, generating vast amounts of traffic. Client Client Client packet Server Client Client Client Figure 31: Client / Server architecture. 62 Chapter 7: Network engine

73 Peer Peer packet Peer Peer Peer Peer Figure 32: Peer-to-peer architecture. In single player mode the game runs without using the network engine, but in multiplayer mode the network engine is active, sending data to and receiving data from the game. All data that is generated and sent from game to engine is always forwarded to the server. Not all data received from the engine comes from the server, instead it can be generated by the network engine itself. This occurs when an update packet from that opponent is not received on time, through dead reckoning the network engine will approximate an opponent s behavior. This way the game does not have to bother checking received data; instead the network engine is like a black box to the game. Input and output is not checked but received and sent as is [28]. Game Network Engine Network Figure 33: To the game, the network part is like a black box. Chapter 7: Network engine 63

74 7.1.1 Server The server in this game serves as a collector / distributor of data, controls it and for most packages, broadcasts it to all other clients. Just like a hub, all clients are connected to the server, only aware of other clients if the server says there are other clients [28]. The server keeps track of all connected clients in server game state for each client. This game state is sent from the client shortly after a connection between client and server has been established. Before each race a packet, containing starting time and track number, is broadcasted to all clients except the client that sent the packet. For each client connecting and wishing to partake in the race, a new contender packet is broadcasted and added to the local contender list at each client. After the race, the results are summarized by the server and broadcasted Client After connection to the server is established, the client sends a packet containing data about its player such as mass, vertical frontal area (for wind resistance) and other things. If the prototype is to be developed further, variables can be added to get an even more realistic game [28]. The most important package in this games networking system, and many other online games, is the update package. It is sent repeatedly during the game, refreshing the data for its character in the game, in this case a cyclist. The package includes data such as sender identity, velocity, position etc. These are used for updating the players position at every client and also for dead reckoning if some update packets would be lost. Only the most important data are allowed in the update package though, this is to avoid overloading the network and minimizing latency, described in the following section. 64 Chapter 7: Network engine

75 7.2 Latency A significant part of the traffic on the Internet today is generated by network gaming, therefore it should be quite safe to say that the market potential is high even to this day. Just a look at the number of commercial games with support for online gaming on the store shelves these days confirms this fact. Almost all game consoles on the market today have network support [16]. One of the main problems with networked games is caused by network transmission delays, also known as latency, and refers to the time between the generation of an event and the resulting update. Latency is a result of many factors, some which can be remedied by certain methods of implementation. Other factors just have to be accepted as is and focus is set on trying to minimize the consequences of the latency instead [40][41]. Screen Playe r A A Screen Player B A B B ds = v * t latency ds = v * t latency Delay-induced inconsistency. Two racers are going head-to-head while passing the finishing line. Due to latency, it takes awhile before data arrives to the local machine, therefore, the position of the opponent is out-of-date and somewhat behind. This leads to both players believing they are the winner of the race. The local client has no better information and will declare their local player as the winner. Figure 34: Consequences of delay-induced consistency Chapter 7: Network engine 65

76 7.2.1 Latency sensitivity Just because latency is one of the largest problems does not mean that all games suffer from having it. Some games are just not sensitive to latency due to the fact that the game does not require high-speed transmission. Among the reasons for this is the game itself, e.g. online chess, or any other turn based game, where time for thinking is a natural part of the game, this fact is not affected by the game being played online. The opposite of mentioned games are first person shooters (FPS), fast paced and large amounts of data needed to be transmitted back and forth. Here a small mistake can lead to high risks in the game such as looking in the wrong direction when rounding a corner and another player is standing there with his weapon pointed in your direction. These games are truly latency sensitive, the players performance affected by it and therefore the gaming experience itself as well. Staying with the FPS games, another aspect is the player and how aware of the latency he or she really is. Studies show that players, or gamers as many of them prefer to call themselves, are more delaysensitive when choosing a server than once they are connected and playing the game. The longer a player remains in the game, the more they might be enjoying the game and hence the less they would want to leave, even in the event of additional network delay. Furthermore, players are willing to tolerate higher levels of delay than the human factors literature indicates. The individual player vary as well, some claiming to have no problems with ping times other players find intolerable. Actual figures have been recorded in different studies but because of the fast evolving gaming industry, these figures are somewhat obsolete [38][19] Reducing latency One of the key factors to reducing latency is to choose the appropriate protocol for sending data, UDP and TCP being the two main alternatives. TCP is evil. Don t use TCP for a game Lincroft[31] puts it bluntly. With so many features for delivery acknowledgements, congestion control and more, the negatives 66 Chapter 7: Network engine

77 cause more trouble than the positives are worth, probably what made Lincroft make that harsh statement. Packet size is another important matter; Less is more. The more information that has to be shared, the bigger the packet will be. This will increase the workload on whatever capacity the Internet connection the computer is connected with. An example of this would be a car racing game where speed, velocity and direction are some essential data that needs to be included in the update packet. Color, number of seats and fragrance of air freshener are data that typically do not affect the race and would only increase traffic on the network for no use, therefore these data should not be included in the update packet [38]. Yet another method for reducing latency worth mentioning involves the ever growing Massive Multi Player Online Role Playing Games (MMPORPG). Here the worlds are huge and the amount of players online at a time can be overwhelming, just as the amount of data needed to be sent from and to every client. Since the clients basically only need to know what is happening in their near vicinity in the game, the world is separated to several parts, placing different parts of the game world on different servers, that way the client only gets data traffic involving the part of the game world it is currently occupying [38][14]. Of course, a powerful computer and a fast Internet connection affect the speed but do not really have anything to do with the mathematical theory behind latency reduction and this will not be discussed further Minimizing consequences of latency The fundamental requirement of many multiplayer games is to provide a shared experience that appears consistent across all the players. Since latency is a natural part of online gaming, several methods for handling it has been developed the most common one being Dead Reckoning, once developed to be used in military simulators [15]. By using derivatives of earlier motion or derivatives of earlier information provided by the object itself, i.e. another player, the dead reckoning system calculates the position of an object locally Chapter 7: Network engine 67

78 without needing to wait for the late arrival of the actual information. A concrete example of this would be when the update packets include velocity, acceleration and position. Using these figures the velocity and position in the very near future can be approximated. The calculations are performed at every client. Dead reckoning schemes come in different complexities where the most complex schemes not always lead to the best result. Different schemes are adjusted to fit different types of games e.g. sports games, simulator and racing games, action games etc [41]. A vehicle-like movement model in particular is of advantage for a prediction, due to the object's continuous and smooth manner. At least in racing games the direction seldom diverges much from the direction of the track and the velocity seldom changes drastically unless e.g. a crash occurs. Other methods of masking the latency are buffering and time distortion[38]. In buffering, all clients are synchronized according to the same clock. Instead of processing local data immediately an artificial delay, similar to the latency that remote clients will experience when receiving the event, is added. This all works out as long as the artificial delay does not reduce the perceived responsiveness of the user interface. Time distortion techniques exploit the notion of time, either by expansion or contraction as is deemed necessary. An example of this is a 2D ping-pong game involving two users. One of the possible solutions is to render the ball in real-time according to the user about to interact with it, while simulating it with a certain delay for the other user. The ping-pong example works due to the constraints that limit the movements to just two dimensions. In more advanced games such as FPS s, simulation games and similar types of games it is not feasible to constrain the user in similar fashion. Further solutions to reduce the perception of latency are the methods called decoupling, transparency, motion blur and defocusing. Decoupling makes the system multi-threaded with certain threads assigned to tasks most in need of low latency. Transparency, motion blur and defocusing are methods that use visual effects to mask latency. More about these methods can be found in [7]. 68 Chapter 7: Network engine

79 7.3 Latency handling in the game RakNet, mentioned in section Network engine design, was used in the network engine design, this led to the first step in reducing latency since RakNet uses UDP, see section Reducing latency. Since the game in this prototype does not have steering or braking implemented and movement is linear along the track, this is a perfect fit for dead reckoning. The scheme is kept simple but is still very accurate due to the small numbers of variables needing to be considered when making the prediction. Another contributing factor for the accuracy is the nature of this game, a bicycle simulator where velocities are relatively low and rapid changes of velocity are unlikely. Buffering and time distortion mentioned in section Minimizing consequences of latency were considered and tested theoretically but discarded as they were more complicated to implement without adding any extra functionality. As mentioned in previous sections, velocity, acceleration and position are used to approximate near future figures of the cyclist, below illustrated at the times t 0 and t 1. At time t 0 the last update was received. When an expected update packet does not arrive at time t 1 the client uses dead reckoning to approximate velocity and position using physics formulas. Figure 35: Approximated position and velocity. Chapter 7: Network engine 69

80 7.4 Conclusion The network engine in the prototype was created by using the RakNet API, with a client / server architecture. Latency is one of the main problems with networked games and is caused by network transmission delays. To minimize the consequences of latency in the game a technique called dead reckoning was implemented, approximating the behavior of a cyclist by using latest known data. 70 Chapter 7: Network engine

81 8 Physics engine This chapter will describe the physics engine which is used in the prototype to control the motion of the virtual cyclists. The motion of the cyclists is based on the force applied by the exercise bike and the environment, such as gravity, air resistance and rolling resistance force. 8.1 Introduction Realistic physics have more and more become an important part of computer games, especially in racing games. Many of these games use one of the commercial physics engines available, e.g. Havok[18] or Meqon[34]. These physics engines are very complex and have support for basically three different kind of physics simulations: Character Dynamics The characters in a game is able to interact realistically with each other and the environment. Vehicle Dynamics The vehicles in a game behaves realistically and interact with the environment. Environmental Dynamics The environment in a game can be fully dynamic and reacts with e.g. characters, vehicles, explosions, etc. The physics simulation in the prototype does not have to be as advanced as described above and can be simplified to only control the motion of the virtual cyclist. This motion control system can be separated into three different tasks: Automatic path Since steering of the cyclist in the game is not implemented in this version of the prototype, the cycling game will instead guide the cyclists along a predefined path. This path is defined in the editor when the map is created. Chapter 8: Physics engine 71

82 External forces External forces can be applied to the cyclist and affect the cyclist s movement in different ways, e.g. increasing or decreasing the speed. The external forces can either be environment based such as gravity, air resistance and rolling resistance, or based on user interaction performed by the exercise bicycle through the pedals. Because the cyclist always will follow a predefined path this simplifies how the forces can be applied to the cyclists since motion basically takes place in only one dimension. Collision detection Collision detection will be calculated both between individual cyclists and between cyclist and static game objects. To avoid collisions the physics engine will guide the cyclists past the obstacle in an intuitive way, as well as adapting to situations such as the opponents overtaking each other. 72 Chapter 8: Physics engine

83 8.2 Design The physics engine will perform a physics simulation every frame in the game loop. The simulation will update acceleration, velocity and position for the virtual cyclist continuously during the game. The three tasks discussed in section Introduction, are designed to be performed separately and does not depend on each other Automatic path The virtual cyclists will follow a predefined path so the user does not need to worry about steering. The path is built in the editor and is based on control points defining a parametric curve. To create a realistic movement of the cyclist the artist has to create a path that does not have very sharp hairpin bends. A map can contain many paths and the user can choose which path to use in the race. Figure 36: Cyclists following a predefined path. Chapter 8: Physics engine 73

84 8.2.2 External forces To move the cyclist a force has to be applied to it and the net force will give acceleration along the predefined path. The acceleration is calculated using the Newton s second law of motion on rigid bodies where F is the applied force and m is the mass of the body [35]. The physics engine has four different kinds of forces that can be applied to the cyclists: Exercise bike force, Gravity force, Air resistance force and rolling resistance force. Exercise bike force The force the exercise bicycle applies to the cyclist in the game is very simple and is direct proportional to the pedal speed. This is not a very accurate model and has to be improved if the prototype should be developed into a real product. Figure 37: The pedal speed from the exercise bike is direct proportional to the applied force on the cyclists. 74 Chapter 8: Physics engine

85 Gravity force The gravity force acts as a force that pulls the cyclist towards the centre of the earth. This is simplified in the physics engine as force acting straight down, perpendicular to the horizontal surface. This force is separated into its components along the path and only the force component parallel to the path is applied to the cyclist. When the cyclist rides uphill a force opposite the riding direction will be applied, which in turn increases the pedalling resistance on the exercise bike. In the same way, during downhill slope gravity force will pull the cyclist downwards and that way increasing the rider s forward force, decreasing the pedalling resistance on the exercise bike. Figure 38: a) The gravity force parallel to the path pulls the cyclist backwards. b) The gravity force parallel to the path pulls the cyclist forwards. Chapter 8: Physics engine 75

86 Air resistance force Air resistance is a counter force caused by wind drag when the cyclist moves through air and is proportional to the cyclists speed v, cyclist frontal area A, drag coefficient C Drag and air density D Air.[2]. Figure 39: Air resistance force the cyclists has to overcome to move forward. Rolling resistance force Rolling resistance is a force which acts as a counter force based on the rolling resistance on the wheels. The rolling resistance is proportional to the gravity force F G perpendicular to the cyclist path and the rolling coefficient of the wheels C Roll [2]. Figure 40: Rolling resistance force the cyclist has to overcome to move forward. 76 Chapter 8: Physics engine

87 8.2.3 Collision detection Collision detection is performed to check for collision between cyclists or cyclists and static game objects. Cyclists The physics engine will check for collisions between cyclists. If two cyclists are on a collision course the physics engine will guide one of the cyclists so it can pass by changing the predefined path. Usually this situation only occurs when a faster cyclist, A, is approaching a slower cyclist, B, from behind. A will in that case be steered into an alternative path by the physics engine, overtaking B. After A has passed B he is steered back to the original path. Figure 41: Cyclist A overtakes cyclist B. Chapter 8: Physics engine 77

88 Static game objects The predefined path the cyclist follows might not match the contour of the terrain so to prevent the cyclist from riding through the terrain, collision detection is performed. The collision detection calculates the predicted position of the cyclists and if there is a collision the cyclists will follow the height of the terrain instead of the height of the predefined path. Figure 42: The cyclists follows the contour of the terrain instead of the predefined path. 8.3 Conclusion The physics engine is very simple and has to be improved significantly to create realistic movement of the cyclists. The force applied by the exercise bike on the cyclist uses a model that is far from realistic and has to be improved. This was something that we did not have the time to do because the limited time this project had. A wind resistance force should be added so the cyclists will be able to slip stream each other to reduce the physical resistance on the exercise bike. 78 Chapter 8: Physics engine

89 9 Results and future work This chapter will summarize the results of this project. Future improvements and possibilities for the prototype will also be discussed. 9.1 Results The end result was satisfactory for both employer and us, the students working with this project as exam work. The requirements list in appendix D - List of requirements, states all requirements, that were set agreement with our employer. The requirements had varying levels of difficulty, some were quite easily fulfilled while other needed a bit of work to accomplish. Among the easy ones were requirements such as the data communication should go through a USB cable, the game should run on computers from no earlier than year 2000 etc. Other requirements such as constructing a map editor, getting the game to control the physical resistance on the exercise bike etc needed a bit more work and research to make them function properly. For a complete list of requirements and how they were handled, see appendix E - Requirements handling. Training with the exercise bike is now much more stimulating compared to just pedalling to the LCD display without any feedback other than blinking columns. The pedalling resistance is realistic to a point. Some tweaking could be done to make it even more real life like, that is however a matter of how the individual experience a hill. Other factors play along here as well e.g. the individuals preferred cadence, habits, training etc. Chapter 9: Results and future work 79

90 9.2 Future The end result of this project is just a prototype and to produce a viable commercial product some further development is required Prototype improvements The main goal of the project was to create a functional training simulator therefore there are areas in the prototype that need improvements. Graphics The graphics quality in the cycling game has to be further developed to match the quality of today s computer games. Exercise bike communication The connection between the bike and computer is very experimental and has to be replace by a connection that is integrated with the exercise bike. Network The multi player mode has to be thoroughly tested with the maximum allowed number of players to ensure that the client / server is capable of handling this kind of workload. Physics The physics model is very simple and has to be tested and tweaked to improve the realism. Cheating To prevent cheating the prototype should implement a few countermeasures against client hacks and exercise bike modifications. Testing To ensure a stable commercial product the prototype has to go through a test phase to find annoying bugs that could ruin the success of the product. 80 Chapter 9: Results and future work

91 9.2.2 Prototype extension ideas There are several features that could be added to the prototype to further increase the gaming experience, each of them contributing to making a more commercially attractive product. Team races Racing with teams would add a social factor in the game and create a group feeling. Steering Adding steering increases the interaction in the game. With the steering a rider would be able to practice the art of drafting as well as using tactics, making use of an opponent to conserve energy before the last spurt. Gears The possibility for switching gears would enable the rider to choose gears as he or she finds appropriate e.g. heavier gear when going down a hill to increase speed or lighter gear when going upwards. This would add realism to the riding. Collisions Combined with the steering, this would give the rider bigger responsibilities, forcing him or her to actively avoid colliding with other cyclists and objects. Drafting practice would become even more realistic now with this feature. Brakes To avoid the collisions mentioned above the rider should be able to use a brake in the game to decrease the velocity of the virtual cyclist. Chapter 9: Results and future work 81

92 Trainer A trainer is a construction on which a bicycle is mounted, rear tire connecting to a roll with adjustable resistance. With the stationary exercise bike replaced by a trainer and ordinary bicycle, several advantages are gained: The final product would be cheaper since the user would probably already own a bicycle needed to form the whole system. The rider would have exactly the same riding position when training with the product as when out riding on the roads. Even if the trainer was not made collapsible (some are, others not), it would take up much less space compared to a stationary exercise bike. With access to a geared bicycle, the resistance would be constant but the rider would be able to choose which gear to use at different situations. Other exercise equipment The concept can be extended to other types of training equipment such as: Rowing machines Stepper / Climbers Elliptical trainers Treadmills Skiers 9.3 Conclusion This project has been interesting and varied, covering many areas. The vision has possibilities and can be extend to many different types of exercise equipments to appeal to a broader public. 82 Chapter 9: Results and future work

93 10 Glossary API - Application Programming Interface. Client - Connected to a server. All data to and from the client passes through the server. Collision detection - Checks for collisions between game objects. Congestion control - Mechanism to reduce traffic and in that way latency as well when too much data is sent on the network and causes congestion. CPU - Central processing unit Delay - See Latency. Drafting riding in the closely behind another cyclist, using the turbulence the other cyclist creates to get less wind resistance and that way save energy. Flywheel wheel on the exercise, heavy to simulate the feeling of a real bicycle. FPS First Person Shooter GPU - Graphics processing unit Graphics engine - Software package controlling all graphics related tasks in the prototype. Internet - A global network consisting of millions of computers. Often referred to as "the Internet". IP - Internet protocol. Latency - The time passed between sending a data packet and arrival at the destination. Also known as delay. LOD -- Level of detail. Used in computer graphics as an optimization technique. MMORPG Massive Multiplayer Online Role Playing Game Multi player game mode with several live participants. Network engine - Software package controlling all networks related tasks in the prototype. Chapter 10: Glossary 83

94 Packet, package used interchangeably Pedal speed, rpm used interchangeably Physics engine - Software package controlling all physics related tasks in the prototype. Prototype the entity consisting of exercise bike, computer, software, USB connection Router - A device used in computer networks. Has several network cables connected to it and routes data packets according to algorithms and routing tables. Server - Has clients connected to it, often several. Acts as a hub for all clients, all data passes through here. Single player Game mode with one single participant. TCP - Transmission Control Protocol, a protocol for data transfer over networks. The probability of correct data transfer is higher but at the cost of speed. Trainer A construction on which a bicycle is mounted, rear tire connecting to a roll with adjustable resistance. Construction and bicycle make a stationary exercise bike. UDP - User Datagram Protocol, a protocol for data transfer over networks. Called unreliable protocol but can be prevented through different methods. Faster than TCP. User, rider, cyclist, biker, player - All used interchangeably Wheel part of the motor, controls the distance between magnets and flywheel. 84 Chapter 10: Glossary

95 11 References [1] Akenine-Möller, Thomas, and Eric Haines, 2002, Real-time rendering Second edition, A K Peters [2] Analytic cycling, January 2005, [3] ATI, January 2005, [4] Bloom, 2000, Terrain Texture Compositing by Blending in the Frame-Buffer, January 2005, techdocs/splatting.txt [5] Brennan, Chris, 2002, Per Pixel Fresnel Term, ShaderX: Vertex and Pixel Shader Programming Tips and Tricks, Wordware Publishing, Inc., December developer/shaderx/shaderx_perpixelfresnel.pdf [6] Cg, January 2005, cg_main.html [7] Conner, Brook and Loring Holden, Providing A Low Latency User Experience In A High Latency Application, 1997, Proceedings of the 1997 Symposium on Interactive 3D Games, pp [8] De Boer, Willem, 2002, Fast Terrain Rendering Using Geometrical MipMapping, December [9] DirectPlay, December library/default.asp?url=/library/en-us/dnplay/html/ dpov.asp/ [10] DirectX, December [11] Duchaineau, Mark, Murray Wolinsky, David E Sigeti, Mark C. Miller, Charles Aldrich, and Mark B. Mineev-Weinstein, 1997, ROAMing Terrain: Real-time Optimally Adapting Meshes, IEEE Visualization 1997, pp [12] Everitt, Cass, 2001, Projective Texture Mapping, December Projective_Texture_Mapping.html Chapter 11: References 85

96 [13] FarCry, December 2004, index.php?px=xisle [14] Fiedler, Stefan, Michael Wallner and Michael Weber, 2002, A Communication for Massive Multiplayer Games, Proceedings of the 1st workshop on Network and system support for games, pp [15] Fullford, Deb, Distributed Interactive Simulation: It s Past, Present and Future, 1996, Proceedings of the 1996 Winter Simulation Conference, pp [16] Färber, Johannes, 2002, Network Game Traffic Modelling, Proceedings of the 1st workshop on Network and system support for games, pp [17] GLSL, January 2005, oglsl.html [18] Havok, December [19] Henderson, Tristan and Saleem Bhatti, 2003, Networked Games - a QoS-sensitive application for QoS-insensitive users?, Proceedings of the ACM SIGCOMM 2003 Workshops, pp [20] Hisinger, Damien, Fabrice Neyret, and Marie-Paule Cani, 2002, Interactive Animation of Ocean Waves, Proceedings of the 2002 ACM SIGGRAPH, pp [21] HLSL, January 2005, default.asp?url=/library/en-us/directx9_c/directx/graphics/ reference/hlslreference/hlslreference.asp [22] Hoppe, Hugues, 1998, Smooth view-dependent level-of-detail control and its application to terrain rendering, IEEE Visualization 1998, pp [23] Hoppe, Hugues, and Frank Losasso, 2004, Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids, ACM SIGGRAPH 2004, pp [24] Irrlicht, January 2005, [25] Isidoro, John, Alex Vlachos, and Chris Brennan, 2002, Rendering Ocean Water, ShaderX: Vertex and Pixel Shader Programming Tips and Tricks, Wordware Publishing, Inc., December Chapter 11: References

97 [26] Jensen, Lasse Staff, and Robert Golias, 2001, Deep-Water Animation and Rendering, Gamasutra, December [27] Johanson, Claes, 2004, Real-time water rendering - introducing the projected grid concept, December graphics.cs.lth.se/theses/projects/projgrid/ [28] Kurose, James F. and Keith Ross, 2001, Computer Networking - A Top-Down Approach Featuring the Internet, Addison Wesely Longman, Inc., pp. 1-13, , [29] Larsen, Bent Dalgaard Larsen, and Niels Jorgen Christensen, 2003, Real-time Terrain Rendering using Smooth Hardware Optimized Level of Detail, Journal of WSCG, Vol. 11, No. 1, December C05.pdf [30] Lengyel, Eric, 2004, Oblique near-plane clipping, December [31] Lincroft, Peter, 1999, The Internet Sucks: Or, What I learned Coding X-Wing vs. Tie Fighter, Gamasutra, September lincroft_01.htm [32] Lindstrom, Peter, David Koller, William Ribarsky, Larry F. Hodges, Nick Faust, Gregory A. Turner, 1996, Real-time, Continuous Level of Detail Rendering of Height Fields, ACM SIGGRAPH 1996, pp [33] Lindstrom, Peter, and Valerio Pascucci, 2001, Visualization of Large Terrains Made Easy, Proceedings of the conference on Visualization '01, pp [34] Meqon Research AB, December [35] Meriam, James L. and L. Glenn Kraige, 1998, Engineering Mechanics Vol2 Dynamics Fourth Edition, John Wiley & Sons Inc, pp [36] NVIDIA, January 2005, [37] Ogre3D, January 2005, Chapter 11: References 87

98 [38] Oliviera, Manuel and Tristan Henderson, 2003, What Online Gamers Really Think of the Internet?, Proceedings on the 2nd workshop on Network and system support for games, pp [39] OpenGL, December [40] Pantel, Lothar and Lars C. Wolf, 2002, On The Impact of Delay on Real-Time Multiplayer Games, Proceedings of the 12th international workshop on Network and operating systems support for digital audio and video, pp [41] Pantel, Lothar and Lars C. Wolf, 2002, On the Suitability of Dead Reckoning Schemes for Games, Proceedings of the 1st workshop on Network and system support for games, pp [42] Pelzer, Kurt, 2003, Advanced Water Effects, ShaderX 2 : Vertex and Pixel Shader Programming Tips and Tricks with DirectX 9.0, Wordware Publishing, Inc., pp [43] Rakkarsoft L.L.C., December [44] Renderware, January 2005, [45] Shader Reference, January 2005, archive/default.asp?url=/archive/en-us/directx9_c/directx/ graphics/reference/shaders/shaders.asp [46] Ulrich, Thatcher, 2002, Rendering Massive Terrains using Chunked Level of Detail Control, December [47] Unreal Engine, January 2005, [48] Vlachos, Alex, John Isidoro, and Chris Oat, 2002, Rippling Reflective and Refractive Water, ShaderX: Vertex and Pixel Shader Programming Tips and Tricks, Wordware Publishing, Inc., December ShaderX_RipplingRefractiveAndReflectiveWater.pdf [49] Vlietinck, Jan, 2003, Hardware trilinear displacement mapping without tessellator and vertex texturing, January 2005, users.belgacom.net/gc610902/ 88 Chapter 11: References

99 [50] Wagner, Daniel, 2003, Terrain Geomorphing in the Vertex Shader, ShaderX 2 : Vertex and Pixel Shader Programming Tips and Tricks with DirectX 9.0, Wordware Publishing, Inc., pp [51] Weisstein, Eric W, Snell s law, January 2005, scienceworld.wolfram.com/physics/snellslaw.html [52] Wloka, Matthias, 2002, Fresnel Reflection, December [53] Youbing, Zhao, Zhou Ji, Shi, Jiaoying, and Pan Zhigeng, 2001, A Fast Algorithm For Large Scale Terrain Walkthrough, December terranwalk_release.pdf Chapter 11: References 89

100 90 Chapter 11: References

101 A Screenshots Figure 43: Screenshot of the game menu. Figure 44: Screenshot of a basic map in the game. Appendix A: Screenshots 91

102 Figure 45: Screenshot of a basic map in the game. Figure 46: Screenshot of the map editor. 92 Appendix A: Screenshots