Game Programming for the PC and XBox

Transcription

1 Game Programming for the PC and XBox May Tutor: Dr Shovman Mark Student Name: Anastasios Giannakopoulos Student Number: Module No: AG1102A

2 Table of Contents Introduction... 2 Project goal... 2 Application usage and controls... 2 Player mode:... 2 Debug mode:... 2 Framework design and development... 3 SCTMath... 3 SCTCore... 3 SCTEngine... 4 Input Subsystem... 4 Scene Subsystem... 4 Resource Subsystem... 5 Render Subsystem... 5 PCG Subsystem... 6 Third-Party libraries... 6 Procedural Content Generation... 7 Terrain Generation... 7 Procedure... 7 Other functionality... 7 Usage... 8 Examples... 9 Vegetation Post Processing Depth of field References General references Source code Terrain PCG generation Random forest scattering Depth of field D models Third Party Libraries Appendix I: Project compilation Appendix II: Known issues

3 Introduction Project goal The goal of this project is to research advanced techniques for procedural terrain and vegetation generation. Also ways to control the procedural generation are investigated, specifically the use of an image (elevation map) to control the height of the terrain in specific areas. Three algorithms have been implemented for terrain generation (Diamond square, faulting and advanced particle deposition), however only two are used due to problems of the advanced particle deposition algorithm. For vegetation generation, the random scattering technique has been researched, implemented and enhanced with ways to control the scattering (statistics of different vegetation entities and relationships between them). Also post processing visual effects have been investigated. Specifically a depth of field visual effect has been implemented, using a blurred version of the scene and the Z buffer to render the out of focus areas. Application usage and controls The result is a playable demo using a redesigned and re-implemented Directx 10 framework based on the material of the previous semester (SCTEngine). Player mode: W,A,S,D : Move Mouse: Look around Space: Jump Left Ctrl: Crouch Left mouse: Shoot Shift: Accelerate Debug mode: C: toggle camera between debug (free roaming) and player (First person). Initial state of the application is on the debug camera. In order to use the debug rendering features of the framework, the post processing needs to be disabled (H). B: render bounds, N: render normals, M: render wireframe, G: render debug texture, H: toggle post processing on/off, K: toggle statistics on/off. 2

4 Framework design and development The framework used for this project (SCTEngine v2) is based on previous semester s material. However the framework has been redesigned from scratch, to allow the use of advanced Directx 10 features with ease. All the Direct3D functionality has been abstracted with the use of interfaces. This way, the engine can be extended in the future to support other graphic API such as OpenGL. The SCTEngine v2 is composed of 3 libraries. The Math library (SCTMath), the Core library (SCTCore) and the main engine (SCTEngine). SCTMath The Math library, as the name suggests, contains the necessary math classes that are used throughout the engine. Most of the code for the library has been taken from the source code of the book Ultimate 3D Game Engine Design & Architecture [8] and the open source Ogre3D [7] graphics engine. The code has been adapted to the coding standards of SCTEngine v2. However the library is not complete, since only the elements that are used for this project are include, these are: Matrix4, Vector2, Vector3, BoundingBox (axis-aligned), Ray, Plane, ColorRGBA, Quaternion, Frustum. SCTCore The majority of the Core library has remained almost unchanged from the previous version. It has been reorganized and new functionality has been added. SCTStatistics: The SCTStatistics class encapsulates functions to calculate frame rate per second and CPU usage. SCTLogManager: The log manager enables a debug console (only for debug builds), and functions to print formatted messages to that console. Image 1: SCTCore library classs diagram SCTFileManager: File I/O SCTWindows: Handles the creation of the main render window and all the windows (Win32 API) callback functions. The configuration dialog from the previous version has been removed, however it can easily be re-implemented since the engine is designed in that way. 3

