Engines 0.7: Ogre Shaders

UGH ...Ogre is being difficult. I don't know if it's just me but I find its shaders pretty convoluted. And on top of that, for some reason uncommenting the Cg Shader Plugin still has my Ogre log screaming at me, and I quote: "* Supported Shader Profiles: arbfp1 arbvp1 glsl. (Yeah, have fun using cg when you can't! HA!)" Ok, maybe I added in that last bit, but I truly feel like Ogre is holding a grudge against me..or maybe it's just way too early in the morning to be writing a blog. I don't see myself having time to do it later though :/

So GlSL it is then, Ogre. I somehow cobbled together a vertex and fragment shader in that language (it's not that complicated or different than cg. In fact it might be simpler. I'm not sure yet though). Oh, and I forgot to say, the reason I'm working out how to use shaders is that I want to do the "morph animations" question. The one where you have to morph one object into another (there's a bit more to it than that).

Now anyone with half a brain would assume that Ogre would do keyframe, morphing animations for you. But I really don't know if it does. Form what I have found and read, I think you need to keyframe things in Maya and then do some witchcraft and summon demons to write code for you in a mysterious language called XML.. Here's the link if you can figure it out. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Morph+animation. I saw shaders and though, "oh well if I have to animate stuff through a shader, I might as well just pass vertices in the good 'ol fashioned way and save myself the trouble of learning another language.

How exactly do you make shaders in Ogre though? The answer is "not very easily". So you have a material file, which you apply to an object. That part is straightforward. Then either inside that material file, or in a separate file with the ".program" extension, you write a "shader program". This isn't where you put the shader code itself, this is just a program that passes parameters to the shader program. You also have to call this program in your material's "pass" section, while adding in any parameters that change.

There's an example. It's pretty confusing, but this helped. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Getting+Started+With+Ogre+CG+Materials&structure=Cookbook The only problem is that it was in cg instead of glsl (and cg is the shader language I know).  Also, a bit of advice: separate your vertex and fragment shaders into different files. Glsl will give you errors of you don't. Here's a look at glsl:

By the way, that's a vertex shader. And gl_Position and gl_Vertex are variables that are built into glsl. gl_Position is the vertex position the program outputs, while gl_Vertex, I'm guessing, is the vertex position put into the shader. Also note that "uniform" is used for variables passed to the shader form Ogre and "varying" is used for variables that will be passed to the fragment program afterwards. 

I guess none of this has actually used anything other than scripts so far. So here's how to pass variables from Ogre: 

Yup...that part is probably the easiest.

So that's what I worked on this weekend (I would've done more but my parents convinced me to go home one last time before the Christmas break and that was kindof a hassle considering how far away I live). There wasn't much time and I'm probably doing morph the complicated way, but hey, at least I now know how to use shaders and can maybe put some into our game someday when I'm not swamped with work and have a few free hours. a

Engines 0.6: GDW Progress

In my game design blog I tried not to talk about programming. No, I saved that for this blog, because to me, Game Design has always been an artistic thing, not something that requires hard numbers and logic and code.  Anyways, our game is starting to look pretty good. I think it's because we have a skybox and particles as well as the beginnings of a HUD.

The particles in our game are Ogre particles. They use a script which is really not hard to use (http://www.ogre3d.org/docs/manual/manual_34.html here's the documentation in case you were looking for it). I tried to write a seek function for our enemy ships but failed horribly. That's ok though. I'm just not the greatest at math and Havok makes things confusing. For some reason if you take the orientation of an object using Ogre, then try to apply that same orientation to another object using Havok it just doesn't work at all. The other object will just face random directions.

So I guess I should talk about what I HAVE done instead of what I haven't. In the past few weeks (I'm not sure if it was the past few weeks. The engines midterm feels like it was last week even though it was this week and time feels all skewed. It's just skewed in a bad way where it feels like there's no time to do anything or work on the game and all I want to do is work on the game and gaaahhhh!!). Anyways, I worked on a "ship" class. This defines an object as a spaceship. Albert suggested we write scripts for our ship attributes, so I implemented that. Scripts make it very easy to change variables and save you compile time because you don't have to recompile your game each time. Speaking of compile time, our game took 2min 47sec to compile. I restarted my computer and the compile time was much more reasonable. I dont know why that happened. But 2 minutes is a looong time. Anyways, the scripts aren't complicated:

health     100
ammo     500
speed     10
amount   5
particlePos1 1.7 0.7 -3.5
particlePos2 -1.7 0.7 -3.5
particleTex particleTexture
particleSysName testParticles
billboardSetName shipBillboards
thrusterTex redThruster
thrusterPicSize 1.6

