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.

Getting back into schedule

I haven't been blogging lately because of various assignments and midterms. I now have a brief window of time where I can catch up on both my blog and my own personal time, and then it's off to MIGS.

Modeling Update
The geometry in the model is pretty much final. There may be a few tweaks here and there but the main task these past weeks was unwrapping the model. I wanted to get the assignment done as early as possible because it was due on the same day as the midterm for the engine design course. To my surprise it didn't actually take long at all. Sitting down for a couple of hours and Maya actually didn't give me any trouble whatsoever, it was a miracle! Working very systematically made this a really productive session.

An overview of the entire model, showing the relatively stable pattern of checkers around the entire character. Mudbox will make this more awesome!

UV layout of the character. I've tried to make it so that every shell corresponds to either the left or right side of the body, with a few pieces here and there.

Shaders
I've been poking around in Nvidia's FX Composer, and did find out some pretty neat stuff. First of all, I've actually figured out how to make your own variables such as just floats as well as loading in textures and making it usable with corresponding UI widgets for easier modification. This may sound very simple and kind of dumb, but just figuring out how to get stuff to display and how to properly make variables teaches you a lot about the shader production workflow and how the structure is actually laid out in the Cg/HLSL language.

The very first thing I did is load up a 'Phong_Bump_Reflect' material and looked around in the code to see what was happening. I asked Derek Fullerton for some help with the program, and we figured out how create and modify your own textures/variables. We played around with some of the settings and added some things such as a specularity map to our sphere which resembled the earth. I later tweaked this and used the same texture for an opacity map, and a 'reflection map' where only the water on the earth reflects the image.

You can see that only the water shines and reflects, all using a specularity map.

Here I used the specularity map as the opacity map, and made the value semi-transparent. You can see some odd artifacts to the left side of the Earth, but that's probably an issue with how I am using blend modes.

I realized that if any of our efforts using Mudbox will actually be useful, these shaders will have to do their job properly. One of the hardest and most puzzling things right now for me is figuring out how normal maps work. They work here in the Cg file, but it's been pre-done for me so I can look at how it works. I hope this is one of the things we could possibly go over in either class or tutorial in game engine design. More so of the actual math and theory behind the shader, because I am fairly confident that I could load in a normal map and all the necessary variables, I just wouldn't know what to do with them in code. For example, here is where the magic happens in this Cg shader:

         float3 bump = Bump * (tex2D(NormalSampler,IN.UV).rgb - float3(0.5,0.5,0.5));
    Nn = Nn + bump.x*Tn + bump.y*Bn;
    Nn = normalize(Nn);

I know that the 'Bump' variable is the strength of the bump, the NormalSampler is just the actual normal map in memory, but I'm not sure why the .rgb values of the entire image are getting subtracted by half (the - float3(0.5,0.5,0.5)). I know that the normal is then modified using the normal, world tangents and the binormal (whatever that is) using the normal map's UV values. I just don't know how I would go about getting this information (the tangents and binormals specifically), or what these values actually represent. I guess I'll try wikipedia later, or ask a professor when I am trying to do the homework questions.

Getting this working is quite important because a lot of what we are going to do for the modeling class assumes that we can somehow have normal mapping in our game. Of course, I am also interested in getting them working for just its own sake, and because things will more impressive if I do!

No normal map

Normal Mapped.
You can see the difference a normal map makes in terms of detail, especially so on a character like the one in the above section.

I've also fooled around with some other effects from Nvidia's shader library. Things like the post glow filter added a sort of 'atmosphere' around the earth. It looks off because the atmosphere is still lit where the light is not hitting the Earth. That could be easily fixed by also applying a diffuse value over the expanded geometry, so only the parts that are getting hit with light will respond with the blue glowing edge.

Earth with an atmosphere, albeit a kind of fake looking one.

The other shader effect I tried was post radial blur. This is a really neat 'motion blur' -ish effect, where it looks like you are moving really fast. It has some cool values that you can tweak, like the direction of the overall blur, its starting position when it blurs and how far the blur expands over the screen. This shader uses a similar method as the HDR shader talked about in class, but only in terms of render-to-texture. All it does is render the scene to a texture and apply a blur with the parameters chosen. Still looks cool though.

