Post-midterm stretch, and getting ready for MIGS!

Good day ladies and gentlemen!

Sorry for making this post late, as midterm time was quite hectic, and naturally left me sleep deprived.

First midterm was by itself on a Tuesday, so I was able to study a lot for it, and didn't do too bad.
The second midterm was the beginning of the true midterm crunch time, as my two other midterms fell on succeeding days. To boot, for my third midterm (Game Engine Design), I was required to complete a certain number of homework questions to attempt it. Of that week, my midterms went well, but unfortunately my last midterm didn't go so well as I only was able to study for it the morning of, thanks to the other assignments and midterms due before. In fact, I was supposed to do my last midterm tomorrow, but I had to do it a few days ago since I'm in Montreal for MIGS at this time of writing.

Now I'd like to elaborate on the homework questions I did to be able to do my Game Design Design midterm. Here are many different questions to choose from, some more hard than others, and each has "experience points" weighted accordingly. One must attain 20 experience points to do the midterm, and 40 to do the final exam.

One of the questions asked me to create a program where the user smashes a pile of bricks by throwing a ball from camera point, using provided physics calculations from Havok. Another question required me to import a textured 3D model from modeling program Autodesk Maya, and be able to rotate it, pan around it, and zoom in and out. So I decided to blend both questions into one. The biggest challenge was to have the camera rotate smoothly, and to this day my software camera technology isn't exactly user-friendly. Regardless, this is how I did this in a nutshell:

I first put a pivot node in the middle of the scene, and connected it to another pivot node that encapsulates the camera. To visualize, a pivot node is basically a joint in a structure; in this case, a camera movement structure similar to film practice.

This picture is the best way to visualize my camera system. The first node is the joint between the legs of the stand, and the main beam. The second joint is at the tip of the beam, holding the camera. The camera itself is also able to rotate.

Whenever the user clicks on the screen and drags the mouse, a built in function of WildMagic (the software engine I'm using) kicks in, and gives me the coordinates of where the mouse clicked. To boot, there's another function from WildMagic that alerts the program when the mouse is clicked AND THEN moved. I used the first mouse function to track the mouse's position, and record its coordinates as "previous mouse coordinates". Then I use the second function (which only kicks in when the mouse and clicked AND held) to check the mouse coordinates again, and compare them to the previous mouse coordinates. I then subtracted the two points from each other to get a vector. In case you don't know, a vector is just a line that points in a direction. So I then take that vector, and the camera's direction vector (also provided by WildMagic) and then cross product them. If you don't know what that is... study linear algebra. If you don't care to learn about linear algebra... then just assume that it's some magical function from Math-Land.

Anyway, after doing the cross product of those two vectors, it gives me another vector which serves as the axis of rotation. In other words, imagine a string through a ball. The ball can rotate only around that string. That string is known as its axis of rotation. Finally, I get the first vector generated from the mouse points, and measure its length. I then use that length to determine the angle of rotation around the already generated axis. Since this whole calculation is conducted around 30 times a second, the length of the vector generated by the mouse motion cannot be too long, so I just convert its distance straight to an angle in degrees. In other words, in my function, 15 units = 15 degrees. Finally I put the axis and angle into a matrix. If you don't know what a matrix is, it's basically a grid of numbers that are helpful for mathematical calculations such as this. If you want to know more, then study linear algebra, as such material can be quite complicated. Anyway, I multiply that matrix by the original matrix the camera pivot has, and then a new orientation is achieved. So that's my camera rotation function! There's still some things I need to fix to get it working, but this is the outcome I have currently. There are some parts that are probably missing, as my function is currently not working perfectly, so please avoid assume that my algorithm is the correct way to do camera rotations.

Camera panning and zooming is a lot easier, as all I had to do was look at the camera's built in up and side vectors, and move along them depending on mouse distance along the x and y axis respectfully. To pan, the user must left-click (like how rotations are done), but also hold the "z" key. As for the zoom, it's the same thing, except it moves along the camera's direction axis, depending on mouse distance along both the x and y axis.

Finally, I textured the blocks and the terrain. I thought about what I should texture them as. After much contemplation, I figured this would be the best theme:

Yes, the background theme plays too, through FMOD.

The other question I had to do involved making a replica of our solar system, with the appropriate planets, textures, rotations, etc. So again I used the same camera controls as the other homework question, but with a non-interactive scene of our solar system. It is set up as a scene graph, which is like a rotational and translational heiarchy. You know that in physiology, the knee is connected to the hip, and the angle is connected to the knee; well the planets are connected to the sun, and the moons are connected to the planets. So when the sun rotates, all the planets rotate with it. When the planets rotate, their moons rotate. And the moons also rotate too, albeit nothing connected to them. However there's still something missing. If the program was executed like this, all the planets would rotate at equal speed. Sure, each planet rotates individually, but on their axis. In order to allow each of them to have different speeds, I had to add extra pivot nodes between the sun and each planet, at the sun's position. Each planet's extra pivot would constitute a different speed, hence resulting different speeds for each planet.

Also, the main theme of Super Mario Galaxy plays in this program through FMOD. Why not?

So there you have it! Now I'm in Montreal waiting to attend MIGS, and listen to many insightful keynotes and presentations, and network with industry professionals as much as possible. Now that I finished all my pre-midterm assignments, and the midterms themselves, now it's time to focus on the GDW. AND time to finish all my other assignments EARLY so that I have more time to work on the GDW project. I have the position of the toolkit programmer, so my workload is definitely not light.

As for my previous blog post reminiscing about my work-ethic, I'm hoping that now that I'm out of the woods, I'll be mature enough to say NO to distractions and be productive with my work EARLY, not just at crunch time. Every time I've presented my GDW, it would pale in comparison to other student's games. So I will do my best to exceed everyone's expectations of me, and it all starts from following a better work-ethic that has a proper sleep schedule; because I hear that the game industry workfield isn't any less rigorous than the work we have now.

Next post will be about what I've learned at MIGS, who I met, and a possible rant on that amount of school lecture content I have to catch up on thanks to MIGS. =P

This is Mario Greco signing out.
Thank you for reading! =D

References:

Photograph. 13ft Telescopic Jib Arm Camera Crane with 100mm Bowl tripod stand & spreader Gold Pan Tilt Motorized Head w Joystick Control Box for Professional Commercial Independent Wedding Documentory Video Film Makers. The Cine City, 2005-2011. Web. 31 Oct 2011. .