Final Stretch

The last week (maybe 2?) of classes is fast approaching and it's crunch time to the extreme. Our studio has to pass the second GDW gate next week, keep working on 3 reports, a sound project, and independent architecture, accounting, and graphics homework. That's a lot to keep track of!

Ambient Occlusion attempt

I tried out some AO in Maya the other day and it turned out pretty sweet. The model was not created by me originally and I hadn't realized that the normals weren't softened first, so it turned out a little liney. I would've done it again (and will do so if it's used in our game) but it took about 15 minutes to render the first time and I had things to do :-P The nice thing about AO, at least in it's most basic form, is that coding it is so easy; just multiply the AO texture by the regular diffuse texture and it deepens the shadows quite nicely. Except for those darn lines!

Assembly... gah

On another note I've also been working in MIPS assembly for my Architecture class. It had.... one hell of a learning curve, I'll give it that. I'm still a little shocked I got it all to work. Basically, I did a whole bunch of research to do this first as I was making a class that accepted an array, size n, and int x. The program goes through the whole array and adds to a sum if array[i] is equal to x. EASY stuff in C++, C, heck even in Flash, but in MIPS it was extremely tricky to wrap my head around for a long while. This isn't all the code obviously but it's the bulk of the for loop and if statement. It was kind of relaxing to work in a lower level code though to just look at something different and try and solve a super simple problem with a lot of hard work, just like coding in C++ used to be when I was learning it.

That's all for this week. Back to working on... everything!

Sudden Progress!

Finished dragon head (tada!~)

My little pride and joy, this dragon head. I finished it in only like 3 days, so while I'm sure it could have some better geometry a better method of having the jaw open then making it a seperate object I'm super happy with what I came up with in such a short time. I hope to bump map it all over the place as this enemy is going to be nearly the size of the scree and such a detail would really make it pop.

Other than this lovely model I've also been working hard to incorporate normal mapping into our game while accounting for multiple normal maps for different objects. The way I worked around this small problem was by changing what texture was at GL_TEXTURE2 (which is being used for normal mapping) before rendering each individual model. This way the right normal map applies to the right model. There may be a better way of doing it, but this certainly seems to work just fine :-)

Our studio also finally reincorporated the menu we had so long ago but haven't seen in months because of this semesters reframeworking. Now it's back! This week I'm focusing on normal mapping all of our models, even if that means loading them in Mudbox and creating a 'blank' one for our game to load, as well as helping out with the creation of the boss level. Busy week!

but always time for music

Steady Progress

Tangent Normal Shader

It's been yet another hectic week as I finished up my last midterm (finally!) and have started programming and modelling like mad. I've been trying to focus a lot on some Graphics homework questions to try and get them out of the way and potentially into our game before the end of the month. For the past couple of days I've been working on a normal map shader as seen above. Oddly, I found making one in tangent-space easier then one in object-space, but that must be because no one in online forums has any advice for object-space. Kind of shows how tangent-space is better!

Shader Code~

The code above is pretty simple for creating normal maps, or at least a lot more simple then I would have anticipated. Obviously, the normal of the point is what is affected, which in turn affects how the lighting is calculated for that point. Using the position and the texcoord of each point, the tangent is found pretty easily (credit to imbusy from http://www.pouet.net/topic.php?which=6266 for the calculation of the TBN matrix). In order to return the normal to world-space from tangent-space multiply the Tangent-Binormal-Normal matrix by the normal map that was created earlier in the code. This way the normal map applies to each normal, insuring the light is affected in the way the normal map intended.

Final Boss - WIP

Aside from some rather frantic coding I've also been doing a lot of last minute model work. Above is the dragon head I've been working on as a final boss for our game. I still have to add the teeth to the bottom jaw and sculpt the inside of the lower mouth, as well as whip together a simple texture, but I'm super happy with how the upper head turned out so far! If time allows I'm also going to give him some head armor reminiscent of our main character, but there is a fair chance I simply won't have time. I'm in charge of the whole boss level where the player gets eaten up by this dragon head and spends the level inside his body, dodging bones and ooze while trying to slash at his heart. That's a dragon head, heart, level walls, and falling bones I have to model in about 4 days if you weren't keeping count! I'm up for a challenge but this is a bit much on my birthday weekend :-P

This is the first model I've made with a functional mouth, so it's taking significantly longer than if the mouth was closed. By significantly, I mean I was finished modelling the base after 2 hours before I had to cut it in half and keep going. It's lovely practice though and I appreciate any chance I can get to try something new in Maya, so I'll persevere I'm sure!

Long Time No See!

It's been too long~

It's been quite a while since I last posted anything, my bad! I took Reading Week off to study, unwind, sleep; the usual. After that was the week of midterms and I just completely forgot about blogging. I'll try to make it up this week and, now that I've remembered about blogs, I certainly won't miss another one! (we hope)

Mole Enemy

This week I've been pretty busy in trying to create some more content for our game. I mentioned on a previous blog that I'd been working on this little mole guy and he's now fully modeled and textured. I think he turned out pretty good and I'm looking forward to seeing him implemented in the game as the little nuisance I imagine him to be >:]