5 SCTImageLoader: This is a new class created for the needs of this project. It uses the DevIL (Developers Image Library) [3] to load the raw data of an image. SCTStringHelper: Contains functions to convert strings from Unicode to ASCII and vice-versa. of the engine s type definitions in SCTTypes.h, general engine SCTTime: High definition timer. The core library also includes most configuration in SCT.h and platform specific configuration in SCTPlatform.h. SCTEngine As mentioned previously, the engine has been redesigned to use the power of C++ interfaces to abstract the DirectX functionality. The following diagram shows the engine s subsystems. To access each subsystem easily, the manager classes are Singleton classes (SCTInputManager, SCTSceneManager, SCTRenderInterface, SCTResourceManager, SCTTerrain, SCTVegetation). Image 2: SCTEngine Subsystem diagram Input Subsystem SCTInputManager: handles and gives access to the keyboard and mouse interfaces. For the keyboard and mouse, only the win32 implementation has been included, using Microsoft s DirectInput8 library. Scene Subsystem SCTSceneManager: The scene manager handles and gives access to all the objects in the virtual world (scene). It uses a tree data structure, with a SCTSceneNode at each tree node. The scene manager contains only a pointer to the scenee root node, and through that node we can get access to every scene node. To access the scene nodes, a Depth-First tree traversal algorithm is used. In addition, a function to 4

6 check for intersection between a ray and all the triangles of a node s mesh is included (CheckIntersection function). This function returns a list with all the intersections of the ray with that mesh. The SCTSceneNode class contains a pointer to the data of that node (currently only SCTMesh), the local to world matrix of this node, which positions and orients the node in the scene. Also a list of all the children nodes of this node is included. Resource Subsystem SCTResourceManager: The resource manager handles all the resource loading and unloading, as well as resource double-checking. This way we make sure that every resource used in the game is only loaded once and gets correctly unloaded, without leaving memory leaks. It does that quite easily by keeping all the loaded resources in a std::map using as a key the filename. Since all the resources used are in the same directory (./Media/) we make sure that nothing has been loaded twice. In addition, the use of the map gives quick access to all the loaded resources (using a Handle instead of string as a key would be an optimization). The SCTShader, SCTMesh, SCTTexture classes are interfaces to abstract the use of the Direct3D api. The SCTMesh interface is divided into two interfaces, the submesh and the Mesh interfaces. The submesh interface contains all the geometry of the model (vertex buffer, index buffer), the material used by that submesh and an axis-aligned bounding box. The mesh class contains a list with all the submeshes that compose this model. To load a mesh the assimp [] library is being used. Assimp library is a great library to load many different 3D models, however after experimentation and loading a lot of different formats, the COLLADA format (Open Collada exporter in Autodesk Maya) has been found to work better (both mesh and material loading). The submesh D3D10 implementation uses plain ID3D10Buffer, instead of the ID3DXMesh interface used in the previous project. The SCTShader interface is a generic shader interface that handles the loading of shaders (only HLSL currently). Since the use of an elaborate shader management system is not in the scope of this project, every different shader that is used derives from the SCTShader interface (specifically SCTShaderD3D10 for Direct3D 10 implementation). The SCTShaderD3D10 contains all the generic code for the shaders (load from file, using specific input layouts, initializing the shader). In this project only four different shaders are used (SCTShaderD3D10Lighting, SCTShaderD3D10Wireframe, SCTShaderD3D10PostEffect and SCTShaderD3D10Skybox). Render Subsystem The render subsystem encapsulates all the functionality to render a submesh to the render window or a render target. It also contains functions to render debug objects (such as wireframe, normals and bounding boxes). The SCTRenderInterface as the name suggests is coded as an interfaces and only the direct implementation is included (SCTRenderInterfaceD3D10). 5

