Ambient light, specular light, and material ordering

It is absolutely worth the hours (> 10 hours) I spent to finish my previous assignment. I improved my file parser so that I can add or remove item easily, which in this assignment I proved to be working. I had also spent some time to restructure my mesh and scene to make it easier to add more entity in the world.

For this assignment, I used a mesh as my floor instead of hard-coded it in the program. I also added a light-interpretation mesh to show the position of my light. Before I added the light-interpretation mesh, it's hard to tell where my light is. Now with a small square representing the light, I can tell where my light is.

I created two new effects for my diffuse light and diffuse+specular light:

• diffuseEffect.hlsl: calculate only diffuse (+ambient) light
• specularEffect.hlsl: calculate diffuse (+ambient) light and the specular.

My boxes under white light

My boxes under cyan light

Yes, I used two different boxes. One with correct normal (24 vertices) and one with position of the vertices as the normal (8 vertices). It is really interesting to see how different normal gives different light effect on the object. The attenuation of the light is not really apparent in the box but it can be clearly seen in the plane which use the diffuse effect. Btw, the small white dot and the cyan dot is the representation of light in my world. And, to show all of my boxes in a screen, I moved the camera a little bit further to position (0, 0, -15). Furthermore, I disabled my meshes rotation which make me dizzy after looking at it for a while with rotated plane.

Also, to be able to see the boxes closer, I added z-direction movement into my camera - making my camera control:

[W][A]: move y-direction
[S][D]: move x-direction
[Q][E]: move z-direction (Q: +z, E:-z)
The camera looks funny after I moved it z-directional. I believed it has something to do with the mathematics I used. I need to improve it.

I still keep the light control: [UP][DOWN][LEFT][RIGHT]

In addition to the lightning, I also do an optimization to the drawing call. Before I mentioned how I do the drawing procedure optimization, I want to write down JP's answer to my question last week about why we have to do so many file parsing. In Game Graphics, renderer is not the only important things. The data control is also important. In game the most important thing is the data flow - more than people think. In Game Graphics, we have to worry about data - where the data comes from and how it goes -to the system. In the other words, we have to be responsible of the data flow in graphics. The better the data flow we have, the more prettier picture we can draw. Now it makes sense to me why we have to create our own file and the file parsing. Without even writing one, how we can improve our data flow control skill?

Advanced from the previous assignment, in this assignment we need to do a better drawing call procedure. The effects, materials, and entities need to be grouped together so that we can minimize the state changing. Doing state changing in graphics is expensive especially the vertex/ fragment shader.

Thanks to my own effort for the previous two assignments, I can do this optimization faster. All I have to do is create an asset database which holds all the vertex shader, fragment shader, mesh data, material data in the world. This asset database, then, is accessed by mesh. In previous assignment, I have one mesh class for every entity. Now there is only one mesh in the world who take care of the drawing of all the entities in the database. For this purpose, there must only one asset database in the world. Therefore I reused the utilities I created for my Game Engineering class:

• Singleton: to make sure there is only asset database instance in the world
• StringHash: to hash the string name input for later comparison
• SmartPtr: to ensure there is no memory leakage when passing my asset when it created and stored in the database.

After I stored all the assets (entities) into my database, I do a multi-level quick sort from the less expensive state to the most expensive state. Then before drawing I always check whether the property of this asset is different from the previous one. If it's different, then I won't re-setting the property, otherwise I will set it again. For the moment, I did the grouping in this order (most expensive to less expensive): fragment shader --> vertex shader --> material --> mesh.

Draw sequence in PIX

When the mesh stream source is updated and not updated

As it can be seen, I only set my vertex shader once per frame (all of entities use the same vertex shader), I occasionally update the fragment shader, material, and the mesh.

There is still a space for better optimization, though.

(1) I use quick sort to do the grouping. Since I did it 3 times, the average time is 3 * n log n.

(2) There is 11 same vertex shaders in the world even though I only use it once. I can improve this by loading every used properties only once and use a map to connect each asset to the correct property.

Oh, I had already cleared all my memory leak in this program. However, there is still something funny. When I really do have a memory leak, it will be dumped twice. Now even though I didn't have it, there is still memory leak dumping. How did I am sure that there is no memory leak? I traced my code to ensure all memory was released before the code is terminated. Anyways, I am pretty sure that there is no memory leak in this code.

Source code