Programming plans

Working on the homework assignments familiarized me with the engine, but I still think I need to mess around with the code to really get a grasp of what's going on. I guess that's not really an accurate way of representing my confusion. With me, it's more that I don't really know that certain features of wild magic even exist, and when I try to do something they blindside me. I'll have to read the book more, and practice doing random things in wild magic before I can start helping Dan Cortens structure proper UML and try to use the design patterns talked about in class wherever they make sense.

November is our 'go month', where we usually gear up and go full steam ahead. Unfortunately, as hard as we try to get the game started early, there is just either not enough knowledge or time to actually do anything productive. November is around the time where we know enough to actually start doing something meaningful, so the plan is the day after we get back from MIGS, we will start having more regular group meetings and work on classes, art and design aspects of our game. In my point of view this is not necessarily a bad thing. If we focus on learning concepts in the first two months, we are more likely to grasp this knowledge more quickly an efficiently. In doing this, we can design our code and game smarter if we start later, rather than trying to haphazardly hack things together that may or may not make sense right away. At least this is my justification for our relatively late start. I know we learned that starting early and starting small are very good ways of going about building games, but in this case, we are learning as we go. We are building our airplane while we are flying it, so to speak.

Update: Model and early code problems

Modeling Update

I've learned several new things since last week and my progress is pretty much summed up in the below pictures.

Don't mind the lips, they are still a work in progress

The face was surprisingly much easier to model than I thought. I expected to push around vertices by the hours, and instead, with just a few moves here and there from the initial sphere, the basic shape of the face was already in position. Of course it definitely was nothing too spectacular, as it still looked extremely blocky, but the critical thing here is that it let me visualize the face very easily, and much faster than I thought I would have. Unfortunately I did not foresee to take pictures of an in-progress work before this one, but it was just a basic shape at the time, so I thought it was nothing special.

Comparison between the 3D model of the face and the reference sketch

I have completed the basic anatomy of the character, which helped me understand proportions of the human form, so I could model other details around it. The point being here is that the anatomy was definitely the most difficult part to model (especially the chest, armpit and back area), and once that is over with, details will be of no fuss. The above picture shows that the 3D model is not exactly a true replica of the original sketch, but some of the features of the face just did not make any sense when put into a 3D context, so I changed the structure of the face a little to make it seem more believable.

As mentioned before, I have modeled the pauldron, vambrace, loincloth and the ornament in the middle in one fell swoop, and most were relatively simple except the pauldron. It was an awfully confusing encounter because for some reason I could just not get the idea that the pauldron was just essentially a rectangle in a curved shape (this is where shading on the original sketch would have helped). I tried several different ways to model it, like making several layers of material underneath the main layer, and I tried making it look rounder, but in the end I ended up with a much simpler model. I scrapped those ideas for now because they were taking up too much time, but now that I've moved on from detail, and onto the face, I may get back to the pauldron after it is complete.

Problems Arise

On the code front, I've been trying to push myself to start understanding Wild Magic and the results are less than successful.


My initial thought was to just jump straight into the hard questions (specifically, shaders, as I think I am the person in my group that will be responsible for such things) and it was just incredibly difficult to even know how to begin such a task. I asked the TA in one of the tutorials about how shaders are implemented in Wild Magic, and I received a complicated and worrisome reply. In OpenGL, it was a rather simple task, where you simply wrote whatever code you wished, and passed that code to the program and the shader code would just execute as you told it to. Very simple process, albeit probably primitive to a professional work flow, but it worked. It dawned on me that WildMagic will not simply let me walk in and do whatever I want. First of all, the shaders are in a different format, although this isn't really a big problem, it's something to think about. The main issue here is how does WildMagic intake, use and compile these shaders? The TA said something about using a specific compiler to concert the shaders to a specific format before use, and that they had to be created in FX Composer.