7 The SCTInputLayout contains different input layout descriptions used to correctly render geometry (shader and input assembler). The SCTRenderTarget is a simple 2D quad rendered with an orthographic projection to the screen, which allows us to render post effects to the screen. The SCTRenderTexture derives from SCTRenderTarget and contains a texture to where the scene or anything we would like to be rendered is rendered. This interface is being used for the post effects in the game. PCG Subsystem The Procedural Content Generation subsystem contains the two managers (SCTTerrain and SCTVegetation) that handle the advanced procedural content creating and placement in the game. Their functionality and usage will be described in the next section Third-Party libraries The following 3 rd party libraries have been used in the SCTEngine v2. Links for the libraries are provided in the References section. Assimp (version ): To load 3D models and its materials. Open collada (.dae) format is being used. DevIL (Developers Image Library version 1.7.8): To get the raw image data for the elevation map used to control the procedural generation of the terrain. Vld (Visual Leak Detector version 2.2.2): To locate memory leaks 6

8 Procedural Content Generation This project is mostly focused in advanced terrain generation and controlling it through an image (elevation map), and procedural placement of vegetation. Terrain Generation The SCTTerain class (PCG subsystem), handles completely the generation and control of the terrain. It encapsulates functions to generate the terrain (Fautling and Diamond square algorithms), to smooth the terrain, process the raw data of an image (elevation map) and convert them to displacement values used by the system to control the elevation. It also contains functions to generate the terrain normals, tangents and binormals (for use in lighting and bump mapping). Procedure The terrain manager always generates the terrain following the same procedure: First the grid is created using a quilt pattern (index buffer). Then the loaded image (elevation map) is converted to displacement values. This is done quite simply: the color Red is being converted to displacement values between [0.6, 0.8], green to [0, 0.1], and blue to [-0.4, -0.3]. These values have been selected after a lot of experimentation for specific elevation maps and are not necessary correct for every possible map. However they can easily be changed, if necessary. The next step of the algorithm is the actual generation of the terrain. For this step the Diamond square algorithm is used. The only modification of the algorithm is the use of the displacement values to weight the height of each pixel. Since the elevation map image is scaled to the size of the terrain, there is always one displacement value for every vertex in the grid. After the generation of the terrain with the diamond square algorithm, a few passes of the faulting algorithm is applied to the grid. Finally, up to five smooth passes can be applied to the terrain to smooth it out. The algorithm used here is a blur algorithm (left to right and top to bottom). Other functionality Some algorithms have not been fully developed and so, even thought the code is included they are not used by the system. One is an advanced particle deposition algorithm. The idea for this algorithm was to drop a particle in radius and make it drop down following random routes. This way realistic eroded terrain could have been generated, however because there were problems in visiting recursively only once all the neighbors in the radius of the dropped particle, the algorithm was abandoned. The function GetTerrainHeight() which should return the height of the terrain at a current position (x,z) using linear interpolation of the heights of the current terrain cell has also been abandoned since it didn t return the correct height. For this reason, ray casting against the terrain is being used to get the 7

9 current height, however is computationally more expensive, since it checks with all the triangles in the terrain. Usage Generating a terrain is as simple as filling a structure (PCG::SCTTerrainConfig) with all the necessary information and calling the GenerateTerrain() function of the terrain manager. Image 3: Terrain configuration structure Every step of the terrain generation algorithm can be configured through the SCTTerrainConfig structure. If an elevation map is not used, then the terrain is generated using a constant displacement value of one. The resulting terrain cannot be controlled to plains, mountains and sea. Using the elevation map, however, we can control up to some extend the way the terrain will look. An elevation map is composed of the tree basic colors (Red, Green and Blue). Red color defines high elevation (mountains), green, low (plains) and blue, negative elevation (sea, lakebeds). Sometimes the use of an elevation map produces artifacts because it is used with the diamond square algorithm, which they are not noticeable when the user walks on the terrain. 8

10 Examples The following images show the generation of different terrains using the terrain generation system. Four different elevation maps are used. Image 4: Elevation Map #1 Image 5: Result of elevation map 1 on Diamond square algorithm Image 4: Elevation Map #2 Image 5: Result of elevation map 2 on Diamond square algorithm 9

