Grey - Game Project

Last week David and I was working on a issue with skeleton animation blending, the problem was that when we ran two animations on the same skeleton the joint movements of each animation was not in full effect.

After some reading in the Pro OGRE 3D Programming book and the Ogre3D forum we figured out that Ogre’s default skeleton animation blending mode was set to ANIMBLEND_AVERAGE, meaning if you have two animations active it divides each weight with the amount of animations active (1.0/2). What we wanted for our skeleton animation blending was ANIMBLEND_CUMULATIVE which would let all the active animations perform their joint movements and skeleton animations in full without weight reduction.

Accessing libraries in yake (like Ogre) is not much of a problem when you figure out how to go about it, so setting the skeleton animation blending to ANIMBLEND_CUMULATIVE worked really well. Here is a little snippet of changing the blendmode of a skeleton.

typedef yake::graphics::ogre3d::OgreEntity OgreEnt;
	
void setAnimationBlendMode( yake::graphics::IEntity* ent, Ogre::SkeletonAnimationBlendMode mode )
{
	Ogre::Entity* ogreEnt = ((OgreEnt*)ent)->getEntity_();
	
	Ogre::SkeletonInstance* skel = ogreEnt->getSkeleton();
	skel->setBlendMode( mode );
}

Also last week I started to look into Ogre Compositing but I pretty much ran into a wall, I’ll have to take a good look at it this week and see if we can work around the problem. What is Ogre Compositing? you might ask youself, Ogre Compositing is used for making post-frame-effects, meaning we render the games frame onto a texture where we then run different material programs and shaders to enhance the image.

We want to use this post-effect functionality to make colour corrections to the game, a few weeks back David was messing around with a screenshot making some colour corrections in photoshop, the difference was amazing compared to the original.

If/when I get this Ogre Compositing working I’ll post a with/without screenshot to show the difference:)

Cheers.

Hey!

It’s been a while since we(coders) last wrote frequent posts, we’ve not written much mainly because of other intensive courses and just not having any fun stuff to write about. The CG-artists have been giving a lot of good frequent updates which has been really nice.

Since Milestone 2 we’ve been in the implementation phase, so far during this phase we have with great caution written most of the class-structure and framework for the game. We’re now focusing on inserting the CG-artists content into the game. As always we are paying dearly for the crime of not doing even more tests during the prototype phase, but of course you can never do enough tests.

Last week David posted some screenshots of a scene without any dynamic lighting, this week he started to experiment with it and it is looking really good, here’s a screenshot:

Currently I’m working on physics and loading .xode collision-meshes. I am also doing some work with animation blending, but it’s a bit on ice for the moment until Fredrik can rebuild some of the yake source for me.

Back to coding, Laters!

Milestone 2 is complete. The results can be found in the links below. Images of the graphical material is in the presentation file:

- Design Document
- Presentation

Changes and additions will be made to the presentation file before the actual presentation.

Below is a video of the viewer in action. The viewer demonstrates animation, light, model loading and user input.

viewer_2008-01-11.avi

// David

Contrary to popular beliefs us programmers don’t just sit and write code all day. To write clean and efficient code you have to plan ahead and design the code on paper.

This is what I have been up to for the last couple of weeks. I am completely done with classes that will handle loading and applying of game configuration settings such as audio and control options. Right now I am working on designing the enemy and AI classes.

It’s not half as bad as it sounds, it doesn’t involve writing any code at all. Instead we use graphical tools, or pen and paper to design class diagrams that help visualize how all the classes are connected and what their interfaces look like.

Here is what I’ve got so far:

Config system

NPC & AI

Over and out!

It has been a while since we (the programmers) busted out and blogged some.. And to be exact, our last entry was posted: 23 days, 12 hours and.. a lot of minutes.

While the CG-artists have been posting their pretty pictures and work results, we’ve been digging our own graves programming-style. The Prototype Phase is not a pleasing experience, with almost no structure, bad naming-conventions and a constant puddle-jumping from one sample to the next, I’m surprised that not more programmers go insane during this time… or bald..

Since our (programmers) Milestone 1 we have been testing samples and tutorials for the Yake API restlessly like little horny rabbits (without the sex). Some of the things we have been testing are Animations, Control Inputs, Scripting and Particles to name a few. There is still some problems to be solved and improvements to be made, mostly for the Physics pipeline but it’s looking good schedule wise.

This week we decided to move our Implementation Phase a few weeks earlier in the timeplan (right after new year we’ll be rocking), we changed this because we don’t believe there will be a whole lot more to gain from more prototypes so we might as well start a few weeks early.

Here’s some code snippets and stuff about Yake.
Yake is really big on namespaces, templates and typedef’s, neither of us had worked much with these perversely ritualistic parts C++ but it didn’t take long to get hooked on the idea and clever usage. Yake’s design is very generic, with a lot of flexibility through the use of generic- and meta-programming techniques.

Code such as this is a common thing for examples in Yake:)

struct TheConfiguration : public raf::ExampleConfiguration
class TheApp : public raf::ExampleApplication<TheConfiguration>

typedef uint32 IndexType;
typedef std::vector<IndexType> IndexVector;
	
typedef boost::function <void (void)> fState;
typedef fState* fStatePtr;

We’ll keep the updates coming whenever we have stuff to write about and time to write it, so hang in there.. I’m sure the CG-artists will post a whole array of new shiny images any minute now:D

Cheers!