Blogger Templates

Thursday, October 26, 2017


Graphics (8 of ∞) Meshes and more shaders!

Posted in ,
EAE 6320-001

In this write-up, I will talk about my experience of creating a mesh that will be separate from the sprite which will have the necessary position data, geometry data which are populated with vertex data and index data.

Mesh - Barebones
When I started this work, I had a little understanding of how a Mesh would be in terms of architecture. After going through JP’s notes, I was able to create an exact replica of sprite and renamed it as a mesh. I refactored my existing architecture to support mesh submission from game code to graphics code. This means I supported a system which was running without any sprites but with mesh. The mesh class also contains the position and velocity information for movement. It also has an index buffer id in addition to the vertex buffer id to take advantage of shared vertex points. The mesh vertex format struct will be used to represent the vertex data and the color information that each vertex can hold. The area between the vertex points will have the interpolated colors based on the vertex points colors.

Shader Changes
To support the mesh, I had also created the vertex shader, fragment shader, and even layout geometry exclusively for the mesh that will be used to pass the color and the position information. We also use the constant buffer here to take the position information from a constant buffer and sum it with the existing positional information of the mesh. I also wrote functions inside the AssetBuildFunctions.lua to support the linked build process of AssetBuildExe for the newly created shader files.

It was interesting to implement indexing for accessing the vertex data through indices. This would drastically reduce the need for having multiple vertex points for complex mesh shapes by allowing vertex points to be shared. The way I implemented this one is by having a vector of vectors for both vector data and index data. I would put all possible vertex points on a vector of sMesh(vertexData) and add a meaningful order of indices in a vector of sMesh(indexData). The thing we have to be wary about here is the winding order. For the sake of convenience, I followed D3D as my primary pattern. Inside my mesh platform-specific implementation, I would then access my vertex points based on the index data to draw the mesh. For OpenGL, I would use the same indices but with a reversed approach in its platform specific implementation thus abstracting this logic from the gameplay programmer.

Another interesting thing I worked on this project was to make the mesh move using the keyboard events. I was able to leverage the engine’s UpdateSimulationBasedOnTime to support key press events and updating the movement for the mesh. The way i did this was to have a position as part of my mesh class and based on the keypress, I would apply a velocity in the direction of need and the deltaSeconds. The math here to determine the position is quite straightforward. NewPredictedPosition = OldPosition + (velocity * deltaSeconds); We are predicting the position to increase the smoothness of the movement of the mesh as we press any key. Imagine this like an interpolation of values between keyframes.

Input Handling
The way I have designed looking up the input events is using the UpdateSimulationBasedOnTime and having them bound to the respective meshes to pass the velocity and calculate position. I also saw the possibility of using UpdateSimulationBasedOnInput for handling input specific events. I am not sure of the difference/loss we would have if we do the input check directly UpdateSimulationBasedOnTime. I will share more details on this after further experimentation.

The simulation speed is roughly about 0.066 seconds and modifying this value would affect the game's simulation time and possible changes could be that the game simulation running faster or slower based on the mod value.
Couple of things I experimented to get the shared vertex working is to have like a vector of commonly shared vertices and access them through indices but realized the challenge involved in keeping track of the completed indices for different meshes. So I had to fall back to a vector of vector vertices to have mesh specific vectors and use indices to be able to use them in a shared manner rather than duplicating. Future Scope
I am planning to extract this module of mesh data using a game object as that represents a simulation object in my upcoming assignment. I also would need this abstraction as we move from 2D to 3D.
I would like to give credits to Ajay and Akshay for having me clarified on some of the Shader related doubts I had. Do try the following x64 release build
Right Arrow -> Move Right
Left Arrow - Move Left
Up Arrow -> Move Up
Down Arrow -> Move Down


[Starting position of square]

[After Movement]