11 Image 8: Elevation Map #3 Image 9: Result of elevation map 3 on Diamond square algorithm Image 10: Elevation Map #4 Image 11: Result of elevation map 4 on Diamond square algorithm In the examples above we can see clearly that the algorithm doesn t cope well with negative elevations (sea). The Diamond square algorithm is not the best algorithm to use alongside an elevation map, due to its nature. The algorithm works by subdividing the grid in half the size and elevating the middle point averaging the heights of the square corners. It also elevates the middle points between the corners. Using an elevation map with this algorithm produces artifacts like the one in image 11 (straight line in the middle of the terrain). It also produces rough negative elevations (images 5, 9). However the overall terrain looks realistic, and most of the time in correlation with the elevation map. Also the artifacts mentioned above are not noticeable when the player walks on the terrain. 10

12 Vegetation The vegetation system is based on the random scattering algorithm using a radius and different entities as presented in [16]. The idea is to be able to populate a map with vegetation using a few 3D models, and a set of rules. Specifically in the SCTVegetation system, the user has the ability to create vegetation entities from loaded 3D models. Every vegetation entity has a type (tree, foliage or misc), a min and a max radius and a y offset. In order to create the vegetation, a patch of a terrain (or grid) is needed so the vegetation manager can place the entities on the correct height (using raycasting to get the terrain height). The y offset of each entity defines how far above or beyond the ground (height offset of terrain) that entity has to go. Before we explain the role of the min, max radius and the vegetation entity type, let s take a look at the configuration entity o the SCTVegetation system. The size variable defines the size of the terrain patch (in our demo same as the terrain). The iterations defines how many entities the system will try to place on the terrain, The rest variables define the percentage of each type of vegetation entities we want to place on our scene, if of course entities of the appropriate type are available. The last step of configuration for the vegetation system is a set of relationships between the existing Image 6: Vegetation configuration entities. These Image 7: Vegetation entities relationships relationships define which one of the two radiuses set (min, max) will be used to check the current entity against all the entities in the scene. Simply put, if two entities are related, the max radius will be used to distance them in the map, if they are not related, then the min radius can be used. In this way, we can put trees far away from each other, while keeping foliage as near as possible. Since foliage grows near trees, this is a more realistic result. The first three rules in image make sure that no trees, foliage or crates will overlap, while still foliage and crates can be placed near the trees. Before showing some examples of the system in use, it s important to note that the algorithm will not always place as many entities as requested. Let s consider the example of placing many trees in a small terrain patch with each tree using a big radius. After the placement of some entities, the algorithm would fall in an infinite loop trying to find an appropriate position to place the tree, without any luck. The vegetation system has been designed in a way to respect the predefined user statistics while placing as many entities as possible. This is done quite simply; the algorithm tries to place an entity, if it fails to find an appropriate position after 50 tries, it gives up and chooses a new type of entity. 11

13 In the following examples we can see the Vegetation system in use. Bound boxes are used to distinguish the different vegetation entities. Image 8: example 1, configuration Image 7: Example 1, Result (statistics) Image 8: Example 1, Result (top view with bounding boxes) In example 1 we can see that the system respected the predefined statistics (48 trees instead of 50), even though it could not place as many entities as the user wanted (98 instead of 100). Image 9: Example 2, configuration Image 0: Example 2, Result (statistics) Image 11: Example 2, Result (top view) 12

14 Post Processing Depth of field Depth of field is and advanced visual effect in which objects within some range from the camera appear in focus, and objects out of this range appear out of focus. There are various different implementations of this technique, such as Foreword-mapped and Reverse-mapped Z-buffer techniques. For this implementation we use a three step blur-buffer with depth checking technique. In this way, the scene if first rendered to a render target and the back buffer. Then the render target gets blurred with Gaussian blur and is rendered on top of the not blurred scene using the depth buffer values to define the alpha value of each pixel. Step 1: Render both the scene and the depth value to a SCTRenderTexture. Render the SCTRenderTexture of the scene to the back buffer (instead of rendering the scene twice) Step 2: Downscale the scene s SCTRenderTexture, pass the depth buffer to the shader and apply Horizontal and Vertical weighted Gaussian blur (the blur is weighted using depth buffer values). Step 3: With the original scene in the back buffer, pass the Depth values texture and the blurred texture to the shader and apply the depth of field post effect. The depth buffer values are modified using a near and far distance and a range. The fblurfactor below becomes the alpha value of the current pixel on the blurred texture. In this way, we partially render the blurred texture on top of the original scene. float fblurfactor = clamp(1, 0, (fdepth - neardist) / nearrange); Image 9: The scene blurred with 1 pass of weighted gaussian blur Image 10: Depth values, rendered to texture It is important to note that the depth buffer is generated by rendering the Z value of each pixel to a texture instead of using the actual Z buffer. We use the alpha values of each diffuse texture (example leaves) to discard pixels with alpha values. If this wasn t done, instead of individual leaves in the depth buffer, we would have quads (quads on which the leaves are rendered on), which would generate artifacts in the Depth of Field effect. 13

