Last week when doing texture and point light assignment, I kept asking myself why should we write our own vertex shader and fragment shader? All the tutorials I found online didn't use any shader. Before I asked in class, I had already got the answer: because we want to use different effect in a scene! And I proved my own reason in this assignment by using different fragment shaders in my scene.
Frankly, I created two more fragment shaders not only to prove my own theory but also to test my effect file input, I created two more fragment shader. While the light computation is the same in those three fragment shaders, the colour output is different in this manner:
- example.hlsl: show the texture applied on the mesh
- plain.hlsl: show ONLY the colour of the mesh regarless the texture applied to it
- shiny.hlsl: show the blended texture and the colour of mesh
This is how my boxes looked like with three different fragment shaders:
Three boxes with different fragment shaders
It is really interesting to see how different treatment of colour and texture give different effect on the box.
The boxes under cyan coloured light exposure:
Three boxes under cyan light
In addition to colour, I had also added the light intensity into the scene.
Three boxes with half light intensity
The boxes in the scene located in three different places. From left to right (-3,0, 0.0, 2.0), (0.0, 0.0, 0.0), and (3.0, 0.0, 3.0). The trick to draw the boxes without over-used the fragment shader is by using Z buffer. When EnableAutoDepthStencil is enabled, DirectX will check whether current fragment is behind the fragment that has already been drawn. If it's, then it won't be drawn. Otherwise, it will be drawn.
The boxes in 0.98 depth buffer render with PIX
I added 4 more text parser each for scene data, entity data, material data, and effect data for this week assignment. I had also rewrote my previous mesh parser into a nicer and more manageable function flow. I was battling myself whether I should use a simple input or add the half XML-like input. After thinking for a while, I decided to use half XML-like data. With this XML-like input, the input data order is not restricted. Now with this new parsing method, I won't be bothered anymore if in the future we have to add more data. :)
This is the format of my scene data which state the general information for the scene like the entity in the scene (position, rotation, mesh), camera, and light:
<entity> -> start of entity data
# -> total number of entities
{ ->
start of entity data
<file> -> file
data opening
blablabla.txt -> name of file where the entity data
can be found
</file> -> end of file data
<position> -> position data opening
x, y, z
</position> -> end of position data
<rotation> -> start of rotation data (entity facing
direction in world)
x
</rotation> -> end of rotation data
} -> end of entity data
{
...
}
</entity> -> end of entity data
<camera> -> start of camera data
<position> -> start of position data
x, y, z
</position> -> end of position data
<lookAt> -> start of look at data (camera
looking at direction)
x, y, z
</lookAt> -> end of look at data
<up> ->up data opening (camera up direction)
x, y, z
</up> -> end of up data
<rotation> -> start of rotation data (camera angle)
x
</rotation> -> end of rotation data
<aspect> -> start of aspect ratio data (aspect
ratio of camera)
x
</aspect> ->
end of aspect ratio data
<near> ->
start of near view data
x
</near> -> end of near view data
<far> -> start of far view data
x
</far> -> end of far view data
</camera> -> end of camera data
<light> -> start of light data
<position> -> start of position
x, y, z
</position> -> end of position data
<colour> ->
start of colour data
r, g, b (0-255)
</colour> ->
end of colour data
<intensity> ->
start of intensity data
x
</intensity> ->
end of intensity data
</light> -> end of light data
The format of the entity data which stated the mesh and the material:
<mesh> -> start of mesh data
blablabla.txt -> name of file where the mesh data can
be found
</mesh> -> end of mesh data
<material> -> start of material
data
blablabla.txt
-> name of file where the material data can be found
</material> -> end of material data
The format of the material data which stated the texture and the effect:
<effect> -> start of effect
data
blablabla.txt
-> name of file where the effect data can be found
</effect> -> end of effect data
<texture> -> start of texture
data
blablabla.png -> image of texture
</texture> -> end of texture
data
And finally, the format of the effect data which stated the vertex shader, the fragment shader, render state (undefined yet in this assignment), and the texture mode:
<vertexShader> -> start of vertex shader data
blablabla.vp -> name of file where the vertex shader can
be found
</vertexShader> -> end of
vertex shader data
<fragmentShader> -> start of
fragment shader data
blablabla.fp
-> name of file where the fragment shader can be found
</fragmentShader> -> end of
fragment shader data
<renderState> -> start of
render state data
#
</renderState> -> end of render
state data
<textureMode> -> start of
texture mode data
diffuse_map/environment_map/normal_map
</textureMode> -> end of
texture mode data
The real challenge for me in doing this assignment is how to send the light parameter to fragment shader? From last assignments, I learnt how to send the matrix, float, and float array data into shaders. The constant method itself doesn't give me an option to send the colour as D3DCOLOR, which is the type I used in non HLSL program. After searching in internet for a solution without any result, I came up with the idea of re-mapping the D3DCOLOR. In the "d3d9types.h" header file, I saw the way D3DCOLOR constructed is by mapping the RGB and alpha value: ((D3DCOLOR)((((a)&0xff)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff))). Thus, what I need to to is re-mapping it to get the RGB value I needed and send it to shader as float array. Oh, btw, yes, the size of D3DCOLOR is 16 byte.
There is something that still bugging me with my program: the memory leak! From the Game Engineering class, I learnt that it's better not to have memory leak in program especially game. So, I tried to keep that good programming practice in this class, however, I can't get rid of the memory leak caused. When we created a variable in C++ using new, malloc or _aligned_malloc, we have to delete it manually, right? I did that but it seems not working at all. This is really strange. I shall spend more time next week debugging this memory leakage although this is not part of the requirement of this class.
There is something that still bugging me with my program: the memory leak! From the Game Engineering class, I learnt that it's better not to have memory leak in program especially game. So, I tried to keep that good programming practice in this class, however, I can't get rid of the memory leak caused. When we created a variable in C++ using new, malloc or _aligned_malloc, we have to delete it manually, right? I did that but it seems not working at all. This is really strange. I shall spend more time next week debugging this memory leakage although this is not part of the requirement of this class.
On, the control of my light and camera is still the same as previous one:
[W][A][S][D]: camera control
[UP][DOWN][LEFT][RIGHT]: light control
No comments:
Post a Comment