Blog

Moving Mesh and Effect Code from Engine to Game:

The main goal of this exercise is to move the mesh and effect initialization to game instead of the engine. By doing this we are abstracting the engine from the data as engine should be able to process any type of data but doesn’t have to know what that data means. In games, the gameplay programmer can just specify which mesh and effect he wants the engine to render and the engine must be able to render that.

Sending the Background Color to render

eae6320::Graphics::SetBackBufferValue(eae6320::Graphics::sColor{ abs(sin(i_elapsedSecondCount_systemTime)),abs(cos(i_elapsedSecondCount_systemTime)),abs(cos(i_elapsedSecondCount_systemTime)), 1});

Output of changing the background colors.

    

The first problem that we encounter is how to pass the data from the game thread and the application thread. We use a struct(sDataRequiredToRenderAFrame) that is used to store the data required to render a frame. We first create the data in the game and send that data to the engine to store in this struct to render. Since our game and the renderer runs on two different threads if we use only one struct, the renderer thread would be waiting for the game thread to fill the data and the game thread will be waiting for the renderer to finish rendering the current frame.

To maximize efficiency, we make the game thread populate the data that is required to render the next frame while the render thread is rendering the current frame. To achieve this we use two structs, one to store the data being rendered in the current frame and one to store the data we want to render in the next frame and after the current frame ends, we swap the data in the two structs.

Since we are creating our effects and meshes in the game instead of engine, we should restrict the access to mesh and effect classes and should not allow calling the constructor and destructor. Instead we implemented a Factory function which creates a new mesh or effect and gives us the pointer to the created mesh or effect. Since we are dealing with pointers, there is a possibility that the game or renderer might free the pointer when the other one is using, and this might create undefined behavior. To mitigate this, we use reference counting to keep track if the pointer is being used and when the game or renderer no longer uses the pointer, we decrement reference count and once reference count reaches zero, we then free the pointer. The framework for reference counting was already present in the engine and we just have to implement it.

To pass the mesh and effect data between game and engine, I am using a array of struct which takes an effect and mesh in that order and the renderer then first binds the effect and then draws the mesh in the same order

m_EffectsAndMeshes[0].m_RenderEffect=s_Effect; 
m_EffectsAndMeshes[0].m_RenderMesh=s_Mesh; 
m_EffectsAndMeshes[1].m_RenderEffect=s_Effect2; 
m_EffectsAndMeshes[1].m_RenderMesh=s_Mesh2; 
eae6320::Graphics::SetEffectsAndMeshesToRender(m_EffectsAndMeshes,m_NumberOfMeshesToRender);

 

Hiding the meshes and swapping the effects:

Since we moved the code to initialize and submit the effects and meshes to game, we can also specify which ones to render and which effect goes on which one. In my game, we can hide a mesh by pressing F1 key and swap effects between the two by holding the F2 key.

 

Removing mesh

 

Swap effect:

The reason why we submit all the data required to render a frame when the renderer is rendering the previous frame is that the renderer will know what to render in the next frame and this eliminates the renderer waiting for data to be submitted by the application.

Size of Mesh, Effect and sDataRequiredToRenderAFrame:

After making the mesh and effect reference counted, the size of mesh and effect turned out to be 20 bytes in OpenGL, 40 and 48 Bytes respectively in Direct3D. The size of the struct was 168 bytes in OpenGL and 176 Bytes in Direct3D. After rearranging the member variables in the struct, the size of mesh and effect came down as shown below.

Breakdown of sDataRequiredToRenderAFrame

Member	Size
Constant data required per frame	144
Color struct which holds four floats	16
The struct which holds the effect and mesh to render	8 / 16 * ( 10 pairs)
unsigned int containing the number of mesh effect pairs being rendered	4

 

Before Optimization:

	Mesh	Effect	sDataRequiredToRenderAFrame
OpenGL	20	20	244
DirectX	40	48	328

After Optimization:

	Mesh	Effect	sDataRequiredToRenderAFrame
OpenGL	20	16	244
DirectX	32	48	328

Size differences from last week:

For the previous assignment, the way I divided the platform specific code into a new class was not the ideal way of doing it and created a few problems while working on this weeks assignment. So I went in and changed the code so that it is better and in the process I removed a few member variables that I was using in both the mesh and the effect class which lead to the drastic decrease in the amount of memory taken by each class.

Total Memory for the graphics project:

The memory allocated to graphics project is budgeted, since memory is limited, especially in consoles and mobile. Hence the total number of meshes and effects that can be drawn at the same time is capped at 10. The total memory that will be taken is 488 Bytes in OpenGL and 656 Bytes when using Direct3D. When the game wants to render more than that number of meshes, the renderer only renders the first 10 pairs of effects and meshes and in Debug mode will throw an error.

 

Controls:

1. Shift: To slow the simulation
2. F1: To make a mesh invisible
3. F2: Swap the effects between meshes

MyGame_Assignment04_x86 MyGame_Assignment04_x64

The main part of this assignment is to remove all the platform specific code that is present in the various graphics.xx.cpp files and create one platform independent graphics.cpp file. For this I created another class to hold all the platform specific code called “GraphicsHelper”. This class contained functions that mirror those of the main Graphics interface. Graphics.cpp contained all the platform independent code and calls are made to functions in graphics helper for platform dependent code. Each platform specific implementation inside GraphicsHelper is differentiated using preprocessor blocks.

The GraphicsHelper class also has interface to change the color of back buffer. At start of every frame the back buffer is first cleared usually by setting the color to black. I created a color struct that takes in values of red, green, blue and alpha between the values of 0 and 1. This I pass to my graphicshelper.cpp using the interface “SetBackBuffer” which then sets the value for the back buffer.

 