15 Image 12: Depth of field example Image 11: Depth of field example Image 13: Depth of field example 14

16 References General references [1] Sebastien St-Laurent (2004). Shaders for game programmers and artists. Boston, Ma.: Thomson/Course Technology. [2] Sebastien St-Laurent (2005). The Complete Effect and HLSL Guide. Redmond, WA: Paradoxal Press. [3] Eric Lengyel (2004). Mathematics for 3D game programming and computer graphics. 2nd ed. Hingham, Mass.: Charles River Media. [4] Eberly, David H. (2007). 3D game engine design : a practical approach to real-time computer graphics. London: Morgan Kaufmann, [5] Jason Gregory (2009). Game engine architecture. Wellesley, Mass.: A K Peters. [6] Allen Sherrod (2007). Ultimate 3D game engine design & architecture. Boston, Mass.: Charles River Media. Source code [7] Ogre3D source code, [8] Building Blogs engine, source code from book [6] Terrain PCG generation [9] DeLoura, Mark. (2000). Game programming gems. Charles River Media , articles by Shankel Jason and Guy W. Lecky-Thompson [10] Game programming Gems 5 advanced particle deposition [11] Gregory Snook (2003). Real-time 3D terrain engines using C++ and DirectX 9. Hingham, Mass.: Charles River Media. [12] Trent Polack (2003). Focus on 3d terrain programming. Cincinnati, Ohio: Premier Press. [13] Post by user Koder4Fun, Calculating generated terrain s tangent, [14] Calculating terrain normals, [15] Helpful posts by users in calculating terrain normals, calculate-terrain-normals/ Random forest scattering [16] Mick West. (2008). Random Scattering: Creating Realistic Landscapes. Available: 15

17 Depth of field [17] Joe Demers. (2004). Chapter 23. Depth of Field: A Survey of Techniques. Available: [18] Unknown author, Depth Of Field Sample. Available: [19] racoonacoon. (2011). Getting Direct Access to the DepthBuffer in DirectX10. Available: 3D models [20] All of the models used in the demo have been downloaded from and converted to COLLADA (.dae) format, using the Open collada exporter ( in Autodesk Maya Third Party Libraries [21]Assimp 3D model loading library, [22] DEVelopers Image Library, [23] Visual Leak Detector, 16

18 Appendix I: Project compilation Assimp library wasn t included in the submission of the final project because of its size. In order to compile the project, assimp version needs to be downloaded and placed under ThirdParty\assimp_ In assimp workspaces\vc9 directory the visual studio 2008 (assimp.sln) project needs to be converted to a visual studio 2010 project. For the project, the release-no-boost and debug-no-boost configurations are used. The final assimp.lib file needs to be copied from assimp_ \lib\assimp_debug-noboost-st_win32\ to assimp_ \lib\. For SCTEngine_v2 to be compiled, only the assimp solution needs to be compiled (no viewer or tools). Finally all the media from Release\Media\ needs to be copied in SCTApp\Media\. 17

19 Appendix II: Known issues Memory leaks because of issues in the material allocation and release of assimp. Weapon doesn t render correctly on top of all the geometry. The screenshot bellow demonstrates the issue. The weapon gets submerged into the terrain. 18