Havok, Vertex Buffers, Maya 2011

So, it's been a while since I posted. We ran into an interesting situation where we learned that Havok was exporting our referenced meshes as unique meshes within our level. This led to each mesh having its own unique vertex and index buffers. Now, with trees, paths, POIs, and other content, this led up to having 5600 unique vertex and index buffers.

That, for lack of any better words, is a lot of content. That's also a lot of state changes between graphics calls. So, how did we fix this?

Well, we first attempted to export our files using the Havok exporter in Maya 2011, using the "Find Mesh Instances" filter. This filter is supposed to remove duplicate meshes from the scene, but does not detail how it does so.

We at first assumed that any file that was referenced in would be considered a duplicate mesh. Then, when that didn't work, and we had a 50 MB level, we tried doing reference copies. That didn't work either. Well, I then systematically attempted to figure out how "Find Mesh Instances" worked. Turns out, I couldn't find a way for it to work (at least not using the filter).

But, after talking with Eric, I found a nice way around this.

So, the solution was instead to do this:

1. Reference in the object / model you want to use from the file of your choice.
2. After placing your reference, select the object in the Viewer or Outliner.
3. Go to Edit->Duplicate Special (click the square next to it to set it up)
4. Select Geometry Type as Instance and Group Under as World.
5. Click Duplicate Special.

What this does is creates an instance of the reference that was loaded, which has its own transforms separate of its parent. However, because it is an instance of the reference, its materials, vertex data, etc will be changed when the reference is updated. Likewise, when you execute the shortcut now, these parameters will already be set up.

When you export using the Havok Content Tools exporter for Maya 2011, "Find Mesh Instances" will report not finding any duplicate meshes. However, only a single instance of the mesh will be loaded and referenced in the scene. For us, this insures we only create one index and vertex buffer per referenced mesh, greatly reducing the size of our level files and increasing run-time performance for the game.

Heatmaps!

I spent the last week or so working on all the pieces I need to get set up in order to have the data needed to create a heatmap. I first had to log out the data from our game engine, which I achieved by writing all the gameplay metrics to text files. The next step was to organize all the metrics from the log files into a database. The proper way to do this is to use an SQL database, but this was going to take me too long to learn and implement. So I decided to keep using a text file to store the organized gameplay metrics.

Animation State Engine and Expressive AI

Now that we have some animations the AI can start to look more interesting. No longer do they merely stop at the goal and wait to move to the next goal; they actually do something at their goal now! To further that end I developed an animation state engine. This is basically a finite state engine with each state representing an animation, and the edges representing transitional animations. It allows the AI and animation systems to be separate, and the AI system to merely tell the animation system which animation state it should be in next, and the ASE will handle picking the appropriate transitional animation and determining when to play and when to stop animations. Each agent also has a map of animation categories to specific animations, meaning different agents can easily have different "Walk" or "Idle" animations without the ASE or the AI system caring at all.

This Is Why We Can't Have Nice Things, Delta

A little photoshop magic on the city map shows just how well our detective takes care of his things.

Two Paths Diverged in the Park (With Apologies to Robert Frost)

We've had the nav mesh and path finding in for a while, I just haven't had time to make a post about it. Here's what our nav mesh looks like currently:
Right now it's only the actual dirt/concrete/DG/whatever paths in the park, it doesn't include grassy areas yet. There are plans in the future to mesherize the grassy areas as well, but we need some way to assign terrain modifiers to polygons so that AI knows what kind of terrain it is walking on. The other thing you will notice about the nav mesh is that it is all triangles, instead of n-gons. This is unfortunately a shortcoming of Havok, it refuses to read anything but triangles. This means more polygons than strictly necessary, and also it means that our centroids kind of make a wobbly line. That being said, it works pretty well, and the local avoidance gets the AI to alter it's path and keeps them from looking like they are in one big line.