As you can see, it's just defines the ships' health, speed, the swiftness with which it rotates left and right, the positions of its thrusters of particles and billboards and the textures applied to those particles and billboards. We will also have shield strength.

The ship class has functions to move the ship forward, pitch up or down, and roll left and right. These functions all apply Havok impulses in different direction or orientations. As I said before, we have particles and billboards for the ship thrusters. There are also functions for that.

Our game is really simple so far. It's coming along though. I just wish there was more time to work on it. We could make it so awesome. Sadly, the harder we work, the more work we seem to have thrown at us, cutting the time we can work on the game. I know I shouldn't complain. I still have time to sleep. But it's just a little frustrating knowing that I have to put aside what I want to do (work on the game), for written assignments and things of that sort :C

Game Design 0.7: GDW Progress

I've made some progress on the design of our GDW game this week. There were particles coming out of the thrusters (which I put in before), but I added ambient ones as well as a billboard to make the thruster look better. I also posted before that I would show off our skybox.

Here it is:

You can't see it in this still frame, but some of those white points that look like stars are actually particles zooming past you because you're going fast

I photoshopped the planet into the skybox. The planet was a picture of a rock that I coloured on and added glowing effects to. That is why the terrain looks so realistic

I made the skybox using a program called "spacescape" (http://alexcpeterson.com/spacescape). It actually exports seamless space skyboxes for you. You just need to create and add different layers of noise or stars or billboards. It's pretty cool. I can't take credit for our awesome skybox because I simply followed a tutorial.

You can also see the particle effects on the thrusters. It isn't very difficult to do in Ogre because Ogre has a particle system that you can use (http://www.ogre3d.org/docs/manual/manual_34.html). It just takes a bit of fiddling to make it look the way you want it to.

We will be adding textures to our objects soon. The problem is that I just finished texturing my ship (I think I'm done. I could add more but I'm not sure yet). It's an enemy ship and it's only 800 triangles, which is excellent if we want many enemy fighters in our game. The lower the polycount, the more efficient it is to render.

The rough metal texture of this ship comes from a photo I took of my mother's baking pan. 

That's all I've got for now. I've barely just started working on GDW because I've had to finish ALL the assignments and study for midterms and sit in class and listen. I really hope I can make more time somehow because I would really, really like to work on this game more. I think it has potential and working on it is probably the best part of being in Game Dev :]

Engines 0.5

In the past week I actually started to contribute to our GDW game, Quantum Prime. It felt really good. If I could spend all of my time only working on the game I would much prefer that. Unfortunately, I can't because there are classes to attend and assignments to do.

I didn't do much yet though. I only started a basic "ship" class for our spaceships (Quantum Prime is a space game), but I'm itching to code more now. I really want to be useful to my group and I want our game to be awesome.

Unfortunately I need to take a break from everything and study for midterms for the next few days. It feels weird because I'm not used to memorizing things or having to explain what I know (I'm very bad at explaining things without using the words "um", "stuff" and "things"). Usually, if I don't know something I Google it, look at examples I have been given or my old code, or just derp around till it works. Sometimes I even just rage really hard and ask for help or search more thoroughly for answers than I previously have.

Studying, though, is a completely different beast that I am totally not used to. It does give me a chance, for once, to actually understand why things in programming work instead of just accepting that they work and moving on to the next problem or task. So studying for Engines is actually useful.

Game Design 0.6: Audio Games

So last class we had to make a game that consisted of audio only. No visual cues or physical cues could be used. There is a reason there is no such game that sells well enough for everyone to hear of it (no pun intended). If anyone has made a game that is purely audio-based well then I feel bad for them if they thought it would sell well. I'm not trying to bash people who've tried making audio games. I'm just stating a fact. Think about it, if you had the option of playing a game with the shiniest graphics, realistic normal maps, beautiful landscapes,  terrifying enemies, and sweet weapons, and a game with no graphics at all, which would you chose?

Audio is definitely an important part of a game. Horror games with no audio would not be scary at all. Games like Skyrim, have music that is so good, I actually listen to the theme song when I'm bored sometimes. And what would it be like if your guns didn't make shooting sounds. The game would be bland and you'd always feel like it was missing something important.

Audio is just ONE part of what makes a good game though.

To make a FUN game based solely on sound is a huge challenge. Is the player not allowed to interact with the keyboard? If so, they would have to go through annoying menus (where the AI asks you to reply "yes or no" then misunderstands your yes for a no and you get frustrated and want to take a hammer to it to end its meaningless, annoying existence).

Even if you are allowed to touch the keys, your game choices are limited. The only genre I can think of is a text-based adventure or mystery game, where instead of reading, everything is read to you. There are a set number of options and you press certain keys to select them. Everything is pre-scripted.

