texture_mapping
\
This document is an addition to section 5.6 in the Homeworld Technical Design document. It will incorporate the latest information we have learned during POC development and creation of actual texture-mapped ships. This document is also a guideline for the development of the ‘final’ texture-mapping system.
The texture-map pipeline in Homeworld will allow artists to create textures in a paint program (Adobe Photoshop), apply them to 3D meshes in Lightwave (using Targa files), compile and view the results in Homeworld. This pipeline should be as simple as possible. The creation of the Photoshop file (.PSD) has only a few limitations on it; Targas (.TGA) are just copies of these .PSD files. The game will load .PSD files. It is not certain at this point if we will continue to use these .PSD files through to the end of the game, but it is possible. If we do, we will likely implement a trivial change to the .PSD file which prevents the player/hacker from loading them in and modifying them.
The creation of these .PSD files will be fairly standard. The particular methods employed by the artistic team will not be discussed here. A list of the limitations when creating these texture-maps follows:
-
Texture maps must be an even exponent of 2 on each axis. Examples are 2x2, 64x64, and 128x128.
-
Their sizes must be reasonable. 128x128 should be treated as a maximum size in all but very particular cases. A section on texture map memory sizes is included in this document.
-
They should consist of as few layers as possible. Because we will have to composite layers at load time, this can slow down the loading process. Because of this, it would be advantageous to have fewer layers. This will speed loading.
-
Some layers need to have particular names. There can be multiple layers of the same type, however some are treated specially. Following is a list of this label naming convention:
Layer type
Layer Name
Comments
Base texture
TEX*
Bottom-most layer and other basic texture details.
Color layers
COL1,COL2
The bias color of these layers changed by user. Includes base color and striping.
Badge
BADGE
Badge layer created by the badger. Should be empty when saved from Photoshop. Only one of these layers.
Panel lines-black and white
PB*, PW*
Panel lines combined with different blending functions.
Label layers
LAB*
Additional detail layers.
Dirt/subtle details
DIRT*
Additional details such as dirt, rust and subtle lighting.
Alpha channel
ALPHA
Determines what portions of the image are see-through. This layer must be the top layer. It can also not coexist with a luminance map.
Luminance map
LUMINANCE
Determines lighting information per-pixel. This layer cannot coexist with an alpha channel.
Total texture outline
OUTLINE
Black areas of this texture may be used by other textures.
\
The Homeworld texture-mapping system will have to deal with the fact that the computer it is running on will have a fairly arbitrary amount of RAM. It will have to be able to run on the minimum system and it will have to be able to take advantage of a system with a lot of texture RAM. The absolute worst case is where there is a scant 2Mb, and it all exists in CPU RAM of a 16 Mb system. At the same time, there are 8 players playing, plus all the pirates, traders and other nasty texture-users. This evaluates to about 35 ships per race, 12 pirate ships, several derelicts, a few asteroids and a handful of textures for effects. In other words, about 300 texture mapped objects. The minimum amount of RAM required says that this will evaluate to about 7k per ship. This allows a mere 32 * 64 per ship in 16-bit color. It is apparent that some creative measures must be taken to fit these numerous textures into a limited amount of texture RAM.
\
The first of these measures is to use 8-bit paletted texture maps. This increases the size available for each ship by 2. Also, we will have a system of combining texture maps for the same ship from multiple teams into one. This will enable us to have approximately 128 * 64 per ship. Levels of progression which are not accounted for with this scheme.
\
First of all, instead of having separate textures for each team in multi-player, we have only Race 1 and 2. The team colours are done totally with differing palettes. Secondly, all the progressions (there will not be all that many new texture maps due to progressions) will be loaded in beforehand or there will be none at all. Additionally, all the badges will be done as separate polygons to be rendered with a polygon offset function or not used at all. Also, we can compress textures better by using unused space in the rectangle of a larger texture for storing all or part of other small textures. These schemes will allow us to fit ships in a lot better. Have a look-see:
-
2Mb texture RAM.
-
Subtract 10% for backgrounds.
-
each of 8 players has 1 badge of 32 * 32 each.
-
28 textured objects per race, 2 races.
-
no pirates, but traders (perhaps), asteroids and say 3 derelicts.
-
LOD multiplies textures by requirements by 1.333 for each texture
-
Add in about 4 ships’ worth for sprites. Now here’s what we have:
\
(2097152 * .9 - 8 * 16 * 16) / 1.3333 / (56 + 1 + 3 + 1 + 4) = ~22k per ship. This is about the same as a 128 * 164.
\
Now that we’ve had the bad case and the worse case, here’s a good case:
-
4Mb texture RAM.
-
subtract 10% for background.
-
each of 2 races has 4 badges of 32 * 32 each.
-
20 textured objects per race, 2 races.
-
6 pirates, traders, asteroids, 2 derelicts.
-
figure the LOD
-
Add 2 ships’ worth of sprites.
\
(4194304 * .9 - 2 * 4 * 32 * 32) / 1.3333 / (40 + 6 + 1 + 3 + 2 + 2) = ~52k per ship or roughly 256 * 196.
\
Based upon the limitations we have run into concerning texture space requirements, here is a list of the solutions we have come up with:
-
Texture maps use varying palettes to reflect the differences in teams. This will mean we only have to load in the textures for at most the 2 races, not the 8 teams.
-
Perhaps remove some of the ships. Ships currently on the chopping block include the defenders, heavy/light distinction in fighters and the repair corvette.
-
Simplify and limit the badging. Players will have only a single badge for all ships, plus they will be only placed upon special polygons using polygon offset functionality. These polygons can be created by the Badger so that they can be moved about and placed by the user. Therefore, these polygons would have to conform to the surface of the ship.
-
Research will not add any, or very many new texture maps. Research upgrades have always been a problem because they require either instanced textures per player or for each level of progression.
-
Cached/compressed textures. While we will avoid this requirement in the first implementation, we should implement the possibility of this mechanism in our first pass to make it easier should we later need to implement it.