Rendering

c_Stage

The object to hold the stage, of which there is only one. This is a parent class to all classes that rigidly define a stage, and a stage is loaded by declaring such a class.

As an example: c_Stage stage = new StonyRuins() //where StonyRuins is a class derived from c_Stage

3dObject

A class designed to hold all pertinent information about a rendered object. This currently includes an array for vertices, an array for faces, textures and texture coordinates.

3dObjectList

For ease of rendering, a compiled list of pointers to every object in the scene will be maintained. This will include all objects from the stage (Pulled from the c_Stage object), all player sprites and projectiles.

Object Loading Pipeline

Preparing the stage

Assimp (assimp.org) is a free and open source utility that we are using to get our models into the game. I have found troubles in throwing in .blend files into it, but .x files work. So all models must be exported to DirectX; this can be done in blender through File->Export. Files should be placed in the folder of the respective stage, found in the "Models" folder.

The number of files must be accurately kept in a #define within the stage's class. The only other information needed is the names of the files, held in an array of strings that the loader must cycle through.

++Loading objects

The engine will iterate through the list of files, and load them through AssImp. This happens in the class derived from c_Stage.cpp (Eg: StonyRuins.cpp). Once loaded, information will be extracted, such as:

Vertex Positions
Faces
Materials
Normals

This will all occur in a call to GetObject, found in c_Stage.cpp. An empty object will be sent with the function, and will be built by it.

As well, the object must first have it's arrays initialized, which is handled by InitFaceArray() and InitVertArray().

Materials

All meshes will be split according to the materials use. If a Mesh has 2 materials, it will require 2 vertex arrays: One for the first material and one for the second. This is partly a result of how AssImp handles matters, as the mesh is split upon retrieval by AssImp. And partly since I (Chris) cannot fathom a more efficient way to handle this at the moment and do not wish to fix anything not broken.

Meshes with multiple materials will still be held in the same c_3dObject object: vertices are held in a 2 dimensional array, separated by material. A material's index can be used to identify the column holding all vertices of the relevant material.

Vertices/Normals

An array of vertices will be pulled from the object, and all corresponding vertex normals will be collected at this time. The engine defines it's own vertices in a struct called, appropriately enough, "Vertex." This holds the positions and normals, and may collect additional vertex-related information in the future should it be warranted. InsertVertex() is used, once per vertex. This function is a member of c_3dObject.

Faces

Faces are pulled and stored in a two dimensional array to account for multiple materials, much like vertices. InsertFace() is used to insert faces one by one, and is a member of c_3dObject.

Filling the variables.

There are three loops nested together to accommodate this: One for Materials, and two more inside for vertices and faces, respectively. First the Vertices/Normals are passed into the object, then the faces. This is repeated as many times as the object has materials. Once the object is complete, MakeBuffers() is called on the object to finalize it.

Generating the buffers.

A vertex buffer holds vertex information in memory so it can be quickly accessed. This is pretty much mandatory for a real time system such as this. My solution has been to have a buffer for each object, so that buffers can be hotswapped by the program to rapidly render the entire scene. DO NOT MAKE THE BUFFERS BEFORE THE OBJECT HAS BEEN LOADED WITH ALL INFORMATION. The world may end if you do. Even if you luck out and that doesn't happen, I promise the program will bug and crash.

Rendering Pipeline

Given a stage, the program will set up the proper material, then swap to the relevant buffer to print that object to the screen. If there are multiple materials, it will iterate through them all until the object is done before moving to the next one.