1. 03 | Creating, Texturing and Moving Objects
Michael “Mickey” MacDonald | Indie Game Developer
Bryan Griffiths | Software Engineer/Game Developer

2. Module Overview Things We Should Know Creating a Mesh
Manipulating an Object
Rendering a Mesh
Creating More of the Same

3. Things We Should Know
DirectX games use polygons to represent objects and surfaces.
The list of vertices that represent the structure of these polygons are called meshes.
These meshes are then passed to the shader pipeline to be rendered and then displayed.
Most games store their meshes in external files that are loaded into memory as needed.
Basic meshes can be written right into the code itself for easy reference throughout the game.

4. Creating a Mesh Meshs data is typically stored in external files.
The vertex order in these files is application/file type dependent.
Typically stored in one of three forms:
Strips
Lists
Fans
Since our demo game requires only simple meshes, we will not be using any external mesh data.

5. Creating a Mesh
The minimum data required per vertex is its position in local space.
To create a cube we need eight vertices.
But other information can be stored along with it:
A Vertex Color
A U/V Texture Co-ordinate
A Normal

6. Creating a Mesh
So how do we specify to DirectX that a vertex will have certain pieces of information over others?
The first step is to create a input element description.
Then create the Input Layout on the D3D device.
Almost done! Now need to create the buffer for all the data based upon that layout.

7. Creating a Mesh
Vertex Buffers contain a list of vertices for each polygon in a mesh.
The Vertex Shader runs on the GPU and reads from this buffer and interprets the data based on the Input Layout we have specified.
To actually create this buffer we have to define two other things:
A D3D11_SUBRESOURCE_DATA struct and a D3D11_BUFFER_DESC struct.

8. Creating a Mesh Vertices aren’t the only thing we need!
We also need an index list that determines how the polygons are formed to create the final mesh.
Envision each vertex as having an ID assigned to it that represents its position in the buffer.
Now create a list of triplets that represent each of the 12 triangles required to create the cube.

9. Creating a Mesh
Vertices in the demo game contain position, UV and normal data.
Providing support for textures and lights.
The code to set up the D3D Device to handle these vertices and extra data is still very similar to the sample project’s code.
The demo has three mesh classes which utilize the code approach to creating meshes.
MeshObject: The game’s base mesh class.
CylinderMesh: Used for the circular floor mat.
SumoMesh: Our (8-Bit) sumo wrestler mesh. ;)

10. Taking a look at the sumo’s mesh.

11. Manipulating an Object
In order to manipulate and view an object we typically use three different 4x4 matricies:
World Matrix: converts the model’s coordinates into world space.
View Matrix: converts the world space coordinates into camera space.
Projection Matrix: converts the coordinates from camera space into screen space.
Because the model matrix changes before rendering each object in the game it is stored separately from the other two.
Typically the View and Projection matrices are stored and/or defined by a game’s Camera class.

12. Inspecting the camera class and the matrices.

13. Manipulating an Object
Now that we have seen where those matrices are stored and what they each do lets actually look at manipulating an object.
To do this, we alter the world matrix right before we render the object on the rendering device.
However, the alterations need to be stored somewhere. So we abstract that and store a “world matrix” in each object’s instance.
At this point most games will create a class called GameObject to use as a base class for all other objects in the game and typically that is where this data is stored and accessed when we need to render that object.

14. Manipulating an Object
Then we create a series of constant buffers.
Each buffer is meant to store a series of items based on how often those items need to be updated on the graphics device.
Microsoft::WRL::ComPtr<ID3D11Buffer> m_constantBufferNeverChanges;
Microsoft::WRL::ComPtr<ID3D11Buffer> m_constantBufferChangeOnResize;
Microsoft::WRL::ComPtr<ID3D11Buffer> m_constantBufferChangesEveryFrame;
Microsoft::WRL::ComPtr<ID3D11Buffer> m_constantBufferChangesEveryPrim;
These buffers are instantiated similarly to the vertex buffers.
Start by creating a buffer description: D3D11_BUFFER_DESC
Then use m_d3dDevice->CreateBuffer() with that description.
Finally, fill in the data via your original ComPtr for that buffer.

15. Inspecting the GameObject, its children and the buffers.

16. Rendering a Mesh
The next step on our path to rendering a mesh is to create a basic vertex and pixel shader using HLSL.
Both can be written in a single file, but separating them makes it easier to manage as the project grows.
VertexShader.hlsl
PixelShader.hlsl
Also, creating a separate file for your buffers can help to manage things as well.
ConstantBuffers.hlsli

17. Rendering a Mesh Vertex Shaders
A vertex shader processes a mesh’s vertices by performing operations such as transformations, skinning, and lighting on them.
They always operate on a single input vertex and produce a single output vertex.
This stage of the rendering pipeline must always be active.

18. Rendering a Mesh Pixel Shaders
Or fragment shaders, compute color and other attributes per fragment.
They can alter the depth of the fragment for Z-buffering.
And can create two-dimensional post-processing effects, such as blur.

19. Inspecting the demo’s shader files.

20. Creating More of the Same
Instancing – Creating an object from the same base template as another object that came before it.
Referencing – “Would the renderer kindly refer to this mesh over here when drawing me.”
Each SumoBlock has a reference to the same SumoMesh.
The GameRenderer draws that same SumoMesh wherever the SumoBlocks report their positions are, via their worldMatrix each frame.

21. Quick review of the SumoBlock / SumoMesh referencing.