SM3 Map Format: Difference between revisions
mNo edit summary |
m Cleaned it up, made the code sections work properly, stuff like that |
||
| Line 1: | Line 1: | ||
== 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. | 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: | 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: | ||
| Line 58: | Line 58: | ||
} | } | ||
} | } | ||
== Heightmap specification == | |||
The heightmap is specified with 3 tags located in the [TERRAIN] section: | The heightmap is specified with 3 tags located in the [TERRAIN] section: | ||
Heightmap: This should be either | '''Heightmap:''' This should be either: | ||
An 8 or 16 bit image file readable by DevIL | *An 8 or 16 bit image file readable by DevIL | ||
A 8 or 16 bit RAW file, such as generated by Terragen | *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. | 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: | The number of stages is given with the tag NumTextureStages like: | ||
NumTextureStages=2; | NumTextureStages=2; | ||
The first stage never has an operation: | The first stage never has an operation: | ||
[texstage0] | [texstage0] | ||
{ | { | ||
source=Snow; | |||
} | } | ||
Following stages can have "operation=add", "operation=mul", "operation=blend" | 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. | 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 | 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. | 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] | |||
{ | [texstage1] | ||
{ | |||
operation=blend; | |||
source=CrackedDirt; | |||
} | blender=RockBlender1026; | ||
} | |||
The avaiable operations are limited to add/mul/blend for techical reasons: | The avaiable operations are limited to add/mul/blend for techical reasons: | ||
| Line 121: | Line 124: | ||
Obviously because the first stage doesn't have any previous stage, the operation of the first stage is ignored | Obviously because the first stage doesn't have any previous stage, the operation of the first stage is ignored | ||
== Texture specification == | |||
== 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 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: | 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): | Tags (TODO: Document these): | ||
| Line 152: | Line 156: | ||
== Infomaps == | |||
The infomaps section defines the metal map and typemap. Both should be 8 bit images in any format DevIL accepts. | The infomaps section defines the metal map and typemap. Both should be 8 bit images in any format DevIL accepts. | ||
== TODO == | |||
* map features | * map features | ||
Revision as of 07:56, 20 July 2006
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 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
Texture specification
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
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;))