Nav-Mesh Editor Part-3

Okay, making more progress on nav-meshes!
New features:

• Polygon Select Mode
• Automatic neighbor calculating
• Path finding preview
• Nav-Mesh file format ( *.rnm)

I made some more additions to the editor, mostly to make creating these meshes easier. I had to do all the work associated with making a model editor, except my "polygons" can have up to 15 sides ( expandable to 18). All of the navigation data is stored in the one of  the most memory-efficient way possible IMO.

I also got around to making a file-format to store the navigation-meshes in! I call it "Ruined Navigation Mesh" format - original and ironic I know. These files are also VERY size efficient.

For all of you out there familiar with XNA, I've written my own importer and processor...

Ruined-Navigation-Mesh-Format:

Offset	Description	Size
0x00	Header "rNavMesh"	8 bytes
0x08	Number of Vertices (v)	2 bytes (ushort)
0x0A	Number of Polygons (p)	2 bytes (ushort)
0x0C	Vertices	12 bytes (float3) * p
0x0C * v * 12	Polygons - xp vertices ( ushort[] ) yp neighbors ( ushort[] )	Sp = Sp-1 + 4 + xp + yp Data stored in memory as a single ushort[]

One of the great things about just reading data directly from the file is that XNA can compress *.rnm files automatically!

So in other words, all that's left to do with this is to actually make the meshes, and program some AI to use them :P

Path-finding, Initial Polygons 

Path-finding, Found Path 

Note : Polygons are stored as a single ushort[] in memory, the actual polygon's data is extracted from this array (Yay! bit-wize Shifts)

Animation Systems

The animation system in Ruined is much different then most other games.
Usually the animation system in a game works by storing a TON matrices that transform each of a model's "bones" for each animation. While this may be fine for single animations it is unacceptable for more complex animations. Let's say, for example, that we want the character to be running while swinging a sword in one hand and then suddenly jump. In the standard system, the character would suddenly, choppily switch to the jumping animation. This is because the standard system takes only one input and, as a result, has only one output.

The Standard System results in a choppy timeline.

As a result of this choppiness, games designers have adopted a system of smoothing between animations. This allows the switch - from say running to jumping - to be much smoother. The "Smooth System" takes two inputs: the current animation, and the desired new animation, and smoothly transitions between them. The matrices that make up the animation should be decomposed before blending.

A Smooth System allows for smooth transitions from one animation to the next

Now the issue with the Smooth System is that it only supports one stream of animation. A "stream" can be thought of as an animation that only effects a certain part of an object. Separate streams can exist for the arms, legs, head, fingers etc. This allows each stream to animate independently of the the others. So the character can be running while swinging his sword, shooting a bow or eating a sandwich...

A Stream System allows for dynamic control of multiple animations, smoothing, and gives the best results overall.

In Ruined, the engine can make use of all three of these systems. This way, the proper system can be used depending on need:

• Standard Animation is used for things that are perpetually animated, like a train engine.
• Smooth Animation is good for most NPC's or monsters/creatures/wildlife.
• Stream Animation is best for complex characters, such as the main character.

Another cool feature is that all three of these systems allow for optimization (cutting 1340 frames down to 60), which I'll talk about in another post :)