sColor m_BackBuffer {

abs(sin(s_dataBeingSubmittedByApplicationThread - > constantData_perFrame.g_elapsedSecondCount_simulationTime)), abs(cos(s_dataBeingSubmittedByApplicationThread - > constantData_perFrame.g_elapsedSecondCount_simulationTime)), abs(cos(s_dataBeingSubmittedByApplicationThread - > constantData_perFrame.g_elapsedSecondCount_simulationTime)), 1

};

Interface for changing the color of back buffer

 s_helper->SetBackBuffer(m_BackBuffer); 

We also added an index buffer to tell the graphics API, the order in which vertices of a triangle are to be drawn. By using an index buffer, we can reduce the number of points that are being stored for any shape as we can remove the common vertices between each triangle that is part of that mesh. But, this introduces an additional complexity when using different renderers such as OpenGL and DirectX. Since they render points in different order, index buffer for one is incompatible with the other. The way I solved this is to take the order of OpenGL as default and swap every 2^nd and 3^rd point in the array.

I also moved out the code to initialize the meshes and effects from their respective classes to Graphics.cpp. During the initialization from graphics.cpp the effect needs the locations of both the vertex and the fragment shaders as strings

 
	s_Effect->Initialize(m_vertShader1Location, m_fragShader1Location);
	s_Effect2->Initialize(m_vertShader2Location, m_fragShader2Location);

The mesh requires a pointer to the array containing the vertex buffer, pointer to an array containing index buffer and the number of vertices that are to be rendered using the index buffer, as it is not possible to find the number of vertices since we are passing a pointer to the array and not the array itself.

 	
s_Mesh->Initialize(vertexData, indexData, 3);
s_Mesh2->Initialize(vertexData2, indexData2, 4);

After refactoring the code to include the changes to Graphics.cpp, my mesh class uses 28 Bytes and 48 bytes in OpenGL and Direct3D respectively. Effects on the other hand take-up 72 bytes and 120 bytes respectively. I could not find any way to reduce the size.

Optional Challenge:

As an optional challenge we must animate the background color. So instead of passing a solid color value such as {1,0,0,1} for red, I passed the value of the sine value of simulated time clamped between 0 and 1.

Final Output:

MyGame_x64 MyGame_x86</a

Creating common interface for rendering meshes and binding effects:

The current engine has two different Graphics.cpp files, one each for Direct3D and OpenGL, which perform exactly the same thing. The main functionality of these files are to Initialize the vertices and shading data, Bind shading data and draw the vertices, Render the frame and perform cleanup after rendering is complete. Our assignment is to create a common interface to Initialize, Bind and Cleanup effects and Initialize, Draw and Clean the meshes which is platform independent.

Since all of the code is already present, the first thing we need to do is to identify parts of the original files performing the different functions. Once identified, it is simple to move them to new files and create references to the new files in the old ones. The way I did this is to move one part of the file at a time and commenting the relevant parts in the old file, so that even if there are some errors it would be easy to figure out where things are going wrong. Once it is confirmed that everything is working, I removed the redundant code. I created two header files one for mesh and other for the effect which contain the platform independent function calls and couple of cpp files which contain the actual implementation for specific APIs.

The separation of functions for the effect are a bit more complex since the code contain lots of platform independent and dependent stuff mixed together. Hence, I created another cpp file to hold the platform independent initialization and cleanup process.

Below is the code that binds the effect and draws the mesh which is common in both the Graphics files.

// Bind the shading data

{

s_Effect.Bind();

}

// Draw the geometry

{

s_Mesh.Draw();

}

As an engine programmer we often have to dig deep and write code which directly interfaces with the hardware. But since there are lots of differences between each hardware platform and the vendor APIs that are used to access the hardware, it is easier for us and other programmers to write such interfaces which are platform independent.

Adding an additional triangle to draw, we have to keep in mind the difference in DirectX and OpenGL on the order how they render points, with DirectX using the left hand convention and OpenGL the opposite.

Finally, after moving the mesh and effect representations to their own platform independent interfaces, the graphics classes for each platform now only contains code which renderers the frame which can be moved to its own class to make the graphics class truly platform independent.

 

Visual Studio Graphics Debugger and RenderDoc:

The Visual Studio Graphics Debugger and/or RenderDoc are important pieces of software when writing software related to Graphics. Using these two software we can see the API function calls to DirectX(VS Debugger/RenderDoc) or OpenGL(RenderDoc) at a particular frame in the game. This is useful when there are graphics artefacts in the game and we want to debug where in the render pipeline are they getting introduced. We can look at each API function call and see what is being sent to the graphics card at that particular frame which makes debugging graphics related issues easier.

Following are the screenshots from the VS Graphics Debugger showing the render process for a frame in the game

The game:

The same in RenderDoc (For OpenGL)

The game:

Optional Challenge: As a challenge creating a “house” and a “tree” using triangles. This is done using 7 triangles. The hardest part of this is figuring out the points in the screen coordinate space and adding them in the correct order for the respective renderers.

DirectX:

OpenGL:

Fixing the “Debug x86” bug: My Solution had a strange bug where all configurations were building perfectly except for Debug x86. I first thought that this issue was because of a references issue due to Graphics project not being updated as discussed at this link. But even after fixing the references for the Application project, the issue persisted. So, after doing more investigation, I found out that I added a library reference to “Graphics.lib” in the project settings for my game just for the Debug x86 configuration. The issue got resolved as soon as I removed this reference in the settings and now builds in all the configurations.

You can download the game from the links below

User Inputs

1. Shift: Plays the game in slow motion when held
2. Esc: Exits the game.

MyGame_Assignment2_x64 MyGame_Assignment2_x86