User Tools

Site Tools


Differences

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

Link to this comparison view

Next revision
Previous revision
matsys:cmat_manual:shaderspecifications [2005-10-22 20:24]
Carsten created
matsys:cmat_manual:shaderspecifications [2013-01-07 12:07] (current)
Line 9: Line 9:
 The good news is that the MatSys renderers have more shaders built-in than just those that are considered during the automatical selection. They are documented below, inclusive sample material definitions,​ and you can use them to override the auto-selection. Alternatively,​ if you know or are a programmer, you can also make your own shaders. By making own shaders you gain the greatest flexibility that you can get, because only shaders eventually define how materials look, and shaders can do everything that the underlying hardware can do! Creating own shaders is documented at [[matsys::​Writing_Shaders]]. The good news is that the MatSys renderers have more shaders built-in than just those that are considered during the automatical selection. They are documented below, inclusive sample material definitions,​ and you can use them to override the auto-selection. Alternatively,​ if you know or are a programmer, you can also make your own shaders. By making own shaders you gain the greatest flexibility that you can get, because only shaders eventually define how materials look, and shaders can do everything that the underlying hardware can do! Creating own shaders is documented at [[matsys::​Writing_Shaders]].
  
-There is another issue that you should know about shaders: Each material gets not only one shader assigned, but //two//. This is because the Ca3DE Material System renders materials in two steps: First, the //ambient// part of a material is rendered, that is, everything that is rendered even if no light source is present. The //ambient shader// of a material is responsible for how this part is rendered. Then, the parts of the material looks that are contributed by each light source are rendered separately, as for example diffuse reflections,​ specular highlights and other effetcs. The per-light-source contributions are controlled by the //light shader// of a material.+There is another issue that you should know about shaders: Each material gets not only one shader assigned, but //two//. This is because the Cafu Material System renders materials in two steps: First, the //ambient// part of a material is rendered, that is, everything that is rendered even if no light source is present. The //ambient shader// of a material is responsible for how this part is rendered. Then, the parts of the material looks that are contributed by each light source are rendered separately, as for example diffuse reflections,​ specular highlights and other effetcs. The per-light-source contributions are controlled by the //light shader// of a material.
  
 You set the ambient and light shader of a material (and thereby override the automatic selection) with the following keywords in the material definitions body: You set the ambient and light shader of a material (and thereby override the automatic selection) with the following keywords in the material definitions body:
Line 37: Line 37:
  
 The following special-purpose shaders are currently built into all renderers of the MatSys. Please note these shaders and their related examples are pretty advanced, and you might want to skip them until later. It may be convenient to first finish reading the rest of this documentation,​ which will help to fully understand the special-purpose shader examples. The following special-purpose shaders are currently built into all renderers of the MatSys. Please note these shaders and their related examples are pretty advanced, and you might want to skip them until later. It may be convenient to first finish reading the rest of this documentation,​ which will help to fully understand the special-purpose shader examples.
- 
  
 ==== The SkyDome Shader ==== ==== The SkyDome Shader ====
Line 81: Line 80:
 The **''​cubeMap ...''​** statement specifies the cube-map that is to be used for this sky. If you also specified other texture maps like diffuse-maps or specular-maps,​ they would simply be ignored, as the **''​A_SkyDome''​** shader has no use for them. The **''​cubeMap ...''​** statement specifies the cube-map that is to be used for this sky. If you also specified other texture maps like diffuse-maps or specular-maps,​ they would simply be ignored, as the **''​A_SkyDome''​** shader has no use for them.
  