Bird Enemy (WIP)

 The other one I've been modelling for the past couple of days is just a semi-realistic, eagle-type bird I based off of some real photographs. I plan on texturing him in the same manner as the other enemies to help tie them together; vibrant colours, chunky textures, painterly shadows. He'll probably be a reddish-brown with a bright yellow beak and eyes. He drops things on the player, probably rocks, as he flies through the level and pesters the player. I seem to like enemies that really annoy our poor player, whoops.

Other than these two models, both of which I'm pretty proud of for different reasons, I also recreated the font for our UI and menus so they were higher quality and a little less... curly.

Screenshot of our Toon Shader

Toon Shader Code

Above is a screenshot of our protagonist model being lit with the simple Toon-style shader that our Lead Programmer Mark has been working on. It's not 100% definitely the shader we'll be using, but it looks pretty sweet! I think adding outlines would detract from the aesthetic of the game that we have going so far, so the other option would be a more realistic lighting over this Toon shading. We also plan on adding some form of bloom in game and rim lighting behind the main player, but we will definitely (read: hopefully) having the lights move throughout the day/night cycle that our backdrop goes through. The colour of the light will also adjust depending on the time of day, such as a cool, bright blue for night lighting and a vibrant yellow-white for regular sunshine.

The code is actually stupidly straightforward in how it creates the sharp contrasting shadows. Depending upon the degree of diffuse lighting on an area of the model if it's within a certain range, it's set to one value. ie if the diffuse value of a point is between 0.0 & 0.2, it is set to a factor of 0.2. This makes that sharp contrast between a 0.2 and a 0.5 area, for example, as there are no values in-between that remain visible. The colour of the light is also applied at this stage, and the specular calculated for the shiniest of areas.

All in all, our game is coming together nicely if at a slower pace then I'd like. But it's crunch month! If there's such thing as just the right motivation to finish our game, it would be known as Crunch Month~

Shader Experiments!

Yesterday I realized I sat down and worked on one shader for over 6 hours for one of the homework questions... when you look up from your monitor and the room is pitch dark it's time to take a break. The shader I was working on was actually very very simple, just a fragment based one that can implement a texture and a specular map. However, I was having a lot of problems because of the program I was working in that I still haven`t resolved.

I was working with OpenGL Shader Designer, a cool little program that lets you see how your shaders would look in realtime without having to write all the base code (viewports, rotation controls, etc.). It just lets you put some textures in there and loads up one of a couple of default meshes for you to work with. Super cool idea! Not so great in practice.

I continually ran into issues that I couldn`t resolve without access to the base part of the program (not the .vert or .frag) but that wasn`t included in the software, meaning I was constantly finding work arounds. The other problem was a lot of the syntax we learned in class had to be thrown out the window because the software works in version 1.8ish. It never actually said what version, but whenever I tried something from the newer version it would yell at me in confusion.

Final sphere result

So in the end this is what I settled on as being good enough. I was tired of working on it and the thought of trying to add in displacement/normal mapping... again.... *shudder*

I'm pretty pleased with it overall though, it's a fairly basic Phong shader that ought to have a specular map but for whatever reason doesn't show it. I honestly think that's a flaw in the software though, not my shader's code. I guess I'll find out when I get our TA to take a look at it on Thursday/Friday but it was such a pain in the butt I doubt I'll finish it up unless it's the easiest fix.

On the plus side, this has really helped reinforce all the practical stuff we've learned in Graphics this semester. Before yesterday shader programming was a huge mystery to me, not with the theory but the code itself. It still boggles my mind where this information comes from to get into the program but hey, who am I to argue if it works!

Code Screenshot (.frag)

I might as well talk a little bit about the code! I thought it's about time for a more hardcore blog. Rather than going into full detail, as that would take... a while, I'll just explain the basics of the program. In any shader that takes lighting into account, the 3 main types of light need to be considered: diffuse, ambient, and specular. Specular was what I dealt with most in this particular .frag as I was trying to implement a specular/gloss map. The map that I was using was loaded on line 26, with "vec3 glossTexel = normalize(texture2D(texture2, gl_TexCoord[0].st).rgb & 2.0 - 1.0);". This line gets the texture from within gl_TexCoord as a 3D vector, then normalizes it. Calculations are done to determine how the object interacts with diffuse lighting and how it's affected by the glossiness, and the specular lighting and how it's affected if the shininess is > 0.0;

