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;

Keep in mind that the stages are directly executed on your videocard. This means the more stages you make the slower the map will render.

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 Multiply

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. They are stretched across the full terrain, so in combination with the blend operation you can specify exactly where you want to see a specific texture on 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

Blendmaps can be generated from the heightmap. The final value is computed by

blendmap_value = SlopeTerm * HeightTerm * coverage * noise

The slope of the terrain is a value between 0 and 1, with 0 being flat and 1 being completely steep. Ofcourse with a heightmap the slope can only be near 1 and not exactly 1

The height of the terrain is between 0 and 1 (the minimum and maximum height value) If the height is between minHeight and maxHeight, HeightTerm will be 1. maxHeightFuzzy and minHeightFuzzy determine the "border" size between having a HeightTerm of 0 and a HeightTerm of 1.

GeneratorLOD indicates at which resolution the blendmap should be generated. The blendmap size will be (heightmapsize-1) / (2 ^ generatorLOD). For example with a heightmap width of 1025 and a generatorlod of 2, the blendmap size will be 1024/4=256.

(Images illustrating this will be added later)

Infomaps

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

Image file sizes

• The heightmap has to be square and its dimensions have to be a power-of-two + 1, like 257x257, 513x513, 1025x1025
• The blendmaps have to be square two, with power-of-two dimensions like: 256x256, 512x512, 1024x1024
• The tiled textures should have power-of-two dimensions, but don't have to be square
• The minimap can be anything, but it will be resized to an image of 1024x1024. Specifying a 1024x1024 will allow faster loading because no resizing is needed.
• Typemap and metalmaps dimensions should be (heightmapsize - 1) / 2, so when the heightmap is 1025x1025, the typemap is 512x512.
• The heightmap can be any DevIL supported format, or RAW such as exported by terragen. All the other maps/texture files can only be a DevIL format.

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