Coming Along

This blog was written when I was relatively tired, and working pretty late nights. Half the things I say might not make sense, just a disclaimer.

Normal Maps
Normal maps was the most recent thing I have accomplished, and it took me quite a while to get working. I have tried exporting the .cg files straight out of FX composer (FXC) but that is not how that works. After you have fooled around and got the effect that you want in FXC, you have to extract the most important and necessary bits out of the code. Half the code in the actual file is for FXC itself so it can use your shader in it's display window. They use a very different structure than I do, it's more complex but probably more efficient (like having all of your IN/OUT data in a struct, and passing that to the function). In the end though it doesn't really matter, the shader does what it's supposed to.

Before we were given the code in one of Prof. Hogue's lectures I studies how Normal Maps worked, and they're actually not that bad in terms of complexity. I also looked at the simple bump mapping example in the wild magic examples, and the way they did it is rather silly. They do most of the computations per vertex not in the shader, which is quite strange  When I saw a much simpler version in prof. Hogue's lecture, then I knew most of the difficulty would come form working with WildMagic. Since I had the actual shader code from the slides, all I had to do was set up the shaders properly and acquire tangent information from our models.

I was rather sneaky when it came to getting the tangent information, as I figured out that the Havok filter manager has an option where it can compute and export tangents for you. Great news, now I don't have to do all the complicated math myself! That's handy, but unfortunately it wasn't as simple as I'd hoped. This was because the WmPPMayaLoader class was not tailored for taking in tangents & binormals. I did some poking around, and figured out how to extend the loader so that it looks for and properly stores that information. After I had all of the necessary information, I reorganized the way variables were bound to semantics, specifically the vTangent, vBinormal and vNormal variables. They were bound to TEXCOORD#, but instead I bound them to the proper semantics. Cg has semantics for NORMAL, BINORMAL and TANGENT, so I didn't understand why texcoords were being used, it didn't really make sense to me. The only extra things that had to be done was to pass the shader the light direction (obviously) or else it won't know where the light is coming from to do the lighting calculations properly.

Update: I noticed the lighting actually doesn't really work for normal mapping, the light is somehow rotating with the object, which shouldn't be happening...

Don't mind the planets, this was done in a previous homework assignment, but the normal mapping works!

Fullscreen Shaders
I looked at the OffscreenFBO example that was provided to us by prof. Hogue, which took me a while to understand. Since everything was dependant on everything else to work except the OffscreenFBO class, I decided to just extract that class and use my own shaders on it.

Trying to figure out which order to call the functions was the hardest part of trying to get this to work. Basically the FBO needs to be initialized with a bunch of important variables, like the renderer, width and height of the screen and the texture name that it creates from the scene (so you can use it in your own shaders later on). The next step is to add your own shader to the scene and attach it to the FBO by using the setShaderEffect function. Mine just adds 0.5 of red colour to every pixel on the screen, nothing too spectacular at the moment.

The next most important part is creating the camera that will actually look at the FBO once the scene is rendered to it. It is an orthographic camera with the frustum set to the size of the quad, (basically from 0 to 1) so it gets the entire quad in the screen. Once that is set up, you have to start rendering to the FBO, switch to the orthographic camera, draw the FBO then switch back to the original camera. If you don't switch back, then the quad will have a texture of itself on it, which doesn't make any sense, and doesn't give any usable results.

Nothing spectacular yet, but it works

Here it comes

This blog post will be very brief, as not a lot happened post-MIGS because we were bogged down with doing assignments for classes. These past few weeks have been extremely slow, and I don't know how I lost so much momentum when I was doing so well before. I remember getting the shader stuff done a while back, but I have been too busy with other classes and assignments to put my full attention on the game. It should have been the other way around, but unfortunately I would not have done well on any other assignments if that was the case.

Despite the loss of momentum, I still managed to paint my weights correctly, after restarting once. So my skeleton is ready to have proper IK handles bound to it so it moves correctly. I presume that will not take that much time, as most of the tedious work has been done.

Now that the game is due very, very, very, very, very soon, the stress is hitting us like a freight train. One thing I don't understand is why is Derek's final GDW submissions a week after the actual game is due? That doesn't really make any sense, as the levels and characters have to be done for the game in order to complete the requirements list, but will be handed in a week later? I'll have to ask someone about this on wednesday.