diff --git a/docs/shaderManual/alpha-channels.html b/docs/shaderManual/alpha-channels.html index b736290b..661fff8c 100644 --- a/docs/shaderManual/alpha-channels.html +++ b/docs/shaderManual/alpha-channels.html @@ -91,7 +91,7 @@
Start with a TGA file image. In this case, a pentagram on a plain white field (figure 1A). The color of the field surrrounding the image to be merged is not relevant to this process (although having a hard-edged break between the image to be isolated and the field makes the mask making process easier). Make an alpha channel. The area of the image to be merged with another image is masked off in white. The area to be masked out (notused) is pure black (figure 1B). The image to be merged into is greenfloor.tga (figure 1C).
-Make a qer_editorimage of greenfloor.tga. This is placed in the frame buffer as the map image for the texture. By using GL_SRC_ALPHA as the source part of the blend equation, the shader adds in only the non-black parts of the pentagram. Using GL_MINUS_ONE_SRC_ALPHA, the shader inverts the pentagram's alpha channel and adds in only the non-black parts of the green floor.
+Make a qer_editorImage of greenfloor.tga. This is placed in the frame buffer as the map image for the texture. By using GL_SRC_ALPHA as the source part of the blend equation, the shader adds in only the non-black parts of the pentagram. Using GL_MINUS_ONE_SRC_ALPHA, the shader inverts the pentagram's alpha channel and adds in only the non-black parts of the green floor.
In a like manner, the alpha channel can be used to blend the textures more evenly. A simple experiment involves using a linear gradiant in the alpha channel (white to black) and merging two textures so they appear to cross fade into each other.
diff --git a/docs/shaderManual/contents.html b/docs/shaderManual/contents.html index 9b4aabf4..2f2f6d89 100644 --- a/docs/shaderManual/contents.html +++ b/docs/shaderManual/contents.html @@ -57,171 +57,171 @@Sometimes laying out perfect patch meshes aligned with geometry is too much of a pain in the ass. Enter _decal entities. Add the following to your entities.def (Enemy Territory mappers should already have it):
@@ -121,7 +121,7 @@Make sure you compile with a recent (post-2.5) version of Q3Map2 with _decal support.
-It will project onto terrain, brushes, models, patches, whatever. To suppress decals on particular shaders, use surfaceparm nomarks.
+It will project onto terrain, brushes, models, patches, whatever. To suppress decals on particular shaders, use surfaceparm nomarks.
Happy decaling!
diff --git a/docs/shaderManual/foghull.html b/docs/shaderManual/foghull.html index 1dcbb4b8..9988cdcb 100644 --- a/docs/shaderManual/foghull.html +++ b/docs/shaderManual/foghull.html @@ -61,12 +61,12 @@Since distance clipping is not a feature natively built into Quake III Arena, using distance culling would result in a hall of mirrors (HOM) effect where the culled geometry begins, since nothing is being drawn in the frame buffer. To compensate for this, the foghull feature uses a series of six skybox images that are drawn in place of the absent culled geometry, thus preventing the HOM effect.
The skybox images used with the foghull feature should never be actually seen since the idea is to use the fog to obscure the maximum distance that the player can see. It only exists to prevent the HOM effect. To pull this off in a convincing manner, the skybox images should be six identical 8x8 pixel (to save on texture memory) textures each filled with a flat color matching the exact color of the fog. The six skybox images must be named in accordance to the skyParms farbox convention, using the _ft, _rt, _bk, _lf, _up, _dn suffixes.
+The skybox images used with the foghull feature should never be actually seen since the idea is to use the fog to obscure the maximum distance that the player can see. It only exists to prevent the HOM effect. To pull this off in a convincing manner, the skybox images should be six identical 8x8 pixel (to save on texture memory) textures each filled with a flat color matching the exact color of the fog. The six skybox images must be named in accordance to the skyParms farbox convention, using the _ft, _rt, _bk, _lf, _up, _dn suffixes.
Two shaders are required when using the foghull feature, a fog volume shader and a skybox shader, both of which are simple, standard shaders.
-The color of the fog used must match the color used in the skybox images. Any decent image editing software will give you the three RGB color values of your skybox images, which must be normalized by dividing by 255. As with any other fog shader, the fogParms and surfaceparm fog keywords must be present.
+The color of the fog used must match the color used in the skybox images. Any decent image editing software will give you the three RGB color values of your skybox images, which must be normalized by dividing by 255. As with any other fog shader, the fogParms and surfaceparm fog keywords must be present.
textures/env/fog1024 @@ -84,7 +84,7 @@-Foghull Shaders
}
The skyParms and surfaceparm sky keywords must be used to create the skybox "hull" of the map. The skyParms farbox value must point to the base name of the skybox images (sans suffix). Optional surface emitted sun lighting can be added using q3map_skylight with q3map_sun or q3map_sunExt (see Appendix I: Light Emitting Shaders).
+The skyParms and surfaceparm sky keywords must be used to create the skybox "hull" of the map. The skyParms farbox value must point to the base name of the skybox images (sans suffix). Optional surface emitted sun lighting can be added using q3map_skylight with q3map_sun or q3map_sunExt (see Appendix I: Light Emitting Shaders).
textures/skies/foghullsky diff --git a/docs/shaderManual/fur.html b/docs/shaderManual/fur.html index c021fdd6..5caba8af 100644 --- a/docs/shaderManual/fur.html +++ b/docs/shaderManual/fur.html @@ -77,7 +77,7 @@q3map_cloneShader
q3map_fur generates additional surfaces above the base shader. The q3map_fur directive takes a few values: layers, offset and fade. Layers controls the number of surfaces generated (start with low values, high values will very quickly cause a reduction in performance). Offset controls the distance between layers. Fade controls how much each additional layer fades in addition to its previous layer. The fur shader shouldn't be applied to surface geometry as it is implicitly generated above the base shader.
+q3map_fur generates additional surfaces above the base shader. The q3map_fur directive takes a few values: layers, offset and fade. Layers controls the number of surfaces generated (start with low values, high values will very quickly cause a reduction in performance). Offset controls the distance between layers. Fade controls how much each additional layer fades in addition to its previous layer. The fur shader shouldn't be applied to surface geometry as it is implicitly generated above the base shader.
// fur texture diff --git a/docs/shaderManual/general-directives.html b/docs/shaderManual/general-directives.html index 140203de..18bf672e 100644 --- a/docs/shaderManual/general-directives.html +++ b/docs/shaderManual/general-directives.html @@ -53,7 +53,7 @@General Directives
-General shader directives are global and affect all stages. They are read by the game engine only and are ignored by Q3Map2.
+General shader directives are global and affect all stages. They are all read by the game engine and also are partially used by Q3Map2.
skyParms farbox cloudheight nearbox
Specifies how to use the surface as a sky, including an optional far box (stars, moon, etc), optional cloud layers with any shader attributes, and an optional near box (mountains in front of the clouds, etc).
@@ -66,10 +66,10 @@skyParms farbox cloudheight nearbox
Design Notes:
If you are making a map where the sky is seen by looking up most of the time, use a lower cloudheight value. Under those circumstances the tighter curve looks more dynamic. If you are making a map where the sky is seen by looking out windows most of the time or has a map area that is open to the sky on one or more sides, use a higher height to make the clouds seem more natural.
It is possible to create a sky with up to 8 cloudlayers (I don't think this is a physical limit, more of a practical one - see below), but that also means 8 processing passes and a potentially large processing hit.
-Be aware that the skybox does not wrap around the entire world. The "floor" or bottom face of the skybox is not drawn by the game. If a player in the game can see that face, they will see the "hall of mirrors" effect.
+Be aware that cloud layers are mapped onto hemisphere, hence they do not wrap around the entire world. If a player in the game can see the bottom, they will see the "hall of mirrors" effect (if skybox was not specified).
There's a bug in Quake 3 (but fixed in Enemy Territory) that causes a shader vertex overflow (SHADER_MAX_VERTEXES HIT IN FILLCLOUD SKY SIDE) if too many cloud layers are used in maps with a lot of visible sky. To compensate, either reduce the amount of visible sky or limit the shader to two cloud layers. Q3Map2 sky portals may be a good alternative if you feel a standard sky isn't interesting enough.
-Q3Map2 sky shaders work differently from the original and contain a number of improvements in terms of efficiency and visually. The example given below is an original Quake III Arena sky shader. While it is still operational, it is a little outdated and is being kept here for legacy purposes only. It is recommended that you take advantage of the new features of Q3Map2 skies by consulting Appendix: Light Emitting Shaders. Below is an example of a default (pre-Q3Map2) Quake 3 sky shader.
+Q3Map2 sky shaders work differently from the original and contain a number of improvements in terms of efficiency and visually. The example given below is an original Quake III Arena sky shader. While it is still operational, it is a little outdated and is being kept here for legacy purposes only. It is recommended that you take advantage of the new features of Q3Map2 skies by consulting Appendix: Light Emitting Shaders. Below is an example of a default (pre-Q3Map2) Quake 3 sky shader.
textures/skies/xtoxicsky_dm9 { @@ -109,14 +109,14 @@Design Notes:
deformVertexes type
-This function performs a general deformation on the surface's vertexes, changing the actual shape of the surface before drawing the shader passes. You can stack multiple deformVertexes commands to modify positions in more complex ways, making an object move in two dimensions, for instance. There are 6 possible values for the type parameter, each of which will be described in more detail: wave, normal, bulge, move, autosprite, autosprite2. Depending on which of the 6 type parameters are used, different additional parameters will need to be used, including the generalized waveform functions (see Introduction: Key Concepts).
+This function performs a general deformation on the surface's vertexes, changing visual shape of the surface before drawing the shader passes. You can stack multiple deformVertexes commands to modify positions in more complex ways, making an object move in two dimensions, for instance. There are 6 possible values for the type parameter, each of which will be described in more detail: wave, normal, bulge, move, autosprite, autosprite2. Depending on which of the 6 type parameters are used, different additional parameters will need to be used, including the generalized waveform functions.
Design Notes:
The div and amplitude parameters, when used in conjunction with liquid volumes like water should take into consideration how much the water will be moving. A large ocean area would have have massive swells (big div values) that rose and fell dramatically (big amplitude values). While a small, quiet pool may move very little.
deformVertexes wave div func base amplitude phase freq
-Designed for water surfaces, modifying the values differently at each point. The div parameter is used to control the wave "spread" - a value equal to the q3map_tessSize of the surface is a good default value. It accepts the standard wave functions sin, triangle, square, sawtooth or inversesawtooth.
+Designed for water surfaces, modifying the values differently at each point. The div parameter is used to control the wave "spread" - a value equal to the q3map_tessSize of the surface is a good default value. It accepts the standard wave functions sin, triangle, square, sawtooth or inversesawtooth.
deformVertexes normal amplitude freq
This deformation affects the normals of a vertex without actually moving it, which will effect later shader options like lighting and especially environment mapping. If the shader stages don't use normals in any of their calculations, there will be no visible effect. Good values for amplitude ranges from 0.1 to 0.5 while values of 1.0 to 4.0 are good for frequency.
@@ -129,7 +129,7 @@deformVertexes bulge div ampl freq
This forces a bulge to move along S texture direction. Designed for use on curved pipes. Div sets how frequently bulges are placed, the bigger value means more bulges. Amplitude parameter is the amount of bulge displacement measured in game units.
deformVertexes move x y z func base amplitude phase freq
-The move parameter is used to make a brush, curve patch or model appear to move together as a unit. The x y z values are the distance and direction in game units the object appears to move relative to it's point of origin in the map. The func base amplitude phase freq values are the same as found in other waveform manipulations.
+The move parameter is used to make a brush, curve patch or model appear to move together as a unit. The x y z values are the distance and direction in game units the object appears to move relative to it's point of origin in the map. The func base amplitude phase freq values are the same as found in other waveform manipulations.
The product of the function modifies the values x, y, and z. Therefore, if you have an amplitude of 5 and an x value of 2, the object will travel 10 units from its point of origin along the x axis. This results in a total of 20 units of motion along the x axis, since the amplitude is the variation both above and below the base.
It must be noted that an object made with this shader does not actually change position, it only appears to.
@@ -137,14 +137,14 @@-Design Notes:
If an object is made up of surfaces with different shaders, all must have matching deformVertexes move values or the object will appear to tear itself apart.
deformVertexes autosprite
+deformVertexes autosprite
This function can be used to make any given triangle quad (pair of triangles that form a square rectangle) automatically behave like a sprite without having to make it a separate entity. This means that the "sprite" on which the texture is placed will rotate to always appear at right angles to the player's view as a sprite would. Any four-sided brush side, flat patch, or pair of triangles in a model can have the autosprite effect on it. The brush face containing a texture with this shader keyword must be square.
-deformVertexes autosprite2
+deformVertexes autosprite2
Is a slightly modified "sprite" that only rotates around the middle of its longest axis. This allows you to make a pillar of fire that you can walk around, or an energy beam stretched across the room.
fogParms ( r g b ) opacity
-Fogparms describes how to render the fog on the surfaces. You must also specify "surfaceparm fog" to cause Q3Map2 to identify the surfaces inside the volume.
+Fogparms describes how to render the fog on the surfaces. You must also specify "surfaceparm fog" to cause Q3Map2 to identify the surfaces inside the volume.
This implies noPicMip, but also prevents the generation of any lower resolution mipmaps for use by the 3D card. This will cause the texture to alias when it gets smaller, but there are some cases where you would rather have this than a blurry image. Sometimes thin slivers of triangles force things to very low mipmap levels, which leave a few constant pixels on otherwise scrolling special effects.
Surfaces rendered with the polygonOffset keyword are rendered slightly off the polygon's surface. This is typically used for wall markings and "decals." The distance between the offset and the polygon is fixed. It is not a variable in Quake III Arena.
+Surfaces rendered with the polygonOffset keyword are rendered slightly off the polygon's surface. This is typically used for wall markings and "decals". The distance between the offset and the polygon is fixed. It is not a variable in Quake III Arena.
Design Notes:
Use this for wall or floor markings, particularly for direction arrows for team games. Texture the brush with the decal shader on one face and the other faces with a nodraw shader. Then place the brush flush with the surface of the wall or floor.
-When using a _decal entity for texture projection, polygonOffset must be used to prevent Z-fighting. If you experience problems with depth sorting, try using sort 6.
+When using a _decal entity for texture projection, polygonOffset must be used to prevent Z-fighting. If you experience problems with depth sorting, try using sort 6.
Specifies that this shader is the surface for a portal or mirror. In the game map, a portal entity (e.g. "misc_portal_surface") must be placed directly in front of the surface (within 64 game units). All this does is set "sort portal", so it isn't needed if you specify that explicitly.
+Specifies that this shader is the surface for a portal or mirror. In the game map, a portal entity (e.g. "misc_portal_surface") must be placed directly in front of the surface (within 64 game units). All this does is set "sort portal", so it isn't needed if you specify that explicitly.
Bare bones mirror shader example:
textures/ztest/mirror @@ -197,15 +197,15 @@sort value
The default behavior is to put all blended shaders in sort 9 and all other shaders in sort "opaque", so you only need to specify this when you are trying to work around a sorting problem with multiple transparent surfaces in a scene.
The value here can be either a numerical value or one of the keywords in the following list (listed in order of ascending priority):
Originally, sky shaders were just very large surface lights that casted parallel directional lighting. With Q3Map2, there are a few differences that sets sky shaders apart from surface lights. First of all, we'll take a look at how the pre-Q3Map2 shaders were set up:
+Originally, sky shaders were just very large surface lights that casted parallel directional lighting. With Q3Map2, there are a few differences that sets sky shaders apart from surface lights. First of all, we'll take a look at how the pre-Q3Map2 shaders were set up:
textures/shadermanual/sky @@ -140,11 +140,11 @@-Skies
}
What we've done here is replace q3map_lightSubdivide and q3map_surfacelight with q3map_skylight which yields more uniform shadows at a fraction of the compile time. However, this also generates the "stadium light" effect - producing some unwanted shadows. We'll fix this later.
+What we've done here is replace q3map_lightSubdivide and q3map_surfaceLight with q3map_skylight which yields more uniform shadows at a fraction of the compile time. However, this also generates the "stadium light" effect - producing some unwanted shadows. We'll fix this later.
-To solve the problem with jagged shadow edges, we can smooth out the shadows by blurring the lightmap. Depending on the type of lighting that you want to achieve for the sun (a cloudy day, for example), you can create a penumbra (half-shadow) effect using q3map_sunExt. This simulates the way sunlight bounces in certain conditions, creating a slight "jittering" effect. This is the same shader again with q3map_sunExt.
+To solve the problem with jagged shadow edges, we can smooth out the shadows by blurring the lightmap. Depending on the type of lighting that you want to achieve for the sun (a cloudy day, for example), you can create a penumbra (half-shadow) effect using q3map_sunExt. This simulates the way sunlight bounces in certain conditions, creating a slight "jittering" effect. This is the same shader again with q3map_sunExt.
textures/shadermanual/sky @@ -185,7 +185,7 @@Skies
-As mentioned above, you may be faced with problems involving the "stadium lights" effect when using q3map_skyLight. We can eliminate this problem by using higher values for the q3map_sunExt samples and q3map_skyLight iterations parameter, but at the cost of a higher compile time. For example, q3map_sunExt 1 1 1 140 -35 25 3 32 and q3map_skylight 100 6.
+As mentioned above, you may be faced with problems involving the "stadium lights" effect when using q3map_skylight. We can eliminate this problem by using higher values for the q3map_sunExt samples and q3map_skylight iterations parameter, but at the cost of a higher compile time. For example, q3map_sunExt 1 1 1 140 -35 25 3 32 and q3map_skylight 100 6.
Note:
@@ -194,7 +194,7 @@Note:
-A faster approximate alternative of getting rid of the "stadium lights" effect is to use q3map_lightmapFilterRadius.
+A faster approximate alternative of getting rid of the "stadium lights" effect is to use q3map_lightmapFilterRadius.
textures/shadermanual/sky @@ -232,7 +232,7 @@-Note:
}The self and other parameters are the amount of filtering applied on the lightmap in world units. The self value is always set to "0" on sky shaders since skies don't have lightmaps. The q3map_lightmapFilterRadius directive should always be placed before any light-related directives that you want it to affect. In our case, we placed it after q3map_sunExt and before q3map_skyLight so that it filters the stadium lights, but won't blur the sun shadows which are already jittered. This produces very similar results without the long compile times.
+The self and other parameters are the amount of filtering applied on the lightmap in world units. The self value is always set to "0" on sky shaders since skies don't have lightmaps. The q3map_lightmapFilterRadius directive should always be placed before any light-related directives that you want it to affect. In our case, we placed it after q3map_sunExt and before q3map_skylight so that it filters the stadium lights, but won't blur the sun shadows which are already jittered. This produces very similar results without the long compile times.
diff --git a/docs/shaderManual/lightstyles.html b/docs/shaderManual/lightstyles.html index db076e50..5631fc66 100644 --- a/docs/shaderManual/lightstyles.html +++ b/docs/shaderManual/lightstyles.html @@ -57,7 +57,7 @@Lightstyles
Worldspawn Keys
-To create some flickering lights, we need some waveform functions. These are set on the worldspawn entity in Radiant's Entity Inspector using two new available key/value pairs: _styleNrgbGen and _styleNalphaGen keys, where "N" is the style index number, an integer between 1 and 31. Both keys will take standard waveform functions as values. As an example:
+To create some flickering lights, we need some waveform functions. These are set on the worldspawn entity in Radiant's Entity Inspector using two new available key/value pairs: _styleNrgbGen and _styleNalphaGen keys, where "N" is the style index number, an integer between 1 and 31. Both keys will take standard waveform functions as values. As an example:
_style1alphaGen wave sin .5 .3 .25 1.5 _style1rgbGen wave noise 0.5 1 0 5.37 @@ -73,7 +73,7 @@Light Entities
With a light entity selected, open up the Entity Inspector and add a "style" key. Use a value between 1 and 31 matching the style index number previously set in the worldspawn.
Light Emitting Shaders
-You can also use q3map_lightStyle N, where "N" is a value between 1 and 31 matching the style index number set in the worldspawn, on light-emitting shaders to have them emit styled light.
+You can also use q3map_lightStyle N, where "N" is a value between 1 and 31 matching the style index number set in the worldspawn, on light-emitting shaders to have them emit styled light.
textures/slstyle/light { @@ -97,7 +97,7 @@Light Emitting Shaders
Lightmapped Surfaces
-For any shaders that may be hit by a styled light, you'll need to add q3map_styleMarker after the lightmap stages and before the texture stages so Q3Map2 can properly create the fake lightmap stages. For masked textures where a depthFunc equal is required, add q3map_styleMarker2.
+For any shaders that may be hit by a styled light, you'll need to add q3map_styleMarker after the lightmap stages and before the texture stages so Q3Map2 can properly create the fake lightmap stages. For masked textures where a depthFunc equal is required, add q3map_styleMarker2.
Shaders with lightmaps after texture passes will look odd. This may change in the future. Try to rearrange your shaders, if possible, to have lightmaps first.
textures/slstyle/plywood2sided diff --git a/docs/shaderManual/preface.html b/docs/shaderManual/preface.html index 50d457d9..4a8b38e4 100644 --- a/docs/shaderManual/preface.html +++ b/docs/shaderManual/preface.html @@ -69,6 +69,7 @@Q3Map2 Edition
- Additional material
- ydnar
- TTimo
+- Garux
Tells compiler to generate flare surface with default game flare shader. Value is not used, but must be present.
Currently takes a single function, const. This directive is used to set a surfaces vertex alpha values. q3map_alphaGen operations are applied to an object's vertexes so the alphaGen vertex directive is required for each affected stage.
+Currently takes a single function, const. This directive is used to set a surfaces vertex alpha values. q3map_alphaGen operations are applied to an object's vertexes so the alphaGen vertex directive is required for each affected stage.
-Forces a fixed vertex alpha value to the entire shader surface, useful for controlling transparency or blending. Values are a normalized number.
+Forces a fixed vertex alpha value to the entire shader surface, useful for controlling transparency or blending. Value is a normalized number.
This is used for special vertex alpha blending effects on surfaces by altering the vertex alpha values depending on specific surface properties, such as the surfaces normal axis or the vertexes contained within its volume. q3map_alphaMod operations are applied to an object's vertexes so the alphaGen vertex directive is required for each affected stage.
+This is used for special vertex alpha blending effects on surfaces by altering the vertex alpha values depending on specific surface properties, such as the surfaces normal axis or the vertexes contained within its volume. q3map_alphaMod operations are applied to an object's vertexes so the alphaGen vertex directive is required for each affected stage.
Used to blend textures using alphaFunc or blendFunc in the shader's second pass, with the transparency depending on the surface's normal axis vector. This is achieved by taking the user specified vector ( X Y Z ) and applying a dotproduct calculation with the generated vertex normal vector to yield a normalized vertex alpha value. The dot product operation multiplies each element of one vector against the corresponding elements of a second vector, then adds them:
+Used to blend textures using alphaFunc or blendFunc in the shader's second pass, with the transparency depending on the surface's normal axis vector. This is achieved by taking the user specified vector ( X Y Z ) and applying a dotproduct calculation with the generated vertex normal vector to yield a normalized vertex alpha value. The dot product operation multiplies each element of one vector against the corresponding elements of a second vector, then adds them:
( 0 0 1 ) dp ( 0 0 1 ) = 0 * 0 + 0 * 0 + 1 * 1 = 1 -( 0 0 1 ) dp ( 0 0 0.5 ) = 0 * 0 + 0 * 0 + 1 * 0.5 = 0.5 -( 0.5 0.5 1 ) dp ( 0 0.5 0.5 ) = 0.5 * 0 + 0.5 * 0.5 + 1 * 0.5 = 0.75 +( 0 0 1 ) dp ( 0 0.7 0.7 ) = 0 * 0 + 0 * 0.7 + 1 * 0.7 = 0.7 +( 0.5 -0.5 0.7 ) dp ( 0 0.7 0.7 ) = 0.5 * 0 - 0.5 * 0.7 + 0.7 * 0.7 = 0.14-
In a practical sense, you can think of the dotproduct vector ( 0 0 0.9 ) as meaning that all vertex normal vectors pointing straight up along the z-axis ( 0 0 1 ) will have a vertex alpha value of 90% opacity.
+In a practical sense, you can think of the dotproduct vector ( 0 0 0.9 ) as meaning that all vertices with normal vector pointing straight up along the z-axis ( 0 0 1 ) will have a vertex alpha value of 90% opacity, entirely horizontal ( X Y 0 ) will get 0%, and everything in between will be mapped linearly.
This works in a similar way to dotproduct except it exaggerates the differences in vertex normals by squaring the final dot product value. With the same values as the above example, dotproduct2 would give the following:
[ ( 0 0 1 ) dp ( 0 0 1 ) ]2 = ( 0 * 0 + 0 * 0 + 1 * 1 )2 = 1 -[ ( 0 0 1 ) dp ( 0 0 0.5 ) ]2 = ( 0 * 0 + 0 * 0 + 1 * 0.5 )2 = 0.25 -[ ( 0.5 0.5 1 ) dp ( 0 0.5 0.5 ) ]2 = ( 0.5 * 0 + 0.5 * 0.5 + 1 * 0.5 )2 = 0.5625 +[ ( 0 0 1 ) dp ( 0 0.7 0.7 ) ]2 = ( 0 * 0 + 0 * 0.7 + 1 * 0.7 )2 = 0.49 +[ ( 0.5 -0.5 0.7 ) dp ( 0 0.7 0.7 ) ]2 = ( 0.5 * 0 - 0.5 * 0.7 + 0.7 * 0.7 )2 = 0.0196
Example q3map_dotproduct2 shader for terrain:
@@ -122,7 +122,7 @@q3map_alphaMod dotproduct2 ( X Y Z )
Works similar to q3map_alphaMod dotproduct, but in addition values MIN and MAX denote a range of cosine values, in which blending will occur. So less than MIN is mapped to alpha value 0, above MAX is mapped to alpha value 1, and everything in between is mapped linearily.
+Works similar to q3map_alphaMod dotproduct, but in addition values MIN and MAX denote a range of cosine values, in which blending will occur. So less than MIN is mapped to alpha value 0, above MAX is mapped to alpha value 1, and everything in between is mapped linearly.
If you prefer working with angles, you can set MIN to the cosine of the most steep angle of the blending, and MAX to the cosine of the most flat angle of the blending. Example:
q3map_alphagen dotProductScale ( 0 0 1 0.500 0.966 ) @@ -140,13 +140,13 @@Design Notes:
Typical examples of use include snow covering the top faces of objects, or terrain with grass growing on horizontal planes blending into rocky cliffs on near vertical surfaces. It is an excellent way of automatically creating realistic alpha-blended terrain without the complicated steps of setting up an alpha map.
-q3map_alphaMod scale norm
-Used in conjunction with q3map_alphaMod volume. Scales the vertex alpha by the specified normalized number value.
+q3map_alphaMod scale N.N
+Used in conjunction with q3map_alphaMod volume. Scales the vertex alpha by the specified normalized number value.
-q3map_alphaMod set norm
-Used in conjunction with q3map_alphaMod volume. Sets the vertex alpha (regardless of any previous alpha values) to the specified normalized number value.
+q3map_alphaMod set N.N
+Used in conjunction with q3map_alphaMod volume. Sets the vertex alpha (regardless of any previous alpha values) to the specified normalized number value.
-q3map_alphaMod volume
+q3map_alphaMod volume
This was created as a way to explicitly set or modify the vertex alpha values of vertex points contained within a controlling brush volume marked with this shader directive. Applies all other q3map_alphaMod directives to each vertex inside a brush textured with this shader, allowing large faded scrolling fire shaders, waterfalls, marquees, explicit dotProduct terrain blending control, etc.
@@ -155,43 +155,43 @@Design Notes:
q3map_backShader shadername
-This allows a brush to use a different shader when you are inside it looking out. By way of example, this would allow a water brush (or other) surfaces to have a different sort order or appearance when seen from the inside. q3map_backShader only works on brush faces. For this reason, it is often deprecated in favor of using q3map_cloneShader where the target shader contains q3map_invert. It can still be useful as a kind of shorthand.
+This allows a brush to use a different shader when you are inside it looking out. By way of example, this would allow a water brush (or other) surfaces to have a different sort order or appearance when seen from the inside. This is essentially shorthand of q3map_cloneShader where the target shader contains q3map_invert.
q3map_backSplash percentage distance
-A surface light is lit by itself, often causing areas of higher light intensity than other areas. q3map_backSplash moves the light source away from the surface of the shader, allowing it to create smoother lighting over the face. By default, all shaders are assigned backsplash values, 5 for percentage, 23 units for distance.
+By default surface light generates extra 'backsplash' light to light itself and surrounding. That light source is moved away from the surface of the shader, allowing it to create smoother lighting over the face. By default, all shaders are assigned backsplash values, 5 for percentage, 23 units for distance.
Allows shaders to be subclassed (Q3Map2 relevant portions only, such as surfaceparms, lighting, texture projection, etc). Subclassed shaders can reference the base shader by referring to the base shader's name. In order for q3map_baseShader to work correctly, the base shader must be specified before any shaders that subclass it. Some EasyGen terrain templates incorrectly specified the base shader after the terrain shaders that depended on it, resulting in some interesting errors.
-This is fundamentally the reverse of q3map_remapShader. Use q3map_baseShader when a single group of q3map_* directives is required for multiple base shaders. Use q3map_remapShader when similar shaders are used that require different groups of q3map_* directives.
+This is fundamentally the reverse of q3map_remapShader. Use q3map_baseShader when a single group of q3map_* directives is required for multiple base shaders. Use q3map_remapShader when similar shaders are used that require different groups of q3map_* directives.
Deprecated! Use q3map_bounceScale instead.
Takes positive decimal number values between 0 and 1.0 (or higher), to scale the amount of light reflected in radiosity passes. You can oversaturate it by using a number higher than 1.0, but this can lead to excessive compile times. Using 90 would probably make things positively glacial. 1.0 is a default, fudged number that looked OK with the maps that were tested. Tweaking it to 1.5 or 2.0 won't hurt anything per se, but it does give you finer control over how each shader re-emits light. The poorly worded q3map_bounce has been renamed to q3map_bounceScale. While its use has been deprecated, q3map_bounce still works.
+Takes positive decimal number values to scale the amount of light reflected in radiosity passes. You can oversaturate it by using a number higher than 1.0, but this can lead to excessive compile times. Using 0.9 would probably make things positively glacial. 1.0 is a default, fudged number that looked OK with the maps that were tested. Tweaking it to 1.5 or 2.0 won't hurt anything per se, but it does give you finer control over how each shader re-emits light. The poorly worded q3map_bounce has been renamed to q3map_bounceScale. While its use has been deprecated, q3map_bounce still works.
Automatically clips misc_model entities for player and weapon collision. This should only be used on large models such as terrain (not small decorative models - manually clip those). The shader's surfaceparms are inherited by the magic clip brush, so if you have surfaceparm nonsolid in your model's shader that uses q3map_clipModel, then the brush will also be non-solid. This can also be set on a per model basis with the entity key/value pair, spawnflags 2.
+Automatically clips misc_model entities for player and weapon collision. This should only be used on large models such as terrain (not small decorative models - manually clip those). The shader's surfaceparms are inherited by the magic clip brush, so if you have surfaceparm nonsolid in your model's shader that uses q3map_clipModel, then the brush will also be non-solid. This can also be set on a per model basis with the entity key/value pair, spawnflags 2.
Clones surface and applies target shader's properties and appearance to clone. Be careful, this can lead to an infinite loop if a cloning shader references another cloning shader or itself.
Currently takes a single function, const. This directive is used to set a surfaces vertex color values. q3map_colorGen operations are applied to an object's vertexes so the rgbGen vertex directive is required for each affected stage. It's also needed to use q3map_noVertexLight or -novertex to avoid overwriting RGB vertex values by -light build stage. Same as q3map_rgbGen.
+Currently takes a single function, const. This directive is used to set a surfaces vertex color values. q3map_colorGen operations are applied to an object's vertexes so the rgbGen vertex directive is required for each affected stage. It's also needed to use q3map_noVertexLight or -novertex to avoid overwriting RGB vertex values during -light build stage. Same as q3map_rgbGen.
Forces a fixed vertex color value to the entire shader surface.
Used to alter the vertex color values of vertexes contained within its volume. q3map_colorMod operations are applied to an object's vertexes so the rgbGen vertex directive is required for each affected stage. It's also needed to use q3map_noVertexLight or -novertex to avoid overwriting RGB vertex values by -light build stage. Possible uses include creating a neutral hued texture for a CTF middleground and then creating shader instances of the texture for red and blue bases. Same as q3map_rgbMod.
+Used to alter the vertex color values of vertexes contained within its volume. q3map_colorMod operations are applied to an object's vertexes so the rgbGen vertex directive is required for each affected stage. It's also needed to use q3map_noVertexLight or -novertex to avoid overwriting RGB vertex values during -light build stage. Possible uses include creating a neutral hued texture for a CTF middleground and then creating shader instances of the texture for red and blue bases. Same as q3map_rgbMod.
Used in conjunction with q3map_colorMod volume. Scales the vertex color by the specified color values.
@@ -210,12 +210,12 @@These ones work just like q3map_alphaMod dotproduct, but are modifying vertex color values. +
These ones work just like q3map_alphaMod dotproduct*, but are modifying vertex color values.
Rename current shader to newShaderName, so it will be shown in a map as newShaderName. Similar to q3map_remapShader, but, unlike it, performs renaming in early loading stage, so compile parameters of newShaderName are used.
+Rename current shader to newShaderName, so it will be shown in a map as newShaderName. Similar to q3map_remapShader, but, unlike it, performs renaming in early loading stage, so compile parameters of newShaderName are used.
Tells compiler to generate flare surface with specified shader.
@@ -249,28 +249,28 @@Forces model (MD3, ASE, etc.) surfaces to be broken down into their component triangles like brush faces and passed through the meta code on a per shader basis. This is required for lightmapped models. Setting spawnflags 4 on a misc_model will set q3map_forceMeta on all its surfaces.
Obsolete! By default, no sunlight is cast on vertex-lit .md3 models or vertex-lit terrain. Using this option, sunlight (overbright bits created by the q3map_sun option) will be cast on these surfaces. q3map_forceSunlight is now obsolete since suns are now first class light sources.
+Obsolete! By default, no sunlight is cast on vertex-lit .md3 models or vertex-lit terrain. Using this option, sunlight (overbright bits created by the q3map_sun option) will be cast on these surfaces. q3map_forceSunlight is now obsolete since suns are now first class light sources.
This is used for generating fur over a surface. This is typically used in conjunction with q3map_cloneShader in the surface (parent) shader and references the fur shader as the clone. A possible application of this is to create grass on alphablended terrain. Keep in mind that the use of a fur shader may cause a large hit to performance but when used sparingly, it can produce some interesting effects. (See Appendix: Fur)
+This is used for generating fur over a surface. This is typically used in conjunction with q3map_cloneShader in the surface (parent) shader and references the fur shader as the clone. A possible application of this is to create grass on alphablended terrain. Keep in mind that the use of a fur shader may cause a large hit to performance but when used sparingly, it can produce some interesting effects. (See Appendix: Fur)
Use this shader in the global directive commands whenever the tcMod scale function is used in one of the later render stages. Many problems with getting shader effects to work across multiple adjacent brushes are a result of the way Q3Map2 optimizes texture precision. This option resolves that, but at the expense of some precision of the textures when they are far away from the origin of the map.
+Use this shader in the global directive commands whenever the tcMod scale function is used in one of the later render stages. Many problems with getting shader effects to work across multiple adjacent brushes are a result of the way Q3Map2 optimizes texture precision. This option resolves that, but at the expense of some precision of the textures when they are far away from the origin of the map.
This is used for explicit terrain-style indexed mapping. It instructs Q3Map2 to look at the func_group terrain entity's _indexmap key for an image to pull index values from, and then to construct a shader name with the root based on the _shader key's value.
Inverts a surface normal. Works on brush faces, models and patches. Used in celshading to achieve the inverted backfacing hull. Can be used with a shader that is targeted by q3map_cloneshader for something similar to q3map_backShader.
+Inverts a surface normal. Works on brush faces, models and patches. Used in celshading to achieve the inverted backfacing hull. Can be used with a shader that is targeted by q3map_cloneShader for something similar to q3map_backShader.
By default, surface lights use the average color of the source image to generate the color of the light. q3map_lightImage specifies an alternate image to be used for light color emission, radiosity color emission, light filtering and alpha shadows. You can even use a light image with a different alpha channel for blurrier alpha shadows. The light color is averaged from the referenced texture. The texture must be the same size as the base image map. q3map_lightImage should appear before qer_editorImage.
+By default, surface lights use the average color of the source image to generate the color of the light. q3map_lightImage specifies an alternate image to be used for light color emission, radiosity color emission, light filtering and alpha shadows. You can even use a light image with a different alpha channel for blurrier alpha shadows. The light color is averaged from the referenced texture. The texture must be the same size as the base image map. q3map_lightImage should appear before qer_editorImage.
The reason q3map_lightImage is specified for the light in the example below, is because the blend map is predominantly yellow, but the base image is not. The designer wanted the color of the light to be sampled from the blend map instead of the base image.
textures/eerie/ironcrosslt2_10000 @@ -304,7 +304,7 @@q3map_lightImage texturename
Takes a single argument: either x, y or z as the direction from which the lightmap is projected from. The directive q3map_terrain has an implicit (read default) q3map_lightmapAxis defined as z. This directive is not recommended for things like caves or arches which have undersides.
+Takes a single argument: either X, Y or Z as the direction from which the lightmap is projected from. The directive q3map_terrain has an implicit (read default) q3map_lightmapAxis defined as Z. This directive is not recommended for things like caves or arches which have undersides.
Lightmap brightness scaling. A value of 2.0 will be twice as bright (linearly) and a value of 0.5 will be half as bright.
@@ -313,43 +313,43 @@This is usually used on light emitting shaders to approximate finer subdivided lighting. It adds a gaussian blur effect to the lightmaps of either the shader itself, or the surfaces affected by the shader, or both. The values for self and other are measured in world units of filtering (blurring) of lightmap data cast by any light sources.
If using a value higher than 4 for the iterations parameter on q3map_skylight, you don't need q3map_lightmapFilterRadius as much, but at the expense of higher compile times. q3map_lightmapFilterRadius should be placed before any light related shader directives that you want it to affect. (see Appendix: Light Emitting Shaders)
+If using a value higher than 4 for the iterations parameter on q3map_skylight, you don't need q3map_lightmapFilterRadius as much, but at the expense of higher compile times. q3map_lightmapFilterRadius should be placed before any light related shader directives that you want it to affect. (see Appendix: Light Emitting Shaders)
Deprecated! Use q3map_lightmapBrightness instead.
+Deprecated! Use q3map_lightmapBrightness instead.
Allows surfaces like terrain to be mapped onto a single lightmap page for seamless terrain shadows. It will specify that the shaders using it can merge nonplanars together onto a single lightmap, so you can have a single 512x512 lightmap across a terrain entity. Note that most id Tech 3 engine games are limited to lightmap pages of 128x128. You may need to experiment with q3map_lightmapSize and the Q3Map2 -export general switch.
+Allows surfaces like terrain to be mapped onto a single lightmap page for seamless terrain shadows. It will specify that the shaders using it can merge nonplanars together onto a single lightmap, so you can have a single 512x512 lightmap across a terrain entity. Note that most id Tech 3 engine games are limited to lightmap pages of 128x128. You may need to experiment with q3map_lightmapSize and the Q3Map2 -export general switch.
Takes a single parameter, defaulting to 1.0, which specifies how many units off a surface should Q3Map2 sample lighting from. Use larger values (2.0-8.0) if you're getting ugly splotches on lightmapped terrain. Try to use filtering to solve splotches if possible, leaving q3MaplightmapSampleOffset as a last resort.
+Takes a single parameter, defaulting to 1.0, which specifies how many units off a surface should Q3Map2 sample lighting from. Use larger values (2.0-8.0) if you're getting ugly splotches on lightmapped terrain. Try to use filtering to solve splotches if possible, leaving q3map_lightmapSampleOffset as a last resort.
Surfaces using a shader with this option will have the pixel size of the lightmaps set to N world grid units. This option can be used to produce high-resolution shadows on certain surfaces. In addition, it can be used to reduce the size of lightmap data, where high-resolution shadows are not required, gaining memory and performance benefits. The default Quake III lightmap sample size is 16, smaller numbers increases lightmap resolution. In general, you should stick with power of 2 values.
+Surfaces using a shader with this option will have the pixel size of the lightmaps set to N world grid units. This option can be used to produce high-resolution shadows on certain surfaces. In addition, it can be used to reduce the size of lightmap data, where high-resolution shadows are not required, gaining memory and performance benefits. The default Quake III lightmap sample size is 16, so square of 16x16 units will be 'lit' by single lightmap pixel. Smaller numbers increases lighting resolution. In general, you should stick with power of 2 values.
Specifies the size of the lightmap page that surface lightmaps get packed on to. Used mainly in Enemy Territory for terrain lightmaps (512x512) in concert with the Q3Map2 switch -lightmapsize. Most idTech 3 games will only support internal lightmap pages of 128x128. Larger pages will result in lightmaps exported externally from the .bsp file.
This forces a specified color of light to be emitted from a surface or sky light, rather than sampling colors from a lightimage, editor image or the texture map. Three normalized color values of light are required for the red green blue parameters. This does not affect bounced light in radiosity or lightfilter.
+This forces a specified color of light to be emitted from a surface or sky light, rather than sampling colors from a lightimage, editor image or the texture map. Three normalized color values of light are required for the red green blue parameters. This does not affect bounced light in radiosity or lightfilter.
Used to set light styles on surface lights for lightmap flickering/waveform effects. N takes the form of a number between 1 and 31, that references the corresponding style number set in the worldspawn entity. Equivalent to setting "style" "N" on a light entity (see Appendix: Lightstyles).
+Used to set light styles on surface lights for lightmap flickering/waveform effects. N takes the form of a number between 1 and 31, that references the corresponding style number set in the worldspawn entity. Equivalent to setting "style" "N" on a light entity (see Appendix: Lightstyles).
Used on surface lights (see q3map_surfacelight). Controls maximum size, above which surface light source is split for uniform lighting. It defaults to 999 game units, but can be made larger or smaller as needed (for light surfaces at the bottom of cracks, for example). This can be a dominant factor in processing time for Q3Map2 lighting. Can have an increasingly "darker" effect when used with -fast. Compensate by raising the surface light value. For sky shaders, use q3map_skylight instead (see Appendix: Light Emitting Shaders).
+Used on surface lights (see q3map_surfaceLight). Controls maximum size, above which surface light source is split for uniform lighting. It defaults to 999 game units, but can be made larger or smaller as needed (for light surfaces at the bottom of cracks, for example). This can be a dominant factor in processing time for Q3Map2 lighting. Can have an increasingly "darker" effect when used with -fast. Compensate by raising the surface light value. For sky shaders, use q3map_skylight instead (see Appendix: Light Emitting Shaders).
Surface lights are also used for -bounce lighting with default starting subdivision value of 256. q3map_lightSubdivide controls this value too.
You might have noticed that terrain has been made to not clip or t-junction anymore. It was causing too many issues, so a new parameter was added: q3map_noClip. Normally, Q3Map2 clips all faces to the BSP, and then takes the minimum polygon that encompasses all visible fragments. q3map_noClip forces Q3Map2 to uses the original brush faces (This is implicit for autosprite(2) surfaces). Therefore, if you map tidy, you could theoretically use q3map_noClip on all your shaders. q3map_noClip and q3map_noTJunc, when used in combination, will preserve mesh geometry exactly as you make it.
+You might have noticed that terrain has been made to not clip or t-junction anymore. It was causing too many issues, so a new parameter was added: q3map_noClip. Normally, Q3Map2 clips all faces to the BSP, and then takes the minimum polygon that encompasses all visible fragments. q3map_noClip forces Q3Map2 to uses the original brush faces (This is implicit for autosprite(2) surfaces). Therefore, if you map tidy, you could theoretically use q3map_noClip on all your shaders. q3map_noClip and q3map_noTJunc, when used in combination, will preserve mesh geometry exactly as you make it.
Don't apply -dirty on this surface.
When used on surfaces that emit light, this will disable -fast optimizations. This is useful for large areas of dim sky, where you want the dim light to reach all surfaces. This shader directive prevents fast from affecting dim sky surfaces. It is necessary, if you can't do a workaround with brighter skies or by using a larger q3map_lightSubdivide value.
+When used on surfaces that emit light, this will disable -fast optimizations. This is useful for large areas of dim sky, where you want the dim light to reach all surfaces. This shader directive prevents -fast from affecting dim sky surfaces. It is necessary, if you can't do a workaround with brighter skies or by using a larger q3map_lightSubdivide value.
Volumes marked with a shader containing this directive will not be affected by fog. For example, it can be used on sky shaders to prevent the fog from affecting it.
@@ -361,62 +361,62 @@Allow the use of a normal (height) map to simulate textured bumpmapping. This isn't real bumpmapping per se, but generates a static lightmap image that reflects the normal map and light source.
Read as "no T-Junc". With this option, surfaces modified by a shader are not used for T-junction fixing. q3map_noClip and q3map_noTJunc, used in combination will preserve mesh geometry exactly as you make it.
+Read as "no T-Junc". With this option, surfaces modified by a shader are not used for T-junction fixing. q3map_noClip and q3map_noTJunc, used in combination will preserve mesh geometry exactly as you make it.
Suppresses Q3Map2 from overwriting the BSP-phase set vertex RGB values.
+Suppresses Q3Map2 from overwriting the BSP-phase set vertex RGB values by -light phase.
Obsolete! Vertex lighting code was rewritten a couple of times, rendering this directive irrelevant. Shaders that are used on misc_models or terrain were to use q3map_noVertexShadows to disable shadows being cast on the vertex lit surfaces. Casting shadows at small, misc_model objects often makes sense. However, having shadows on large, vertex lit terrain surfaces often looks bad. Shadows are not cast on forced_vertex_lit surfaces by default (shaders with pointlight).
+Obsolete! Vertex lighting code was rewritten a couple of times, rendering this directive irrelevant. Shaders that are used on misc_models or terrain were to use q3map_noVertexShadows to disable shadows being cast on the vertex lit surfaces. Casting shadows at small, misc_model objects often makes sense. However, having shadows on large, vertex lit terrain surfaces often looks bad. Shadows are not cast on forced_vertex_lit surfaces by default (shaders with pointlight).
Offsets a surface along the vertex normals by N.N units. Used in celshading for those black edges.
+Offsets a surface along the vertex normals by N.N units. Used in celshading for those black edges.
Obsolete! When this option is used in conjunction with the original lighting algorithm (-light), surfaces with textures modified with this option will show shadows that are cast by curve patches. Curve patches do not cast shadows by default. You would usually force patches to cast shadows by using the -patchshadows Q3Map2 switch.
Allows shaders to be subclassed. Subclassed shaders can reference the remap shader by referencing the remap shader's name. In order for this to work, the remap shader must be specified before any shaders that references it. Subclassed shaders must contain Q3Map2 and editor relevant portions only (q3map_*, surfaceparm and qer_* directives).
-This is fundamentally the reverse of q3map_baseShader. Use q3map_baseShader when a single group of q3map_* directives is required for multiple base shaders. Use q3map_remapShader when similar shaders are used that require different groups of q3map_* directives.
+This is fundamentally the reverse of q3map_baseShader. Use q3map_baseShader when a single group of q3map_* directives is required for multiple base shaders. Use q3map_remapShader when similar shaders are used that require different groups of q3map_* directives.
Design Notes:
-Since the subclassed shaders that are applied to geometry does not contain any texture stages, qer_editorImage is usually required in conjunction with q3map_remapShader.
+Since the subclassed shaders that are applied to geometry does not contain any texture stages, qer_editorImage is usually required in conjunction with q3map_remapShader.
Same as q3map_colorGen
+Same as q3map_colorGen
Same as q3map_colorMod
+Same as q3map_colorMod
Specifies the breaking angle for phong shading. This allows for smooth shadows between brush faces like patches. The angle parameter is the angle between adjacent faces at which smoothing will start to occur. Typical values are usually in the 120-179 range.
+Specifies the breaking angle for phong shading. This allows for smooth shadows between brush faces like on patches. The angle parameter is the angle between adjacent faces at which smoothing will start to occur. Typical values are usually in the 120-179 range.
-This replaces q3map_surfacelight and q3map_lightSubdivide on sky surfaces for much faster and more uniform sky illumination. May be used multiple times in a single shader. See Appendix: Light Emitting Shaders.
+This replaces q3map_surfaceLight and q3map_lightSubdivide on sky surfaces for much faster and more uniform sky illumination. May be used multiple times in a single shader. See Appendix: Light Emitting Shaders.
This is used on lightmapped model shaders if splotched lighting artifacts appear. Any shadows at the ambient/dark level will be flooded from neighbouring luxels. This gets rid of shadow acne, but a surface must be more or less uniformly lit or this looks ugly. Try using q3map_lightmapSampleOffset first before using this as a last resort.
+This is used on lightmapped model shaders if splotched lighting artifacts appear. Any shadows at the ambient/dark level will be flooded from neighbouring luxels. This gets rid of shadow acne, but a surface must be more or less uniformly lit or this looks ugly. Try using q3map_lightmapSampleOffset first before using this as a last resort.
For use on shaders that accompany style lights. For any shaders that may be hit by a styled light, add q3map_styleMarker after the lightmap stage and before the texture stages so Q3Map2 can properly create the fake lightmap stages (see Appendix: Lightstyles).
+For use on shaders that accompany style lights. For any shaders that may be hit by a styled light, add q3map_styleMarker after the lightmap stage and before the texture stages so Q3Map2 can properly create the fake lightmap stages (see Appendix: Lightstyles).
Similar to q3map_styleMarker except it is used on masked textures where a depthFunc equal is required.
+Similar to q3map_styleMarker except it is used on masked textures where a depthFunc equal is required.
This directive in a sky shader will create the illusion of light cast into a map by a single, infinitely distance parallel light source (sun, moon, hellish fire, etc.). This is only processed during the lighting phase of Q3Map2. While still perfectly usable, q3map_sun is now deprecated in favour of q3map_sunExt (see below).
+This directive in a sky shader will create the illusion of light cast into a map by a single, infinitely distance parallel light source (sun, moon, hellish fire, etc.). This is only processed during the lighting phase of Q3Map2. While still perfectly usable, q3map_sun is now deprecated in favour of q3map_sunExt (see below).
Works like q3map_sun with the addition of two new parameters to create "light jittering" for penumbra (half-shadow) effects. This gives you much more realistic shadows from the sun, especially when trying to simulate a cloudy day or a wide sun. The penumbra effect can also be applied to entity lights (point, spot or sun) with the _deviance N (distance in world units for point/spot lights and degrees for suns) and _samples N (number of samples) key/value pairs.
+Works like q3map_sun with the addition of two new parameters to create "light jittering" for penumbra (half-shadow) effects. This gives you much more realistic shadows from the sun, especially when trying to simulate a cloudy day or a wide sun. The penumbra effect can also be applied to entity lights (point, spot or sun) with the _deviance N (distance in world units for point/spot lights and degrees for suns) and _samples N (number of samples) key/value pairs.
Design Notes:
-Sky shaders should probably still have a q3map_surfacelight or preferred q3map_skylight value. The "sun" gives a strong directional light, but doesn't necessarily give the fill light needed to soften and illuminate shadows. Skies with clouds should probably have a weaker q3map_sun value and a higher q3map_surfacelight or q3map_skylight value. Heavy clouds diffuse light and weaken shadows. The opposite is true of a cloudless or nearly cloudless sky. In such cases, the "sun" or "moon" will cast stronger shadows that have a greater degree of contrast. This is also why q3map_sunExt is preferred. It gives the designer greater control over shadow contrast with a penumbra effect.
+Sky shaders should probably still have a q3map_surfaceLight or preferred q3map_skylight value. The "sun" gives a strong directional light, but doesn't necessarily give the fill light needed to soften and illuminate shadows. Skies with clouds should probably have a weaker q3map_sun value and a higher q3map_surfaceLight or q3map_skylight value. Heavy clouds diffuse light and weaken shadows. The opposite is true of a cloudless or nearly cloudless sky. In such cases, the "sun" or "moon" will cast stronger shadows that have a greater degree of contrast. This is also why q3map_sunExt is preferred. It gives the designer greater control over shadow contrast with a penumbra effect.
Design Notes:
Not certain what color formula you want to use for the sun's light? Try this. Create a light entity. Use the Radiant editor's color selection tools to pick a color. The light's _color key's value will be the normalized RGB formula. Copy it from the value line in the editor (CTRL+c) and paste it into your shader.
The texture gives off light equal to the value set for it. The relative surface area of the texture in the world affects the actual amount of light that appears to be radiated. To give off what appears to be the same amount of light, a smaller texture must be significantly brighter than a larger texture. Unless the q3map_lightImage or q3map_lightRGB directive is used to select a different source for the texture's light color information, the color of the light will be the averaged color of the texture. For sky shaders, use q3map_skylight instead for faster and more uniform sky illumination.
+The surface gives off light equal to the value set for it. The relative surface area in the world affects the actual amount of light that appears to be radiated. To give off what appears to be the same amount of light, a smaller surface must be significantly brighter than a larger one. Unless the q3map_lightImage or q3map_lightRGB directive is used to select a different source for the shader's light color information, the color of the light will be the averaged color of the texture. For sky shaders, use q3map_skylight instead for faster and more uniform sky illumination.
A surface with q3map_surfaceModel in its shader will randomly place a specified model across it's face. This is designed to place grass or tree models over terrain.
@@ -456,7 +456,7 @@Projects a texture Ns units by Nt units along a chosen axis. q3map_tcGen ivector ( 256 0 0 ) ( 0 256 0 ) will project a texture every 256 units in x, and every 256 units in y, along the z-axis. Ivector means inverse vector, and this means you won't have to do the divide with a calculator. Inverse = 1.0/n, unless the value is 0, then the matrix value is set to 0. A bit of dodgy math, but it works.
This works in a similar manner to the stage specific tcMod directive (see Stage Directives: tcMod), except in the compiler, so that modified texture coordinates are "baked" into the surface. This lets you set up less obvious texture tiling on natural and organic surfaces (especially terrain).
+This works in a similar manner to the stage specific tcMod directive (see Stage Directives: tcMod), except in the compiler, so that modified texture coordinates are "baked" into the surface. This lets you set up less obvious texture tiling on natural and organic surfaces (especially terrain).
Rotates the texture (around origin, not center) a specified number of degrees.
@@ -464,11 +464,11 @@Scales S (x) and T (y) texture co-ordinates. scale 2 2 would halve the size of the texture (doubling the texture co-ordinates).
-Shifts texture co-ordinates by S, T amount. translate 0.5 0 would shift it one-half in S, and none in T.
Alphamap terrain shaders (typically textures/common/terrain and terrain2) must have the q3map_terrain directive. Terrain is handled completely differently from previous versions. Q3Map2 no longer looks for the word terrain in the shader name to determine whether or not it is an indexed shader. It looks for q3map_indexed, or q3map_terrain, which then sets off a bunch of stuff shoehorned into it, like: the lightmap axis, texture projection, etc.
+Alphamap terrain shaders (typically textures/common/terrain and terrain2) must have the q3map_terrain directive. Terrain is handled completely differently from previous versions. Q3Map2 no longer looks for the word terrain in the shader name to determine whether or not it is an indexed shader. It looks for q3map_indexed, or q3map_terrain, which then sets off a bunch of stuff shoehorned into it, like: the lightmap axis, texture projection, etc.
By default, q3map_terrain sets the following:
q3map_tcGen ivector ( 32 0 0 ) ( 0 32 0 ) @@ -479,20 +479,16 @@q3map_terrain
This controls the tessellation size (how finely a surface is chopped up in to triangles), in game units, of the surface. This is only applicable to solid brushes, not curves, and is generally only used on surfaces that are flagged with the deformVertexes directive. Abuse of this can create a huge number of triangles. This happens during Q3Map2 processing, so maps must be reprocessed for changes to take effect. The poorly named tessSize directive still works but has been deprecated in favour of q3map_tessSize for consistency.
--+Design Notes:
-It can also be used on tessellating surfaces to make sure that tessellations are large and thus, less costly in terms of triangles created.
-
This enables surface tessellation and controls its size (how finely a surface is chopped up in to triangles), in game units. This is only applicable to brushes, not curves, and is generally only used on surfaces that are flagged with the deformVertexes directive. Abuse of this can create a huge number of triangles. The poorly named tessSize directive still works but has been deprecated in favour of q3map_tessSize for consistency.
Deprecated. Useful when you don't specify an editor or light image for a shader. Recent builds of Q3Map2 will find some referenced image in a shader and use that as a fallback. Historically, this was used for surface splitting for RTCW for PS2, to accommodate the hardware's limited texture range precision.
The light value, at the vertices of a surface using a shader with this option, is multiplied by the scale value. This is a way to lighten, or darken, a vertex_lit surface, in comparison to other lightmap_lit surfaces around it. Values must be normalized.
+The light value, at the vertices of a surface using a shader with this option, is multiplied by the scale value. This is a way to lighten, or darken, a vertex_lit surface, in comparison to other lightmap_lit surfaces around it.
Obsolete! (See q3map_noVertexShadows) By default, no shadows are cast on vertex_lit_surfaces (see surfaceparm pointlight). In addition, when running Quake III Arena in vertex light, no shadows are cast upon any surface at all, since shadows are part of the lightmap. When using this shader directive, shadows will be cast on surfaces that are vertex lit. However, sharp shadow edges won't be seen on the surfaces, since light values are only calculated at the vertices.
+Obsolete! (See q3map_noVertexShadows) By default, no shadows are cast on vertex_lit_surfaces (see surfaceparm pointlight). In addition, when running Quake III Arena in vertex light, no shadows are cast upon any surface at all, since shadows are part of the lightmap. When using this shader directive, shadows will be cast on surfaces that are vertex lit. However, sharp shadow edges won't be seen on the surfaces, since light values are only calculated at the vertices.