A game like this would require some work though. It is not easy to think of a good, exciting, original story. After that all of the sound must be recorded and the engine must be scripted to take into account every possibility. It's not an easy or menial task by any means.

As an aside, this type of game could not be implemented in real life in a classroom setting with students as sound sources in half an hour. A script would have to be written, parts would have to be memorized, and timing would have to be implacable  It would take as much time and skill as organizing a great play, or maybe more because a play's story-line is linear.

Game Design 0.5

For our GDW game we're going for a realistic / Star Wars Battlefront kind of feel (only the space battle part). This entails gathering textures of scratched metal and rocks, which is what I spent last weekend doing. My mother wanted to go hiking in Gatineau Park and we brought the camera along. I took a few pictures of rocks. One of them turned out perfectly for the surface of a rocky planet (I'll post pics after I finish the planet).

There's a village near Carleton Place called Appleton and the rocks downstream of the dam are shaped by the water. I got some good pictures there of rocks too, only it was starting to get dark.

I also took some pictures of metal for our spaceships. Here are some of the better ones:

My mother's baking pan

This is the cover of an old catalytic converter (part of the car exhaust) in our yard. 

I hope these images help you get an idea of the look we're going for. And if we can get all of our art assets in the same style (we're working to fix our mistakes from last year) then our game could look really good. 

The Unity demo we have to make will have some rough textures as well as our models. It will also have basic mechanics. I've seen it and it's starting to look nice. The skybox isn't done though. It needs the aforementioned planet to be added to it. I'm working on that though. 

Also, if anyone needs/wants texture photos like this I can share them on Dropbox - because Game Dev is all about teamwork. 

Engines 0.4 Havok Primitives

So the easy deadline came and went (well almost. I was extended to Monday), and I now have an ok amount of XP. I still need more to be able to write the midterm though.

I feel like we have A LOT of work to do. Havok isn't exactly the easiest thing to figure out. In fact, good luck with that. May the programming gods help you. We all have to wrap the Havok skeletal animation system as a requirement and I think that will be quite hard.

I've done the "Boucing Ball" easy question where we have to make a ball bounce using Havok rigid bodies but not use the hkx and fbx loaders that are included. To do this I had to make a Havok sphere and a hard surface for it to bounce on. Then I had to place an Ogre sphere and plane where the Havok objects were. Havok objects are invisible except, according to Dan, in the "Havok Visual Debugger". I haven't tried using that though.

Now I had my visible objects and collidable objects but nothing was happening because Ogre and Havok don't talk to each-other unless you make them. So even though my sphere had mass and was affected by gravity in Havok, it was just a sphere mesh in Ogre. This was the hard part. I was trying everything to make my sphere move. I had no idea it was moving in Havok because I couldn't see it when I ran my program.

Then Harry, who was also trying to figure out this question, thought "hmm...maybe it's moving but not moving the Ogre object with it". So I hacked it and finally got it to work.

This is what I did:

1. Make Ogre objects (or load them in from Maya as .mesh files) and attach them to nodes. Position them wherever you want, but keep in mind you'll have to move your Havok objects to the same positions.
2. Initialize the Havok World and Havok Scene Manager, then lock the world. (This should be done for you by the project generator but I thought I was initializing the world wrong and spent lots of time re-initializing, just to have to comment all of that out). 
3. Mark the world "forWrite". This allows you to change things in the Havok world. If you don't do this you get errors because the program can't touch anything in the world. 
4. Make an hkpSphereShape object and give it the radius of your Ogre sphere. 
5. Set up the hkpRigidBodyCinfo for the sphere shape. Give it a mass, a shape (the hkpSphereShape you made earlier), friction, and set the motion type as hkpMotion::MOTION_SPHERE_INERTIA. You should also set its position and inertiaTensor (not quite sure what that means, but look at the Havok demos). 
6. Make a rigid body. Yup, all the steps before don't actually give you a rigid body. It's just setting up the attributes of the rigid body.
7. I activated the rigid body too, just to make sure it'll move as soon as my program starts. 
8. Add the rigid body entity to the Havok world.
9. Do steps 4-7 for the plane. I used hkpBoxShape because I don't know how to make a Havok plane. Also, note that giving something a mass of 0 will make it stationary. 
10. Unmark the world "forWrite" so that the program knows you're done writing stuff in the world.
11. Unlock the world (this should also be done for you by the project generator).

So now we have everything we need. The Havok sphere is falling onto the plane and bouncing but you can't see it. To link the positions, I made an hkpVector4 to store the position of the ball rigid body. Then I set the Ogre ball node position to the values stored in the hkpVector4. This is harder than it seems just because Havok is so convoluted. The way you get an x value out of the vector is like this: myVector(0) , or myVector.getSimdAt(0) . Y is at 1, and Z is at 2. 