Side note: f this is considered a 2/2 blog, and my other ones all aren't, please let me know! I'd really like to know what is being looked for in order to do well in this portion of the course, and without feedback we're all feeling rather in the dark. Even just a heads-up of how many points we all have so far would be super appreciated!! :-)

Another Day Another Post

This week I've been doing some work on a new model for our game, based off of our Lead 3D Artist's design from the start of the year. It's got a really nice silhouette and was a lot of fun to make without being as stressfully complex as the humanoid model I made last semester.

Mole Dasher concept

I've been modelling this guy and it's been nice to get back into Maya and remember everything I'd picked up this year. I was certainly rusty after a month and a half break but I got back into it soon enough. I'm not using my laptop right now or I'd take a screenshot of the model. It's all covered in reference colourful texture anyway so it's pretty bizarre looking.

I also did some more work on the backgrounds for the game. We plan on having a scrolling vertical background that fades from one sky to the next, like a randomized day-night cycle.

So far I've been mostly building up our assets each week, but school work for every class has had me (and the group) pretty swamped. I work part-time too, meaning I have very little time to work on our game. But when I do I make sure to do it in bulk! I'm planning on starting another model in the next few days, an enemy bird that drops bombs (maybe eggs?) onto the player. Simple concept that I think would be really fun to model. Legs & arms are the worst part of modelling for me, so anyway I can avoid them the better.

Time for GDW, guess I better get going!

Little Update

There's not too much to say this week and my notes aren't very good for a blog, so this one's going to be short and sweet! Sometimes it's nice to just get a few ideas off the top of my head onto paper rather than making this into some long-winded update or talk about notes for the week.

Tomorrow we have our first review in GDW for the Winter 2014 semester. So far our lead programmer has done a lot to improve our framework over the previous semester. I haven't had the chance to take too close a look at it as I've been busy setting up my frameworks for other class projects and homework (including Graphics!), but I have been working on plenty of other aspects for our group game. What I do know has been added is:

• .md5 file compatibility, a file type I'm not familiar with but that appears to make animation crazy easy (sweet!)
• implementing the new libraries we have to work with this semester
• incorporating FMOD for our sound class, and our sound .cpp (get it?)

Meanwhile I've been working with the other members of the group to get together some new ideas for obstacles and enemies we can incorporate throughout the semester. I don't yet have a sketch ready yet but my new enemy idea is a hawk that swoops by and drops an egg on the player to do some damage. Before the week is up I plan to have this enemy fully designed and in the beginning stages of modelling, as well as modelling a few simple obstacles that I can UV map and paint next week. Every little model helps, right?

Light Up The World pt1

Another day in class and today's topic is lighting. I think I actually talked a bit about lighting in my last post, so it's time for an in depth explanation as today's notes.

To start things off, why should we even bother putting effort into video game lighting. Don't you just need to see? My opinion is that lighting is an under-appreciated story-telling mechanic and mood-setter that can make or break a good game. It can hide model and texture flaws, direct the player onward, draw the eye, and be used just like in any good horror movie to obscure the player's vision for a good shock. The absence of light is at least as important as the presence of it, as an area without lighting makes the player wary when coming from a sunny plain and helps keep the player focused on their objective by obscuring the pretty but unnecessary distractions.

Most of what we learned last semester involved dynamic lighting meaning lights coded into the game that can potentially move around and be used as spotlights. Static lights are more simple but equally effective at directing the player. These lights have less/no maneuverability as they are "baked" into the textures of an object in Maya before it ever even sees the game. However in spite of their more permanent state, static lighting is very useful from a graphical standpoint by taking up less computational power to look good.

There are 4 types of light that I've learned so far. They are:

• Emissive
• tied to an object; ie a computer screen, glowing orb, etc.
• Ambient
• constant value of the scene's natural brightness level
• Diffuse
• difference of light between areas (ie shading) that's the object's position relative to the light
• Specular
• the shininess of an object based on the position of the viewer relative to the object

Some lighting concepts I'd love to see in Up All Knight are harsher shadows from intense spot lights (ie the sun), god rays, and drop shadows. All fairly simple concepts but ones that are new to me!

Skyrim screenshot; example of god rays & lovely coloured lighting

Unknown source, but I liked the motorcycle drop shadows!