-The remaining keywords further specify important properties of this material. Please refer to section [[#​Keyword_Reference|Keyword Reference]] for a detailed description. Short explanations of their meanings are given in the comments in the above example.+The remaining keywords further specify important properties of this material. Please refer to section [[MatSys::​cmat_Manual::​KeywordReference]] for a detailed description. Short explanations of their meanings are given in the comments in the above example.
  
 ==== The Terrain Shader ==== ==== The Terrain Shader ====
  
-The terrain shader exists in order to render the Ca3DE outdoor terrains, which work a bit different than regular, Phong-lit surfaces. You activate the ambient terrain shader by writing+The terrain shader exists in order to render the Cafu outdoor terrains, which work a bit different than regular, Phong-lit surfaces. You activate the ambient terrain shader by writing
 <​code>​ <​code>​
     AmbientShader A_Terrain     AmbientShader A_Terrain
Line 102: Line 101:
   - Dynamic light sources are normally very "​small"​ when being compared to the extends of terrains, and mappers tend to place them inside buildings rather than in the open area. This further limits the per-lightsource contribution on terrain surfaces.   - Dynamic light sources are normally very "​small"​ when being compared to the extends of terrains, and mappers tend to place them inside buildings rather than in the open area. This further limits the per-lightsource contribution on terrain surfaces.
   - I simply have not yet had the time to write the **''​L_Terrain''​** shader.   - I simply have not yet had the time to write the **''​L_Terrain''​** shader.
-:!: But if for example somebody wanted to model an indoor cave with the Ca3DE terrain technique, having a shader that accounts for the light of dynamic light sources even on terrains would make a lot of sense. Good news is that, as indicated above, it is //easy// to write such a shader -- I'll probably do so as soon as I need one.+:!: But if for example somebody wanted to model an indoor cave with the Cafu terrain technique, having a shader that accounts for the light of dynamic light sources even on terrains would make a lot of sense. Good news is that, as indicated above, it is //easy// to write such a shader -- I'll probably do so as soon as I need one.
  
 Next, the **''​A_Terrain''​** (and the future **''​L_Terrain''​**) shader requires a diffuse-map to be specified. This diffuse-map will be scaled to match the physical size of the terrain, that is, it will cover the terrain completely. In order to get the edges of the terrain properly textured, it makes sense to also specify **''​clampToEdge''​** border wrapping for the diffuse texture: Next, the **''​A_Terrain''​** (and the future **''​L_Terrain''​**) shader requires a diffuse-map to be specified. This diffuse-map will be scaled to match the physical size of the terrain, that is, it will cover the terrain completely. In order to get the edges of the terrain properly textured, it makes sense to also specify **''​clampToEdge''​** border wrapping for the diffuse texture:
Line 109: Line 108:
     lightmap $lightmap     lightmap $lightmap
 </​code>​ </​code>​
-As the Ca3D-Engine ​map compile tools will also generate a lightmap for the terrain in order to e.g. take sunlight or other radiosity light sources into account, we specify the **''​lightmap''​** keyword with the engine-supplied lightmap. Note that while the lighting of dynamic light-sources is //not// taken into account, the light of radiosity light sources //is//!+As the Cafu map compile tools will also generate a lightmap for the terrain in order to e.g. take sunlight or other radiosity light sources into account, we specify the **''​lightmap''​** keyword with the engine-supplied lightmap. Note that while the lighting of dynamic light-sources is //not// taken into account, the light of radiosity light sources //is//!
  
 Next, the **''​A_Terrain''​** shader employs the texture-map that is specified with the **''​lumamap''​** keyword as a //​detail-map//​ for the terrain. This is a good example for how the specification of a custom shader (here **''​A_Terrain''​**) can entirely alter the meaning of a material keyword. We will see below how the coarseness (the repetition-count) of the detail-map is set. Next, the **''​A_Terrain''​** shader employs the texture-map that is specified with the **''​lumamap''​** keyword as a //​detail-map//​ for the terrain. This is a good example for how the specification of a custom shader (here **''​A_Terrain''​**) can entirely alter the meaning of a material keyword. We will see below how the coarseness (the repetition-count) of the detail-map is set.
Line 173: Line 172:
 You can use the special **''​none''​** shader both as an ambient or a per-lightsource shader in order to have no shader for ambient or per-lightsource contributions at all. You can use the special **''​none''​** shader both as an ambient or a per-lightsource shader in order to have no shader for ambient or per-lightsource contributions at all.
  
-As you have seen in the examples above, this makes sense in several situations. Especially materials that are not affected by local, dynamic light sources often have the **''​LightShader none''​** statement, as for example for sky dome. Note that currently, you still have to combine any **''​LightShader none''​** statement with the **''​noDynLight''​** statement in order to take proper effect. The **''​noDynLight''​** will however become obsolete in future releases of the Ca3DE Material System.+As you have seen in the examples above, this makes sense in several situations. Especially materials that are not affected by local, dynamic light sources often have the **''​LightShader none''​** statement, as for example for sky dome. Note that currently, you still have to combine any **''​LightShader none''​** statement with the **''​noDynLight''​** statement in order to take proper effect. The **''​noDynLight''​** will however become obsolete in future releases of the Cafu Material System.
  
 Using **''​AmbientShader none''​** is much less frequently useful, and almost only ever employed for "​invisible"​ materials. Note that **''​AmbientShader none''​** also implies **''​LightShader none''​**. Also, in order to take proper effect, the **''​noDraw''​** keyword is required with each occurrence of **''​AmbientShader none''​**,​ but that requirement will be removed and **''​noDraw''​** be obsoleted in future versions of the MatSys. Using **''​AmbientShader none''​** is much less frequently useful, and almost only ever employed for "​invisible"​ materials. Note that **''​AmbientShader none''​** also implies **''​LightShader none''​**. Also, in order to take proper effect, the **''​noDraw''​** keyword is required with each occurrence of **''​AmbientShader none''​**,​ but that requirement will be removed and **''​noDraw''​** be obsoleted in future versions of the MatSys.
- 
matsys/cmat_manual/shaderspecifications.1130005493.txt.gz ยท Last modified: 2013-01-07 12:07 (external edit)