SM3 Map Format
|
Warning! This page is outdated! The information displayed may no longer be valid, or has not been updated in a long time. Please refer to a different page for current information. |
Development < Map Development < 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 improved lighting such as bumpmapping/specular mapping.
Hugh Perkins has been working on a SM3 map editor
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. It also has an extra tag in LIGHT (GroundSpecularColor):
[MAP]
{
// regular smd information, such as start positions,
// [WATER] and [ATMOSPHERE] sections...
[LIGHT]
{
// specular color, defaults to 0.1 0.1 0.1
GroundSpecularColor=0.3 0.3 0.3;
// other standard tags shared with SMF (such as GroundSunColor)...
}
[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
SpecularExponent=16; // specular exponent AKA
//shininess or polishedness. defaults to 8
[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 method specification (how are the textures applied)
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
Textures
Tiled textures
The operations usually have "source=texturename" in them, which points to the name of a tiled texture.
Example:
NumTextureStages=1;
[texstage0]
{
source=Snow;
}
[Snow]
{
File=Maps/dry_data/Snow_Sand.jpg;
TileSize=20;
}
Tilesize is how big a single tile is in the 3D spring world, when the texture is tiled across the map. Imagine a heightmap of 1025x1025 (In spring world space this is 1024*8= 8192x8192 units). When you set tilesize=4096, you will see the complete texture 4 times on the map (2 by 2). Set it to 8192 and you'll see the map completely covered.
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 too, with power-of-two dimensions like: 256x256, 512x512, 1024x1024. They should be smaller than the heightmap.
- 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.
Feature placement
The feature specification is done with a list of feature type names in the SM3 itself, and with a binary datafile that contains all the feature positions, orientations. Feature types are specified like this:
[FeatureTypes]
{
NumTypes=4;
type0=TreeType0; // a tree
type1=MyFeature;
type2=MyOtherFeature;
type3=GeoVent; // a geothermal
}
The feature binary file should be made with an editor. I'm hoping Maelstrom will add feature placing to his startpoint editor, but until then there's only http://user.supradigital.org/jcnossen/FeaturePlacer.zip
The "Pos:" fields are ment to enter the feature X,Y,Z. You can use zero for Y because spring will automatically put the feature on the ground when it loads. Type is the index into the feature type list specified in the SM3 file.
The feature data file should be linked to the SM3 with:
[MAP]
{
// other map tags ...
featuredata=FeatureDataFileName;
}
Minimap
The minimap is loaded from an image file that you have to set in the MAP section of the sm3 file. Example:
[MAP]
{
// other map tags ...
minimap=maps/data/minimap.png;
}
TODO
- fix bugs