Here ends Day 1! Looks like we're continuing on next class with the rest of lighting, ttyl~

Inspiration

After playing some of the next (current?) gen games on the PS4 and being a little in awe of some of the things I've seen, I thought I'd post some examples of inspiration that I'd love to see within our game. I'm sure I'll find some of it to be unattainable at my group's current level, but a girl can dream!

Assassin's Creed 4

This is Assassin's Creed 4 for the PS4, the game I've been playing most by far. It still has all the usual AC series problems from excessive snapping to buildings, to suddenly just not climbing. It's a little difficult to compete in a race/chase when you just.... stop. But those are problems in play mechanics, not in the graphics of this generally gorgeous game. Some things I particularly love and would like to incorporate into Up All Knight are:

• Fog/cloud effects; the further up you climb more often the player encounters foggy patches that obscure things around the player
• Lighting; sunlight that sparkles on shiny armor and backlights other objects
• Sun rays; seen below, these would be amazing as the player climbs, passes the sun during the day/night cycle, and gets little sun beams through the clouds ^_^

 

This is something known as 'Real Life' and Alan Wake

But before we can get to any of this stuff we have to build up our framework into modern OpenGL, a significant advancement from last semester's out-dated coding methods. By next weekend we will hopefully be completely done modifying our code into the framework needed for the rest of the semester. Time to down a few energy drinks and get crackin'!

Belated Introductions

This is more than a little late, seeing as I've already begun posting for class, but I thought I'd "start off" this blog with some background info :)

Hey! My name is Rachael and I'm a year 2 Game Dev. student at UOIT. I'm more into the art side of things and love photoshop paintings as my current medium of choice, though I'm beginning to work my way up with Maya too! I'm the Lead 2D Artist for the small development studio Fort Fortnight Studios. Since I'm only in year 2 we haven't had the chance to work together for very long, but going through school together and handling the steep learning curves and twists of University have brought us together as a pretty tight team.

This blog is for our Intermediate Graphics class, possibly our group Game Design Workshop, and just to keep myself and my partners on track with our development. There'll probably be a fair share of dry posts for school, reiterating notes and the like, but hopefully some of the development blogs will keep your interest!

We're currently heading into month 5 of 7.5 of our development period and are working on our first 3D game Up All Knight. It's still very much in the protoype stage, as not all of that time was workable thanks to hectic exams, winter holidays (and recuperation period!), and the initial confusing weeks of finding groups and deciding on a game concept.

Main Character Concept

Now that the first week of classes is over and everyone's sleeping schedules have (mostly) fixed themselves after a much needed winter break it's time to get back into continual crack-down mode. Time to get to work!~

Dawn of a New Day

Day one in our Graphics course with new content and we're jumping right into the heart of graphics: the hardware that makes it possible. I recently built a computer for the first time (with plenty of assistance), my first personal desktop after years of dealing with laptops. I learned very early on that as a gamer one of the most important components I would need was the GPU as it is what handles the majority of the graphics in most decent modern games. This is thanks to the wonders of modern engineering, allowing us the capability of having 1000+ cores, the GPU is capable of hundreds more processes then the CPU with it's 4-8 cores.

The GPU handles the graphics pipeline: the process of converting data into pixels on the screen. It's pretty amazing how we can program a computer to take basic points in space, convert them into simple triangles, and then output a complex model all in a matter of seconds. A lot of this is thanks to the information us programmers assign to each point, or vertex, such as colour and normal.

Okay, so we know what happens to create this image, but how does the image itself work? Digital images are made up of pixels, each consisting of 4-5 channels (RGB + Alpha, Luminance). How this information balances with each other determines the colour that displays. Other data that the graphics pipeline needs to know is textures and UV mapping. A texture is typically thought of as a 2D image that is applied to 3D model to give it colour based on where a UV map says it should go. Other forms of textures include bump and displacement maps; a map that tells the computer where there should be small valleys and ridges that are only affected by light, and a map acts as a bump map that also affects the actual geometry of the model.

Key Order: Modelview -> (eye) -> Projection -> (clip) -> Perspective -> (normalized device) -> Viewport -> (window)
Key Formula: v(new) = P x M x v(old)

Then we find out that we're going to have to reprogram a large portion of our framework... something I've known for a while but liked to pretend we would magically not have to do. In order to both a) do well in this course and b) have a game running with any amount of decent speed, we'll have to take our game out of immediate mode and have it run using more complex, faster shaders and buffers. This semester's going to be a whole lot of work, but I believe in our game and our group and know it will all be worth it in the end :)

Testing testing 1-2-3!

This is just a good 'ole test post. Let's see what this thing is capable of!