At this point, I decided to just dig around in the code and the various include files that stemmed form the 'mainGame.h' file. This was counter-productive, as searching through headers and trying to understand what everything meant just confused me even more. Maybe I just didn't spend enough time with it, but the more and more I tried looking, the more I got confused. What I got out of this is that having such a complicated tool at your disposal is a very daunting thing indeed. I tried looking through the book for a brief while, but only found the theory on shaders (which, for the most part, I understand), but nothing arose about the actual code implementation of the shader in the chapter. Maybe I was looking in the wrong place, but for now, it is going to be irrelevant due to my conclusions from this little information hunt.


I've concluded that jumping into the hard questions would waste a lot of my time, and just put a lot of stress on me. My group members for the most part, felt the same way. Our decision was that each group member will begin with similar if not the same easy questions first. The rationale is that we form a sort of 'supporting net' where each one of us goes through the very basics of the engine, and as we learn new capabilities, facts and become more experienced, we share this information with each other to help us get a tighter grasp on the engine. After the midterm for this class, we will branch out and attempt to have each group member do something different so we have the maximum possible spread over the questions, which will no doubt help us in the end. I'm not sure if a nightmare question will be worth it yet, as we don't really know much about the engine right now.

Concept and Design of Maegnos

Our game has a title now: Maegnos. Seems to take inspiration from Greek or otherwise similar roots, but also sounds like the English word 'magnet'. Kind of packs a lot into the title, already suggesting at both the mechanics you are about to experience, and hints a little at the art style of the game.

Rough concept from Sedona

The above illustrates both the character concepts and the logo concept the will most likely not change from now on. I'll delve into specifics about the game later.

Team Update

Not too long ago, we received a new member to our group named Dennis. He seems to be more oriented on programming and is already suggesting ideas on how to approach a simplified collisions system and a rendering optimization. Although I'm a little hesitant to accept both because we don't need to be thinking about optimization now, especially when we barely have a code base to work off of. Again, same thing with the collision system. Until we figure out how Havok does what it does, or at the very least what it can take care of, then I think we should worry about focusing on studying the structure of wildmagic++, and exploring the options WM++ gives us.

Mark Duarte is another group member that recently joined us, who also seems to be focusing more on programming and similar fields. We haven't heard much from him, but things should pick up pace as we start to dive into production. 

With these new group members, communication could be an issue so Lindsay created a website not too long ago, of which 4 of us are members so far. The 4 core members are friends and know each other well, so the Skype group we have now is mainly filled with chatter amongst us 4, and some work related chatter sprinkled in between. The website allows us to go to a place dedicated to the game, so we could discuss everything improtant there, rather than forcing people to read through our nonsense to get to the important stuff.

I'll keep posting regular blogs here, but stuff from me that will appear on that website will either be a summarized version of the blog posts here, or an announcement or talk about a feature for the game.

Click here to go to our site.

Overall Game Concept  

The game so far is to be a 3D platformer that invlolves lots of puzzle solving and combat. The main mechanics revolve around the theme of magnetism. Every single object and even some plates of wall either have a positive, negative or netural charge. They react as expected, if an object is charged enough it will start attracting/repelling away from the player, which can be used to manipulate the environemnt and solve puzzles. Massive objects and plates of charged wall will instead attract/repel the player for some interesting options for traversability.

In terms of combat, the player will have a staff to defend themselves with. This is also the staff that allows the character to manipulate objects with the force of magnetism. Enemies have the three states described above, and this will have some interesting impact on the combat. As a standard, there will be a light/heavy attack variation, although depending on the implementation, the heavy attack may just be a finisher to a combo or something similar. Swinging attacks with an opposite charge (say positive to negative) to your enemy will do extra damage, because the opposite charge attracts the enemy to your staff, and helps deal extra damage. Swinging with the same charge helps push enemies away from you so you don't get overwhelmed (also helps space enemies out for combos). Heavy/finisher attacks use the same notion, just ramped up. For example, using a positive finisher on positive enemies will send them flying away from you, while doing the same on negative enemies will suck them in and do much more damage.

As a side note, as mentioned in the last blog, my ideas will probably be heavily influenced by the fact that I wanted to do a fighting game. Unfortunately, puzzles will be implemented first, with the addition of combat later, so if anything happens, combat is the first in line to the cutting room floor. Not all of combat however, just specific and/or advanced features of combat.

Character Concepts

