Creating Terrains for 3DView2
Terrains for 3DView2 consist of
- a height map
- a material map
- a number of terrain parameters
- a number of terrain textures
The terrain textures are defined in the visualization. A visualization is like a skin for 3DView2, it is described in an xml file defines the look of the world. Any number of terrains can use the same visualization and will therefore use the same terrain textures and have a similar look. You can also use the same terrain with different visualizations. For general information about visualizations see
Adding Things to 3DView2; the definition of terrain textures is covered later in this document.
The Height Map
A height map is a grayscale bitmap image. The color information in the image is interpreted as height data. The brighter a pixel is the higher is the terrain in that location. Consider a height map a top-down view of your terrain where mountains and hills are bright pixels while valleys are represented by dark pixels.
Height Maps for 3DView2 must be square and the edge length should be a power of two plus one, e.g. 129, 257, 513 or 1025. If these requirements are not met the bitmaps is automatically converted and resized accordingly; but this can lead to small unwanted artifacts and distortions.
Height Maps can be in almost any image format. JPG creates very small files which are ideal for people with a slow network connection, but the compression is lossy. PNG has lossless compression but the files are a good deal larger.
Keep in mind that larger maps are more demanding in terms of processing power and memory. It is not advisable to create maps much larger than 2049 pixels unless the machines you are targeting are very powerful.
The Material Map
A material map is a palette color bitmap image. The color information in the image is interpreted as a map of different ground materials.
Material Maps for 3DView2 should be square and the edge length must be the same as the height map minus 1 pixel. For instance, if your height map is 1025x1025 pixels, your material map should have a size of 1024x1024 pixels. If this condition is not met, the image is resized automatically but this can of course lead to unwanted artifacts in the image.
The material map
must be a
palette image. That means that it uses a palette of 256 colors and stores only a color index per pixel instead of storing individual color values per pixel. RGB color images will not work! A typical color palette image format is GIF. PNG supports palettes as well but is a bit more tricky since it also supports RGB and RGBA formats. All image processing programs should be able to handle GIF images and allow you to edit the color palette. GIF also has very nice lossless compression.
Every pixel in the material map represents a small portion of the terrain. The color index of the pixel defines the terrain type, i.e. the ground texture that is applied to this portion of the terrain. So color index 0 is terrain type 0, color index 1 terrain type 1 and so on. What the different terrain types are and how many different terrain types are available is defined by the visualization (see below). The actual color values (the palette colors) are not used. Therefore you can define the palette colors in a way that is convenient for editing. For instance, if color index 0 symbolized terrain type 'grass' then you could define palette entry 0 as green. Again, 3DView2 does not use this color.
3DView2 automatically creates soft transitions between different ground materials. There is no way you can influence these transitions; the system is designed for ease of use which means that artistic freedom has to be limited somewhat.
If a material map uses more terrain types than are defined by the visualization the excessive ones are displayed with a pink terrain texture in 3DView2.
Creating a Map File
There are two types of world map files: those for online and those for offline use. Online world files are used when you connect to a MicroPsi server. Offline files can be loaded and displayed without a server connection. The file format for both types is basically the same; there are some minor differences that will be covered in a moment.
World map files are xml files. The following is a typical example:
<world>
<description>The default island if the server does not specify one.</description>
<defaultvisualization>standard.xml</defaultvisualization>
<terrainmap>
<heightmap>square_128.jpg</heightmap>
<materialmap>square_material_128.gif</materialmap>
<offset>
<x>-18.000000</x>
<y>-2.000000</y>
<z>-78.000000</z>
</offset>
<scaling>
<x>0.750000</x>
<y>0.040000</y>
<z>0.750000</z>
</scaling>
<observerstartpos>
<x>-11.000000</x>
<y>13.500000</y>
<z>1.200000</z>
</observerstartpos>
<observerlookat>
<x>14.000000</x>
<y>3.050000</y>
<z>-18.000000</z>
</observerlookat>
<wraparound>false</wraparound>
</terrainmap>
<objects />
</world>The
description tag contains a textual description of the map file; it is used by the GUI.
defaultvisualization is the name of the visualization xml file this map will use by default; a different visualization may be selected at run-time.
heightmap and
materialmap are the file names of the height map and material map; both files must reside in the
data/terrain folder in the 3DView2 directory.
offset is the point in 3d world coordinates where the upper left corner of the height map will be. From there it will stretch in the direction of the positive x- and z-axis. Note that 3DView uses a different coordinate system that MicroPsi. In 3DView the positive y-axis points up while the z-axis ist the equivalent to the y-axis in MicroPsi.
scaling defines the size of the map in 3d space. With a scaling of (1, 1, 1) a height map of 257x257 pixels will be 256x256 units (meters) in 3d space and the highest elevation possible (perfectly white pixel) will be 256 units high. With a scaling of (2, 1, 2) the map will be 512x512 meters with the maximum terrain height unchanged.
observerstartpos and
observerlookat specify the point in 3d space where the camera will initially be situated after loading the map and the point the camera will initially look at.
The
objects tag contains world objects. You should use the built-in editor to place on the map, simply leave the tag empty.
Offline world files belong in the folder
data/offlineworlds in the 3DView2 directory and can have arbitrary names.
Online world files belong in the folder
data/offlineworlds in the 3DView2 directory. The names of online world files must match those of the terrain files on the server. The server currently uses bitmap files as terrain maps. For instance, when 3DView2 connects to a server that displays the terrain map "island.png" it will look for an online world file called "island.png.xml".
The
objects tag of an online world file should always be empty since the object list is received from the server. If the file does contain any objects they are simply ignored.
As far as
offset and
scaling are concerned, only the y coordinate is actually taken from the xml file. The values for the other axis are matched with the servers settings. The world on the server is essentially only two-dimensional, that is why the xml file is still necessary for the y-axis settings.
Terrain Textures
As stated in the beginning, terrain textures are part of the visualization xml file. There is a default visualization called
standard.xml which is a good starting point for creating your own visualizations.
Every visualization xml file must contain a
terrain block. Here is an example:
<terrain>
<mapdefaults> … </mapdefaults>
<texturetilesize>4.0</texturetilesize>
<materials>
<material>
<name>grass (0)</name>
<texture>terrain_grass.tga</texture>
</material>
<material>
<name>sand (1)</name>
<texture>terrain_sand.tga</texture>
</material>
<material>
<name>rock (2)</name>
<texture>terrain_rock.tga</texture>
</material>
<material>
<name>dense grass (3)</name>
<texture>terrain_forestfloor.jpg</texture>
</material>
</materials>
</terrain>The
mapdefaults tag contains map information just like an offline world file. This is meant as a default in case a world does not specify a map file (which hopefully never happens). There is no reason to change anything inside this tag, simply take it over from the default visualization.
The
materials tag defines the terrain types. The terrain types are assigned ID numbers in the order they appear in this file, starting with 0. So the first
material tag is terrain type 0, the second terrain type 1, the third 2 and so on. Every material tag contains a name, which is an arbitrary string and only for information purposes, and a texture file. The texture file can be in any well-established RGB or RGBA image file format. Terrain textures should - like all other textures - be square and should have an edge length that is a power of two.
Terrain textures are tiled over the whole terrain so you must make sure that terrain textures are tileable, i.e. the upper border of the texture must match the lower border and the left border must match the right one. The textures are laid out on a rectangular grid. With the
texturetilesize tag you can define the the size of that grid. This influences how much the textures are stretched - the is only a cosmetic issue, a little experimenting is necessary. It is important to understand that the value you set here is only a guiding value. The actual tile size must be aligned with the terrain chunk size; the terrain system will try to match the value you give as closely as possible.