User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
matsys:cmat_manual:texturemapspecifications [2006-07-30 00:38]
127.0.0.1 (old revision restored)
matsys:cmat_manual:texturemapspecifications [2013-01-07 12:07] (current)
Line 17: Line 17:
 Map compositions are normally just the path plus file name of a texture image relative to the MOD directory, like for example ''​Textures/​Kai/​3r_metpan01_diff.png''​. However, map compositions can also be more complex constructs as explained in the next section [[matsys::​cmat_manual::​TextureMapSpecifications#​map_compositions|Map Compositions]]. Map compositions are normally just the path plus file name of a texture image relative to the MOD directory, like for example ''​Textures/​Kai/​3r_metpan01_diff.png''​. However, map compositions can also be more complex constructs as explained in the next section [[matsys::​cmat_manual::​TextureMapSpecifications#​map_compositions|Map Compositions]].
  
-The initial keyword (''​diffusemap''​ etc.) defines how the texture image is used in dynamic lighting computations during rendering. This is very similar to Doom3 materials, and both Ca3DE and Doom3 implement in this regard a form of the //Phong lighting model//.+The initial keyword (''​diffusemap''​ etc.) defines how the texture image is used in dynamic lighting computations during rendering. This is very similar to Doom3 materials, and both Cafu and Doom3 implement in this regard a form of the //Phong lighting model//.
  
 Here comes a list of all available keywords for texture map specifications,​ along with a short description of their default meaning. (The default is dynamic Phong lighting, which however can be overridden, as explained at [[matsys::​cmat_Manual::​ShaderSpecifications]].) Here comes a list of all available keywords for texture map specifications,​ along with a short description of their default meaning. (The default is dynamic Phong lighting, which however can be overridden, as explained at [[matsys::​cmat_Manual::​ShaderSpecifications]].)
Line 30: Line 30:
   * **''​lumamap''​** This texture map image defines the luminance for this material. Note that the light emittance that is defined here is local only (as is a general property of the Phong lighting model). It is not cast onto other surfaces.   * **''​lumamap''​** This texture map image defines the luminance for this material. Note that the light emittance that is defined here is local only (as is a general property of the Phong lighting model). It is not cast onto other surfaces.
  
-  * **''​lightmap''​** This materials lightmap image. This image is normally computed and provided by the 3D engine or the program with which you use the material. Although you can provide texture map file names as for the above keyword, that rarely ever makes sense. Normally, simply specify the special lightmap ''​$lightmap''​ in combination with the ''​lightmap''​ keyword in order to use whatever lightmap the 3D engine provides for this material. This is demonstrated in the preceding example.+  * **''​lightmap''​** This materials lightmap image. This image is normally computed and provided by the Cafu engine or the program ​(e.g. the material viewer or CaWE) with which you use the material. Although you can provide texture map file names as with the above keywords, that rarely ever makes sense. Normally, simply specify the special lightmap ''​$lightmap''​ in combination with the ''​lightmap''​ keyword in order to use whatever lightmap the Cafu engine provides for this material. This is demonstrated in the preceding example. \\ :!: If you don't use this keyword at all, or specify something different than ''​$lightmap'',​ the compile tools will not cover surfaces that use this material with a lightmap, and these surfaces will neither receive nor reflect Radiosity light. Note that for many effect materials, this is desired and very useful behaviour, as for example with decals, skies, water surfaces etc.
  
   * **''​shlmap''​** The image that contains color-encoded coefficients for //Spherical Harmonic Lighting// for this material. As for lightmaps, you may specify arbitrary texture map file names with this keyword, but normally just use ''​$shlmap''​ in order to let the engine supply the proper SHL map.   * **''​shlmap''​** The image that contains color-encoded coefficients for //Spherical Harmonic Lighting// for this material. As for lightmaps, you may specify arbitrary texture map file names with this keyword, but normally just use ''​$shlmap''​ in order to let the engine supply the proper SHL map.
  
-  * **''​cubeMap''​** A six-sided cube-map image that is used e.g. for environmental mapping. Normally, cube-map specifications are per default //​ignored//,​ because they are not regularly used with Phong lighting. Instead, they are specially activated as described in section [[matsys::​cmat_Manual::​ShaderSpecifications]]. As a single cube-map is actually composed of six individual images, a special convention for its file name is employed: A ''​%%'#'​%%''​ character in the file name is automatically replaced with the six possible cube-map suffixes _px, _nx, _py, _ny, _pz and _nz. For example, consider this material definition from the ''​Ca3D-Engine/​Games/​DeathMatch/​Materials/​SkyDomes.cmat''​ file: <​code>​+  * **''​cubeMap''​** A six-sided cube-map image that is used e.g. for environmental mapping. Normally, cube-map specifications are per default //​ignored//,​ because they are not regularly used with Phong lighting. Instead, they are specially activated as described in section [[matsys::​cmat_Manual::​ShaderSpecifications]]. As a single cube-map is actually composed of six individual images, a special convention for its file name is employed: A ''​%%'#'​%%''​ character in the file name is automatically replaced with the six possible cube-map suffixes _px, _nx, _py, _ny, _pz and _nz. For example, consider this material definition from the ''​Cafu-9.06/​Games/​DeathMatch/​Materials/​SkyDomes.cmat''​ file: <​code>​
     Textures/​SkyDomes/​PK_BrightDay2     Textures/​SkyDomes/​PK_BrightDay2
     {     {
Line 79: Line 79:
   * **''​hm2nm(e1,​ scale)''​** Assumes that ''​e1''​ is a gray-scale heightmap and converts it into a normal-map. The relative height of the heightmap is scaled by factor ''​scale''​ in order to weaken or pronounce the resulting effect. Values between 1.0 and 10.0 are normal use, but numbers greater than 10.0, less than 1.0, or even negative numbers are allowed, too.   * **''​hm2nm(e1,​ scale)''​** Assumes that ''​e1''​ is a gray-scale heightmap and converts it into a normal-map. The relative height of the heightmap is scaled by factor ''​scale''​ in order to weaken or pronounce the resulting effect. Values between 1.0 and 10.0 are normal use, but numbers greater than 10.0, less than 1.0, or even negative numbers are allowed, too.
  
-  * **''​flipNMyAxis(e1)''​** Considers the colors of ''​e1''​ as color compressed normal-vectors,​ and flips their y-component. This is useful for normal-maps that have their y-component pointing into the wrong direction. Such normal-maps occurred in the early days of dynamic lighting or were created for other programs than Ca3DE. This function is for fixing such cases, and should rarely be needed.+  * **''​flipNMyAxis(e1)''​** Considers the colors of ''​e1''​ as color compressed normal-vectors,​ and flips their y-component. This is useful for normal-maps that have their y-component pointing into the wrong direction. Such normal-maps occurred in the early days of dynamic lighting or were created for other programs than Cafu. This function is for fixing such cases, and should rarely be needed.
  
   * **''​renormalize(e1)''​** Considers the colors of ''​e1''​ as color compressed normal-vectors,​ and renormalizes them (scales them to unit length). This is mostly useful for testing and debugging.   * **''​renormalize(e1)''​** Considers the colors of ''​e1''​ as color compressed normal-vectors,​ and renormalizes them (scales them to unit length). This is mostly useful for testing and debugging.
Line 90: Line 90:
 i.e. they work with ''​diffusemap'',​ ''​normalmap'',​ ''​specularmap'',​ ''​cubemap'',​ etc. i.e. they work with ''​diffusemap'',​ ''​normalmap'',​ ''​specularmap'',​ ''​cubemap'',​ etc.
  
-Technically,​ a map composition is completed before the Ca3D-Engine ​or the graphics board see them.+Technically,​ a map composition is completed before the Cafu engine ​or the graphics board see them.
 In other words, the engine or the 3D hardware never see the individual images, only the composite result. In other words, the engine or the 3D hardware never see the individual images, only the composite result.
 //​Everything that is done by these composition steps could also be pre-worked by the artist in an image processing software. There would be **no** difference for the engine, the hardware, or in the resource (memory) consumption.//​ //​Everything that is done by these composition steps could also be pre-worked by the artist in an image processing software. There would be **no** difference for the engine, the hardware, or in the resource (memory) consumption.//​
Line 111: Line 111:
   * **''​wrapS''​** This controls horizontal texture coordinate wrapping and must be followed by one of   * **''​wrapS''​** This controls horizontal texture coordinate wrapping and must be followed by one of
     * **''​repeat''​** for repeating the texture in horizontal direction. This is the default.     * **''​repeat''​** for repeating the texture in horizontal direction. This is the default.
-    * **''​clamp''​** for clamping the texture in horizontal direction, taking the border color into account. As the Ca3DE MatSys never uses or sets the border color, using ''​clamp''​ is rarely ever useful.+    * **''​clamp''​** for clamping the texture in horizontal direction, taking the border color into account. As the Cafu MatSys never uses or sets the border color, using ''​clamp''​ is rarely ever useful.
     * **''​clampToEdge''​** for clamping the texture in horizontal direction to its edge color. Often useful with cube-maps or terrain base images.     * **''​clampToEdge''​** for clamping the texture in horizontal direction to its edge color. Often useful with cube-maps or terrain base images.
  
   * **''​wrapT''​** This controls vertical texture coordinate wrapping and must be followed by one of   * **''​wrapT''​** This controls vertical texture coordinate wrapping and must be followed by one of
     * **''​repeat''​** for repeating the texture in vertical direction. This is the default.     * **''​repeat''​** for repeating the texture in vertical direction. This is the default.
-    * **''​clamp''​** for clamping the texture in vertical direction, taking the border color into account. As the Ca3DE MatSys never uses or sets the border color, using ''​clamp''​ is rarely ever useful.+    * **''​clamp''​** for clamping the texture in vertical direction, taking the border color into account. As the Cafu MatSys never uses or sets the border color, using ''​clamp''​ is rarely ever useful.
     * **''​clampToEdge''​** for clamping the texture in vertical direction to its edge color. Often useful with cube-maps or terrain base images.     * **''​clampToEdge''​** for clamping the texture in vertical direction to its edge color. Often useful with cube-maps or terrain base images.
  
-  * **''​noScaleDown''​** specifies that the texture image is never scaled down, not even if the user selects a medium or low texture detail setting for tuning the graphics performance. Useful for fonts, HUDs, lightmaps (implicitly),​ some model textures (see example below), and everything else that must not get mixed up or blurred by image filtering. Also used e.g. for the Ca3DE splash screen logo, which would get blurred otherwise (look into ''​Games/​DeathMatch/​Materials/​Splash.cmat''​ if you want to toy around with it  a little :-) ).+  * **''​noScaleDown''​** specifies that the texture image is never scaled down, not even if the user selects a medium or low texture detail setting for tuning the graphics performance. Useful for fonts, HUDs, lightmaps (implicitly),​ some model textures (see example below), and everything else that must not get mixed up or blurred by image filtering. Also used e.g. for the Cafu splash screen logo, which would get blurred otherwise (look into ''​Games/​DeathMatch/​Materials/​Splash.cmat''​ if you want to toy around with it  a little :-) )
 + 
 +  * **''​noCompression''​** exempts this texture image from being stored in a compressed format in video memory, even if the user generally enabled texture compression for tuning the graphics performance. \\ In the Cafu engine, texture compression is by default enabled for all texture images except normal-maps. Although Cafu automatically selects and employs the latest and highest quality compression method that the graphics driver offers (this even works when the Cafu executable is //older// than the driver!), sometimes the compression process comes with some loss of image detail or introduces small artifacts. ''​noCompression''​ can then be used to ensure no compression for a particular texture. 
 + 
 +  * **''​useCompression''​** is more or less the opposite of ''​noCompression'':​ it turns compression back on. Normally there is no reason to ever use this keyword. It exits for symmetry to ''​noCompression''​ and because ''​noCompression''​ is the default for normal-maps:​ if you want to have compression enabled for a particular normal-map, specifying ''​useCompression''​ will turn it on. However, please note that compression artifacts in normal-maps tend to disturb the lighting computations so much that the generated output images drop to questionable quality. \\ Also note that ''​useCompression''​ is "​weak":​ If the user generally disables all compression,​ it will have no effect.
  
 The meaning of the ''​minFilter'',​ ''​magFilter'',​ ''​wrapS''​ and ''​wrapT''​ options is analogous to their respective meanings in the OpenGL and DirectX APIs. The OpenGL Programming Guide (the "Red Book") about OpenGL version 1.2 and higher has a good explanation about these options. Although the text is specific to OpenGL, the same concepts apply to the above mentioned options. The "Red Book" for version 1.1 does not address the ''​clampToEdge''​ option, but its text is available online at [[http://​www.rush3d.com/​reference/​opengl-redbook-1.1/​chapter09.html]]. The meaning of the ''​minFilter'',​ ''​magFilter'',​ ''​wrapS''​ and ''​wrapT''​ options is analogous to their respective meanings in the OpenGL and DirectX APIs. The OpenGL Programming Guide (the "Red Book") about OpenGL version 1.2 and higher has a good explanation about these options. Although the text is specific to OpenGL, the same concepts apply to the above mentioned options. The "Red Book" for version 1.1 does not address the ''​clampToEdge''​ option, but its text is available online at [[http://​www.rush3d.com/​reference/​opengl-redbook-1.1/​chapter09.html]].
matsys/cmat_manual/texturemapspecifications.1154212711.txt.gz · Last modified: 2013-01-07 12:07 (external edit)