And that's it. The only thing I have a problem with is WHO THOUGHT IT WAS A GOOD IDEA TO CALL GETTING THE X VALUE "getSimdAt()" ?! 

Game Design 0.4

We're at the stage where we need to start thinking about how we're going to design the levels for our game. Since our game is in space, the level design will have to be different than for a game that has a floor and walls. That doesn't mean we don't need to put effort into designing the level. The player still has obstacles to overcome and a goal to reach.

Space is endless, but the Havok World isn't, as Harry found out the other day. The Havok world space is defined by the .hkx file which you export from Maya. It creates a scene with Havok objects that correspond to each of your object meshes in the scene. When it does this it also limits the world to a size that fits your scene. After you load everything into TwoLoc and make it run successfully, it becomes apparent that if an object exits the Havok world, the program crashes.

Dan Buckstein explained that some games get around this despite having an "open world" by killing the player if he exits the world and re-spawning them in a different location. Take Battlefield 3 for instance; if you get near the edges of the map, you receive a warning to return to the battle and a countdown. In other games there is a winding track and nothingness beyond the track. If you fall off the track then you are re-spawned somewhere on the track before you fall off the Havok World. Those measures were put in place to prevent the game from crashing really hard.

Our game is in space though. We want it to feel vast. I'm not sure how we'll constrain the player. Perhaps we will move everything around the player while he remains static? Perhaps we will place invisible walls that you cannot cross? It would be hard to tell if you are moving or not in space unless you are heading towards other objects (such as spaceships or asteroids) which would be at the center of the world.

The goal of our levels are centered around destroying the enemy mothership while avoiding being destroyed by the enemy fighters. There will also be asteroids that the player must watch out for. We will probably place everything in the middle of the Havok world, so that the only way the player would come near the edges of the world is if he was fooling around with the game and seeing how far away he could go. Still, we must prepare for this. Exiting the world is a game-breaking error. No one is allowed to leave.

Engines 0.3

So this weekend I completed two more homework questions. I feel like I'm almost getting the hang of adding objects and materials now; almost.

For some reason animated textures just don't work. Ogre supports them (or should) but I have tried numerous things to make it work and it just doesn't want to. It should be as simple as adding one line of code into the material file, but nope. And on top of that it doesn't give you any errors. Not one. All of the files are loaded in fine according to the OgreLog.log file so I have no idea what there is left to do. I gave up on that question.

Speaking of the OgreLog file, it proved quite useful when I first tried to load in materials. It tells you the file paths where it searches for .material and texture files. That made me realize that file paths must be absolute or based on environment variables, otherwise they do not work. You know how Visual Studio accepts paths  such as $(ProjectDir) and $(ConfigurationName)? Well Ogre doesn't let you do that as far as I know (or maybe I'm using the wrong keywords).

.material files are cool. You can do all sorts of things in them (searching for how to fix the animated texture, I found quite a lot of documentation on Ogre material files  http://www.ogre3d.org/docs/manual/manual_14.html#Material-Scripts ). You can call Ogre's shaders, and play around with  culling and alpha blending and much more. The only problem is that a lot of Ogre's documentation is not very "noob friendly", meaning that if you're searching for a specific function, you will find what you need, but if you search for the process of doing something which requires many functions, it will be much harder to find.

It doesn't help that sometimes on the Ogre forum, when someone asks a question - for example, how to make a billboard - all of the replies are "check out the documentation. It's easy" and link you to something that looks like this:

Very easy to use documentation for someone who's never made an Ogre billboard

So yeah, it's not always easy to find what you need, but the internet is vast.Somewhere, if you search hard enough, you will find the spinets of code, or clear explanations you need - http://www.ogre3d.org/tikiwiki/tiki-index.php?page=LightsCameraAction#Billboards_and_Materials. Don't expect everything to be easy to find.

*****

On an unrelated note, I remembered this: http://www.youtube.com/watch?v=tguqmbaqNPA at 9:21

Catbert: And Alice, you need more time, but that's only because you spend so much time on your hair and makeup in the morning.
Alice: That's a necessity.
Catbert: Only in your mind.
Alice: You mean, I'm beautiful just the way I am?
Catbert: No, I mean, it's a lost cause. You should put that time to better use!

To put this into perspective, I need to wake up over 2 hours before class starts to get ready in the morning. If I didn't spend time doing my hair and makeup I could probably save myself 30-45min. I know it's a waste of time, but I just can't bring myself to not to do those things in the morning - except maybe during crunch. Actually, even when I've pulled all-nighters I sometimes brought along my hair straightener. There are some things I can't compromise on