Squamster

This is a 3d mesh viewer and texture painter for windows. It uses Ogre's .mesh format. It is currently being licensed under GPLv3 and is available at google code.

http://code.google.com/p/squamster

LOD Terrain system:

This is my LOD terrain system I've currently implemented in the project - "Hellhound" utilizing the Ogre3D graphics engine and the NxOgre wrapper for PhysX.

The Concept

The concept is that of a 3x3 grid system with the player in the middle. As the player moves from one square to another, the terrain system re-centers itself, disabling squares that have moved out of range, and enabling those that have moved within range.

Code

• Terrain.h
• Terrain.cpp

How it works

Each terrain block maintains pointers to its neighbors. Upon becoming the center, it will disable all squares from the old center in the opposite direction it came from, and enable the squares adjacent to it which are still inactive. Re-centering is intended to be activated on an endTouch collision event, when the player is no longer touching the block that was the center. The player keeps track of all terrain blocks touched, and re-centers on the one it has been touching the longest. In the event of jumping, the previous square will maintain the center, and a new center will be corrected on the next startTouch if the jump lands the character on a non-center square. This allows for switching to lower poly-count meshes for blocks of terrain that are not activated; enabling the game to use more detailed terrains.

Setup is done by creating the block, and passing in the name of the block's neighbors. When the level is loaded, the function is called to connect the blocks which queries the NxOgre Scene for the blocks. Errors are output to log.

Limitations

I believe with any system it is important to know its limitations. This system works as-is for my project, but can be broken in multiple ways.

• Teleportation, or long distance throwing of the character will result in orphaned blocks remaining active until they are reconnected this is intended to be limited by the recursive "disableDirection" function which attempts to follow a chain of active blocks and disable them, but can't disable blocks which aren't connected by an active chain to the character.
• Jumping diagonally across might also end up in a situation as just described.
• A wrongly-named connection has the possibility of orphaning blocks. When this system is paired to a terrain-generation program intended to work with it this shouldn't be an issue, however for areas like caverns where this might have to be hand-stitched in an editor there is room for human error. The logging of connection errors attempts to make this easily detectable.

Potential

In addition to knowing a system's limitations, it's also important to know it's potential. This relatively straight-forward system has benefits beyond tying together blocks of terrain and swapping meshes.

• If enemies know what terrain they are on this allows for disabling or throttling down AI based on a simple boolean operation rather than distance checks.
• Environmental models out of view can be hidden or shown without possibly costly vertex-culling as long as sudden pops in visibility are avoided.
• Can act as a cheap LOD system for environment, enemies, or NPCs. Rather than hiding the models they can be switched to a lower poly-count mesh. Rather than checking distance.
• Expansion:
  • Removing or dampening the limitations previously mentioned through changing re-centering to be based on raycasting or brute-force checking of the previous center to disable any that are not in the new center rather than in a direction.
  • Expanding the system from a 3x3 grid to a 5x5 or 7x7 grid - this allows for even more LOD possibilities.