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.