SM3 Map Format

Introduction

As opposed to the original SMF renderer, the SM3 map renderer allows multiple texture layers rendered on the terrain. This allows for higher texture resolutions and (eventually) improved lighting such as bumpmapping/specular mapping.

Map specification

Instead of a binary SMF file and a SMD file, all map information is now stored in a text based .SM3 file. This has the same basic layout as the original .SMD file, but it includes a [TERRAIN] section and an [INFOMAPS] section:

[MAP]
{
   ... regular smd information, such as start positions,
           [LIGHT],[WATER] and [ATMOSPHERE] sections...

	[INFOMAPS]
	{
		metal=Maps/dry_data/metalmap.png;
		type=Maps/dry_data/typemap.png;
	}
	[TERRAIN]
	{
		HeightScale=400.0;
		HeightOffset=10.0;
		Heightmap=Maps/dry_data/1026.png;

		NumTextureStages=2; // all texture stages are multiplied

		[texstage0]
		{
			// the first texture stage operation is ignored
			source=Snow;
		}
		[texstage1]
		{
// use the incoming alpha to blend between 2 textures
			operation=blend; 
			source=CrackedDirt;
			blender=RockBlender1026;
		}
/* texture definitions */
		[CrackedDirt]
		{
			File=Maps/dry_data/dirt2.jpg;
			Bumpmap=Maps/dry_data/dirt2_bm.jpg;
			TileSize=50;
		}
		[Snow]
		{
			File=Maps/dry_data/Snow_Sand.jpg;
			TileSize=20;
		}
		
/* blender definition, all blenders have "Blendmap=1" */
// a rock blender loaded from file for a specific map
		[RockBlender1026]
		{
			Blendmap=1;
			File=Maps/dry_data/1026_bm_small.png;
		}
	}
}

Heightmap specification

The heightmap is specified with 3 tags located in the [TERRAIN] section:

• Heightmap: This should be either
  • An 8 or 16 bit image file readable by DevIL
  • A 8 or 16 bit RAW file, such as generated by Terragen
• HeightScale and HeightOffset:

 The actual height of a heightmap pixel is calculated scaled by HeightScale, after which HeightOffset is added to it (height = pixel * HeightScale + HeightOffset)

Texturing specification

Texture stages/layers

Texturing of SM3 terrains works by a series of texture layers that are applied on top of eachother. These layers are called "texture stages". The stages can be added, multiplied, or alpha blended with the previous stage. This is defined by the stage operation.

The number of stages is given with the tag NumTextureStages like:

NumTextureStages=2;

The first stage never has an operation:

[texstage0]
{
	source=Snow;
}

Following stages can have "operation=add", "operation=mul", "operation=blend"

operation=add

The add operation needs a texture to add to the previous stage, which is specified with the "source=TextureName" tag. The texture specification is explained below.

[texstage1]
{
	operation=add;
	source=CrackedDirt;
}

operation=mul

Same as add, but with operation=mul

[texstage1]
{
	operation=mul;
	source=CrackedDirt;
}

operation=blend

The blend operation does alpha blending with an extra grayscale alpha texture. Specification of these alpha textures ("Blendmaps") is explained later in this doc. The blend operation needs a "blender=BlenderName" tag to work. I'm guessing most maps will only be using this operation.

[texstage1]
{
	operation=blend; 
	source=CrackedDirt;
	blender=RockBlender1026;
}

The avaiable operations are limited to add/mul/blend for techical reasons: This way even the most complex maps can be executed with multipass operations on any card with at least 2 textures units. It would even work on a Riva TNT I think.

Obviously because the first stage doesn't have any previous stage, the operation of the first stage is ignored

Blendmap specification

Blendmaps can either be loaded from file or generated from the terrain

Blendmaps from file

Blendmaps can be loaded from any grayscale file that DevIL can load:

[RockBlender]
{
	Blendmap=1;
	File=Maps/dry_data/1026_bm_small.png;
}

Generated blendmaps

Tags (TODO: Document these):

• coverage
• noise
• minSlope
• maxSlope
• minSlopeFuzzy
• maxSlopeFuzzy
• maxHeight
• minHeight
• maxHeightFuzzy
• minHeightFuzzy
• generatorLOD

Infomaps

The infomaps section defines the metal map and typemap. Both should be 8 bit images in any format DevIL accepts.

TODO

- map features - dynamic shadow mapping support - bumpmapping - specular mapping - a caching trick for very low end gfx hardware (partially done) - shadowmap storage, so the resolution can be increased - proper frustum culling, so big features work correctly (that is if features work at all;))