User Tools
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
matsys:cmat_manual:texturemapspecifications [2005-10-22 20:41] Carsten fixed links |
matsys:cmat_manual:texturemapspecifications [2006-11-14 21:45] Carsten Added the noCompression and forceCompression keyword descriptions |
||
|---|---|---|---|
| Line 20: | Line 20: | ||
| 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]].) | ||
| + | |||
| * **''diffusemap''** The texture map image that defines the diffuse color (or diffuse reflectivity) of the material. The alpha channel of the diffuse-map specifies the translucency of the material. | * **''diffusemap''** The texture map image that defines the diffuse color (or diffuse reflectivity) of the material. The alpha channel of the diffuse-map specifies the translucency of the material. | ||
| Line 50: | Line 51: | ||
| You can specify arbitrary combinations of these keywords in one material, as only the ''diffusemap'' keyword is mandatory. | You can specify arbitrary combinations of these keywords in one material, as only the ''diffusemap'' keyword is mandatory. | ||
| However, if you use the same keyword more than once, only the last occurrence is considered. The order of the keywords occurrences is not relevant. | However, if you use the same keyword more than once, only the last occurrence is considered. The order of the keywords occurrences is not relevant. | ||
| - | |||
| ===== Map Compositions ===== | ===== Map Compositions ===== | ||
| - | Texture map image specifications with the above keywords can not only be simple file names, but also by more powerful **Map Compositions**. A map composition is a description of how a //single// texture map image is composited from several source images on disk. | + | Texture map image specifications with the above keywords can not only be simple file names, but also be more powerful **Map Compositions**. A map composition is a description of how a //single// texture map image is composited from several source images on disk. |
| Here is an example for a simple material whose normal-map is defined by a complex map composition: | Here is an example for a simple material whose normal-map is defined by a complex map composition: | ||
| <code> | <code> | ||
| Line 77: | Line 77: | ||
| * **''combineNMs(e1, e2)''** Treats the colors of ''e1'' and ''e2'' as color-compressed normal vectors, and combines or "adds" them in a mathematically correct fashion. (This it //not// the same as the ''add(...)'' operation.) | * **''combineNMs(e1, e2)''** Treats the colors of ''e1'' and ''e2'' as color-compressed normal vectors, and combines or "adds" them in a mathematically correct fashion. (This it //not// the same as the ''add(...)'' operation.) | ||
| - | * **''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 then 10.0, less then 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 Ca3DE. This function is for fixing such cases, and should rarely be needed. | ||
| Line 112: | Line 112: | ||
| * **''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 Ca3DE 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-map 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 Ca3DE 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-map 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. 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 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 :-) ). |
| + | |||
| + | * **''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 Ca3D-Engine, texture compression is by default enabled for all texture images except normal-maps. Although Ca3DE automatically selects and employs the latest and highest quality compression method that the graphics driver offers (this even works when the Ca3DE 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]]. | ||
| + | |||
| + | The options ''noScaleDown'' and ''minFilter bilinear'' are often combined, because both scaling down textures for better graphics performance as well as using ''trilinear'' filtering for rendering have a tendency to mix the colors of neighboring pixels. In some cases such as font textures, even the ''bilinear'' filtering is too much mix-up, requiring us to combine ''noScaleDown'' with ''minFilter nearest''. | ||
| + | |||
| + | |||
| + | === Options Example 1 === | ||
| Here is an example from ''Games/DeathMatch/Materials/Fonts.cmat'' that demonstrates how the options are used: | Here is an example from ''Games/DeathMatch/Materials/Fonts.cmat'' that demonstrates how the options are used: | ||
| Line 129: | Line 138: | ||
| diffusemap ../../Fonts/Arial.png, minFilter nearest, magFilter nearest, noScaleDown | diffusemap ../../Fonts/Arial.png, minFilter nearest, magFilter nearest, noScaleDown | ||
| // ... | // ... | ||
| + | } | ||
| + | </code> | ||
| + | |||
| + | |||
| + | === Options Example 2 === | ||
| + | |||
| + | Another example for the ''noScaleDown'' and ''minFilter'' keywords. | ||
| + | |||
| + | {{matsys:example_nomipmaps_1.png }} This is a typical skin texture that a modeller has produced for application to one of his model meshes. <clear> | ||
| + | |||
| + | {{matsys:example_nomipmaps_2.png }} A straightforward material definition would look like this: | ||
| + | <code> | ||
| + | Models/Players/Trinity/trinityskin3 | ||
| + | { | ||
| + | diffusemap Models/Players/Trinity_Skin_diff.png | ||
| + | |||
| + | red ambientLightRed | ||
| + | green ambientLightGreen | ||
| + | blue ambientLightBlue | ||
| + | } | ||
| + | </code> | ||
| + | The image to the left shows the result of the this material definition being applied to a model mesh. | ||
| + | Notice the small glitch in the image, which is a result of mipmaps being applied to the above shown texture: Mip-mapping mixes black pixels of the hair with adjacent, bright pixels of the skin, yielding the intermediate colors that are marked in the result image to the left. | ||
| + | Such glitches are even more disturbing and better visible with animated models, e.g. when the head of the model slightly turns. | ||
| + | |||
| + | Note that these kinds of artifacts are //no// bugs, they are a normal result from mipmap filtering. <clear> | ||
| + | |||
| + | {{matsys:example_nomipmaps_3.png }} With the ''noScaleDown'' and ''minFilter bilinear'' keywords applied in the material script, the glitch disappears as shown here: | ||
| + | <code> | ||
| + | Models/Players/Trinity/trinityskin3 | ||
| + | { | ||
| + | diffusemap Models/Players/Trinity_Skin_diff.png, minFilter bilinear, noScaleDown | ||
| + | |||
| + | red ambientLightRed | ||
| + | green ambientLightGreen | ||
| + | blue ambientLightBlue | ||
| } | } | ||
| </code> | </code> | ||
matsys/cmat_manual/texturemapspecifications.txt · Last modified: 2013-01-07 12:07 (external edit)