The character that I am designing right now will be a sort of 'Mentor' to both the characters in the game, and to the player. Relating to the characters, he is older than them and acts as an elder/supervisor of their journey to prove themselves on their rite of passage. Towards the player, this will of course be a voice to guide them on how to use the various features of the game, and maybe even help them solve some early puzzles.

Turnaround for the 'Mentor' character

I wanted this character to be less stereotypical 'old man' with robes sort of mentor, rather he is a retired warrior who can still be helpful/athletic if he needs to be (we haven't figured out how to stick him into actual gameplay yet).

My progress on modelling him so far can be seen below. My current issue is that I think I have too many polygons for a 'low-poly' model. Especially when I try to attach the hands to the body, which will raise the total poly count pretty significantly because of the edge loops that need to run throughout the body to maintain detail. I still need to do the face and feet, and the details (like the pauldron, knee pads, loincloth, middle ornament and vambrace) to complete it, but the main anatomy is complete, working from here on should be easy enough.

Finishing Thoughts

I know professor Hogue said that these blogs also provide useful feedback about where we are struggling, and what we have issues with, so in later blogs I'll dedicate a subheader to the topic. Other than that, I'll be posting next week.

Game Concepts and Planning

This passing week and the previous were about coming up with an interesting concept for a game to work on for the 8 months that we have this year (obviously). The good news is that my group (Dan Cortens, Lindsay Mikula, Sedona Parnham) started planning immediately, or as soon as all of us actually moved back to Oshawa. Learning from last year, we don't want to have to always wonder about what game mechanics are going to be possible, and what is officially in the game and what is not. We are going to start following our own advice that we gave last year at the presentations, where mainly we start small, start early and hopefully avoid missing out on hours of wonderful sleep (I've grown to cherish it now).

The bad news is that Cortens and Sedona wanted to do a 3D puzzle game and me and Lindsay wanted to do some sort of fighting game. There was discussion on strictly going one way or the other, and it wasn't really going anywhere, because two people would think of concepts for the puzzle game, while the other two would be more focused on realizing the fighting game idea. This went on for a while, mainly because we got conflicting information about which would be easiest to do. Some people told us that fighting games require a lot of precise collision calculations, and lots of other complicated mechanics. On the other hand, the 3D puzzle game has more physics intensive calculations, and its mechanics have to do with pushing/pulling objects and the player around using magnetic forces. Now, we don't usually pick the easiest way out (we were usually pretty ambitious), but in this case our philosophy for the rest of the year was get the basic mechanics out as fast as possible, and have time to make it polished enough to impress somebody who knows nothing about how games work (which is actually pretty ambitious anyway).

Our previous game, Raptor Racers, was quite an achievement for a group of students, and I'm proud of the work we've done. But arguably, to somebody who knows nothing about the underlying work required to make games, it wasn't really all that impressive. The AI was hilariously glitchy, collisions broke on people and the game just had hosts of issues, bugs and other annoyances. At the TIFF last [school] year, if the game happened to be feeling in a glitchy mood, people would just raise an eyebrow, laugh a little and then walk away not looking too impressed. I realized that the hard work, the technical achievements, the prestige that comes with trying something more complicated (building game from scratch as opposed to just using unity) doesn't really matter in the end. The end product is what speaks for you, and in order to really wow somebody, we're going to have to both push our own creative limits yet again, and hopefully squeeze in enough time to polish the game to make it respectable in its own right.

But enough of being pessimistic, the bad news did get resolved at the GDW on Monday this passing week when the themes were given out. The 3D puzzle game already had many game concepts already thought of, and it seemed to be more of a solid idea rather than the fighting game. The fighter was more us picking a genre and trying to go from there. The theme we picked was colour, which can go very easily with the puzzle game, but sort of harder to incorporate into a fighter without a proper concept first. In my opinion, a colour themed fighting game would be really cool (like having 4 fighters represent the 4 elements, and by extension having their own colour), but at that point, the rest of the group was essentially rooting for the puzzle magnets game idea, and I'd be the only one pushing for a fighter, so I just decided to let it go.

Next week, I'll probably blog about actual concepts for the magnet game, and my expectations and ideas for it.