commit 507d56343369ee6c0495edbb3a0bbd9dafca9ccc Author: Marco Hladik Date: Fri Dec 4 11:56:21 2020 +0100 first commit diff --git a/ch01/pg1_1.htm b/ch01/pg1_1.htm new file mode 100644 index 0000000..a9f6cd7 --- /dev/null +++ b/ch01/pg1_1.htm @@ -0,0 +1,116 @@ + + +Vera Visions Material Manual: Introduction + + + +

Vera Visions Material Manual

+
+

1 Preface: Making Your Own Materials

+ +The Manual for the level editor program contains a section called Creating New Assets that has the necessary information for setting up the files to create your own custom materials. It is recommended that you study the scripts in this document and in the individual material scripts. Pay careful attention to syntax and punctuation. This is where you are most likely to make mistakes. + +

The material language is heavily specific to OpenGL and Vulkan graphics rendering API behaviour. You have direct access to OpenGL blend mode calls for example and are linking each material to a more advanced GLSL program to handle the actual rendering of any given surface. To write materials you do not need to know GLSL, however you should have a basic understanding of what parameters to pass (if any exist for any given GLSL) and which map commands need to be passed in order for a material to render as intended. Please look at the examples in the game for inspiration and a point of reference. + +

2 Introduction

+ +The graphic engine for Quake III Arena has taken a step forward by putting much more direct control over the surface +qualities of textures into the hands of designers and artists. That's why its engine technology was chosen as a basis +for The Wastes and future games by Vera Visions. +
+In writing this manual, we have tried to define the concepts and tools that are used to modify textures in a way that, it is hoped, will be graspable by users who already have basic knowledge ofcomputer graphics but are not necessarily computer programmers. It is not a tutorial, nor was it intended to be one. + +

2.1 What is a Material?

+ +Materials are short text scripts that define the properties of a surface as it appears and functions in a game world (or compatible editing tool). By convention, the documents that contain these scripts usually has the same name as the texture set which contains the textures being modified (e.g; base, hell, castle, etc,). Several specific script documents have also been created to handle special cases, like liquids, sky and special effects. + +

Material scripts are located in the textures/ directory, along with their assets, with the ".mat" file extension. + +

A material file consists of a series of surface attributes (global scope) and rendering instructions formatted +within braces ("{" and "}"). Below you can see a simple example of syntax and format for a single process, including the +VMAP keywords or "Surface Parameters", which follow the first bracket and a single bracketed "stage": + +

+// Vera Visions Material
+{
+	diffusemap textures/common/lava.tga
+	vmap_tessSize 64
+	{
+		program unlit
+		map $diffusemap
+		blendFunc add
+	}
+}
+
+ +

2.2 Material Name & File Conventions

+The first line is a simple comment. All the official textures are marked that way. +The file-name of the material, as well as the full path are often a mirror of a pathname to a standard .tga file without the extension or base dir (/TW/wastes in our case), but they do not need to be. + +

Materials that are placed on surfaces in the map editor commonly mirror a .tga file, but the "qer_editorimage" parameter canforce the editor to use an arbitrary image for display. + +

Material pathnames have a case sensitivity issue - on Microsoft Windows, they aren't case sensitive, but on UNIX they are. Try to always use lowercase for filenames, and always use forward slashes "/" for directory separators. + +

2.3 Material Types

+The keywords that affect materials are divided into two classes. The first class of keywords are global parameters. Some global parameters ("surfaceparms." And all "vmap_" keywords) are processed by VMAP, and change physical attributes of the surface that uses the material. These attributes can affect the player. To see changes in these parameters one must recompile the level. + +

The remaining global keywords, and all Stage Specific Keywords are processed by the renderer. They are appearance changes +only and have no effect on game play or game mechanics. Changes to any of these attributes will take effect as soon as the game goes to another level or vid_reload (type command vid_reload in the game console). + +

The "program" keyword inside of a stage tells the renderer which GLSL program to run on the material. GLSL programs control the entire rendering routine for any given surface. There's a few available to you. In the above example it would cause the texture to be rendered without lighting and just the diffuse texture. + +

The "blendFunc" keyword is another Stage Specific Keyword that affects how the material is drawn on top of everything else. It will never be placed as a global paremeter, as it will never affect gameplay. + +

Material keywords are not case sensitive. + +

IMPORTANT NOTE: some of the material commands may be order dependent, so it's good practice to place all global material commands (keywords defined in this section) at the very beginning of the material and to place stages at the end (see various examples). + +

2.4 Key Concepts

+ +Ideally, a designer or artist who is manipulating textures with material files has a basic understanding of wave forms and knows about mixing colored light (high school physics sort of stuff). If not, there are some concepts you need to have a +grasp on to make materials work for you. + +

2.4.1 Surface Effects vs. Content Effects
+Materials not only modify the visible aspect of textures on a geometry brush, curve, patch or mesh model, but they can also have an effect on both the content, "shape," and apparent movement of those things. A surface effect does nothing to modify +the shape or content of the brush. Surface effects include glows, transparencies and rgb (red, green, blue) value +changes. Content materials affect the way the brush operates in the game world. Examples include water, fog, nonsolid, and +structural. A GLSL program can also affect the movement of a surface. Water can be tesselated and create waves, for example. This is all done +within a GLSL program with an appropriate vertex shader. + +

2.4.2 Power Has a Price
+The material script gives the designer, artist and programmer a great deal of easily accessible power over the appearance of +and potential special effects that may be applied to surfaces in the gameworld. But it is power that comes with a price tag +attached, and the cost is measured in performance speed. Each material phase that affects the appearance of a texture causes the Q3:Aengine to make another processing pass and redraw the world. Think of it as if you were adding all +the material-affected triangles to the total r_speed count for each stage in the material script. A material-manipulated texture that is seen through another material-manipulated texture (e.g. a light in fog) has the effect of adding the total number of passes together for the affected triangles. A light that required two passes seen through a fog that requires one pass will be treated as having to redraw that part of the world three times. + +

2.4.3 RGB Color
+ +RGB means "Red, Green, Blue."Mixing red, green and blue light in differing intensities creates the colors in computers and television monitors. This is called additive color (as opposed to the mixing of pigments in paint or colored ink in the printing process, which is subtractive color). Here and in most higher-end computer art programs (and the color selector in Windows), the intensities ofthe individual Red, Green and Blue components are expressed as number values. When mixed together on a screen, number values of equal intensity in each component color create a completely neutral (gray) color. The lower the number value (towards 0), the darker the shade. The higher the value, the lighter the shade or the more saturated the color until it reaches a maximum value of 255 (in the art programs). All colors possible on the computer can be expressed as a formula of three numbers. The value for complete black is 0 0 0. The value for complete white is 255 255 255. However, the graphics engine requires that the color range be "normalized" into a range between 0.0 and 1.0. + +

2.4.4 Normalization: a Scale of 0 to 1
+The mathematics here use a scale of 0.0 to 1.0 instead of 0 to 255. Most computer art programs that can express RGB values as numbers use the 0 to 255 scale. To convert numbers, divide each of the artprogram's values for the component colors by 255. The resulting three values are your formula for that color component. The same holds true for texture coordinates. + +

2.4.5 Texture Sizes
+TGA texture files are measured in pixels (picture elements). Textures are measured in powers of 2, with 16 x16 pixels being the smallest (typically) texture in use. Most will be larger. Textures need not be square, so long as both dimensions are powers of 2. Examples include: 32x256, 16x32, 128x16. + +

2.4.6 Color Math
+ +Colors are changed by mathematical equations worked on the textures by way ofthe scripts or +"programlets" in the material file. An equation that adds to or multiplies the number values in atexture causes it to become +darker. Equations that subtract from or modulate number values in a texture cause it to become lighter. Either equation can change the hue and saturation of a color. + +

2.4.7 Measurements
+ +The measurements used in the materials are in either game units, color units, or texture units. + +

· Game unit: A game unit is used by deformations to specify sizes relative to the world. Game units are the same scale we have had since way back in the Wolfensteindays - 8 units equals one foot. The default texture scale used by the WorldSpawn map editor results in two texels for each game unit, but that can be freely changed. + +

· Color units: Colors scale the values generated by the texture units to produce lighting effects. A value of 0.0 will be completely black, and a value of 1.0 will leave the texture unchanged. Colors are sometimes specified with a single value to be used across all red, green,and blue channels, or sometimes as separate values for each channel. + +

· Texture units: This is the normalized (see above) dimensions of the original texture image (or a previously modified texture at a given stage in the material pipeline). A full texture, regardless of its original size in texels, has a normalized measurement of 1.0 x 1.0. For normal repeating textures, it is possible to have value greater than 1.0 or less than 0.0, resulting in repeating of the texture. The coordinates are usually assigned by the level editor or +modeling tools, but you still need to be aware of this for scrolling or turbulent movement of the texture at runtime. + +

Back | Home | Next + + + diff --git a/ch02/pg2_1.htm b/ch02/pg2_1.htm new file mode 100644 index 0000000..222ea14 --- /dev/null +++ b/ch02/pg2_1.htm @@ -0,0 +1,172 @@ + + +Vera Visions Material Manual: General Material Keywords + + + +

Vera Visions Material Manual

+
+

3 General Material Keywords

+IMPORTANT NOTE: Once again, be aware that some of the shader commands may be order dependent, so it's good practice to place all global shader commands (keywords defined inthis section) at the very beginning of the shader and to place shader stages at the end (see various examples). + +

These Keywords are global to a shader and affect all stages. + +

3.1 diffusemap <texturepath/texturename>

+Specifies the default texture asset to use on the diffuse/albedo pass of the material. This is the base texture in most cases. Some special materials used for special effects and the like might not have one. However surfaces such as floors, walls etc. certainly do. +It will affect which texture is used to get color information from for lighting passes, etc. + +

3.2 normalmap <texturepath/texturename>

+Specifies the default texture to use for any normalmap operations. This depends heavily on which GLSL program is used inside the later stages. +The dynamic lights will use this to determine height information for light and shadows. So sometimes you want to skip setting this. + +

3.3 specularmap <texturepath/texturename>

+Can set the specularity of the surface in relation to dlights. Specularity is the intensity of the light reflecting off the surface. In special cases some GLSL programs might use the texture it for other purposes, too. + +

3.4 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). Some of the VMAP specific commands use this as a reference as to what skybox to use for color, intensity etc. + +

The renderer will take it into account only if you do not supply any Stages in the material. + +

<farbox> Specifies a set of files to use as an environment box behind all cloudlayers. Specify "-" for no +farbox, or a file base name. A base name of "env/test" would look for files "env/test_rt.tga", "env/test_lf.tga", +"env/test_ft.tga", "env/test_bk.tga", "env/test_up.tga", "env/test_dn.tga" to use as the right / left / front / back / up / +down sides. + +
<cloudheight> controls apparent curvature of the cloud layers - lower numbers mean more curvature (and thus more distortion at the horizons). Higher height values create "flatter" skies with less horizon distortion. Think of height +as the radius of a sphere on which the clouds are mapped. Good ranges are 64 to 256. The default value is 128. + +
<nearbox> Specified as farbox, to be alpha blended ontop of the clouds. This has not be tested in a long time, so it probably doesn't actually work. Set to "-" to ignore. + + + +

Example: Sky script + +

+// Vera Visions Material
+{
+	qer_editorImage textures/skies/dune.tga
+	skyParms textures/skies/dune/bg 256 -
+	noPicMip
+	noMipmaps
+
+	vmap_lightmapFilterRadius 0 8
+	vmap_sun 0.34 0.22 0.09 120 -28 127
+	vmap_skyLight 190 6
+	surfaceParm sky
+	surfaceParm noimpact
+	surfaceParm nolightmap
+	surfaceParm nodlight
+	{
+		program skybox
+		map $cube:textures/skies/dune/bg
+		map textures/skies/clouds/dunecloud.tga
+		map textures/skies/clouds/dunecloud_layer.tga
+	}
+}
+
+ +

3.5 cull <side>

+Every surface of a polygon has two sides, a front and a back. Typically, we only see the front or "out" side. For +example, a solid block you only show the front side. In many applications we see both. For example, in water, you can see both front and a back. The same is true for things like grates and screens. + +

To "cull" means to remove. The value parameter determines the type of face culling to apply. The default value is cull front if this keyword is not specified. However for items that should be inverted then the value back should be used. To disable culling, the value disable or none should be used. Only one cull instruction can be set +for the shader. + +

3.5.1 cull front
+ +The front or "outside" of the polygon is not drawn in the world. This is the default value. It is used if the keyword "cull " appears in the content instructions without a <side> value or if the keyword cull does not appear at all in the shader. + +

3.5.2 cull back
+ +Cull back removes the back or "inside" of a polygon from being drawn in the world. + +

3.5.3 cull disable, cull none
+Neither side of the polygon is removed. Both sides are drawn in the game. Very useful for making panels or barriers that +have no depth, such as grates, screens, metal wire fences and so on and for liquid volumes that the player can see from within. Also used for energy fields, sprites, and weapon effects (e.g. plasma). + +

Design Notes: For things like grates and screens, put the texture with the cull none property on one face only. On the other faces, use a non-drawing texture.
+ +

3.6 fogparms <red +value> <green value> <bluevalue> <distance to +Opaque>

+ +

Note: you must also specify "surfaceparm fog" to cause q3map to identify the surfaces inside the volume. Fogparms only +describes how to render the fog on the surfaces. + +

<red value> <green value> <blue value> These are normalized values. A good computer art program should give you the RGB values for a color. To obtain the values that define fog color for Quake III Arena, divide the desired color's Red, Green and Blue values by 255 to obtain three normalized numbers within the 0.0 to 1.0 range. + +
<distance toopaque> This is the distance, in game units, until the fog becomes totally opaque, as measured from the point of view of the observer. By making the height of the fog brush shorter than the distance to opaque, the apparent density of the fog can be reduced (because it never reaches the depth at which full opacity occurs). + +

+ +

Design Notes: + +
+ +

3.7 noPicMip

+This causes the texture to ignore user-set values for the gl_picmip cvar command. The image will always be high +resolution. Example: Used to keep images and text in the heads up display from blurring when user optimizes the game graphics. + +

3.8 noMipmaps

+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. + +

3.9 polygonOffset <value>

+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 variable. If no value is supplied a distance of 1 is assumed, however this is meant for backwards compatibility. Being explicit will help grepping values later in case you need to find all surfaces with just a polygonOffset of 1. + +

3.10 portal

+Specifies that this texture is the surface for a portal or mirror. In the game map, a portal entity must be placed directly in front of the texture (within 64 game units). All this does is set "sort portal", so it isn't needed if you specify +that explicitly. + +

3.11 sort <value>

+Use this keyword to fine-tune the depth sorting of shaders as they are compared against other shaders in the game world. The +basic concept is that if there is a question or a problem with shaders drawing in the wrong order against each other, this allows the designer to create a hierarchy ofwhich shader draws in what order. + +

The default behavior is to put all blended shaders in sort "additive" 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 (alternatively) one of the keywords in the following list (listed in order of mostly ascending priority): + +

+ +

Back | Home | Next + + + diff --git a/ch03/pg3_1.htm b/ch03/pg3_1.htm new file mode 100644 index 0000000..126c401 --- /dev/null +++ b/ch03/pg3_1.htm @@ -0,0 +1,277 @@ + + +Vera Visions Material Manual: Specific Material Keywords + + + +

Vera Visions Material Manual

+
+

4 VMAP Specific Material Keywords

+These keywords change the physical nature of the textures and the brushes that are marked with them. Changing any of these values will require the map to be re-compiled. These are global and affect the entire material. + +

4.1 vmap_tessSize <amount>

+The vmap_tessSize keyword 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 manipulated by a vertex shader program. Abuse of this can create a huge number of triangles. This happens during VMAP processing, so maps must be reprocessed for changes to take effect. + +

Design Note: It can also be used on tesselating surfaces to make sure that tesselations are large, and thus, less costly in terms of triangles created.
+ +

4.2 vmap_backshader <materialname>

+This allows a brush to use a different material 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 (see sort above) or appearance when seen from the inside. + +

4.3 vmap_globaltexture

+Many problems with getting material effects to work across multiple adjacent brushes are a result of the way VMAP 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. + +

4.4 vmap_sun <red> <green> <blue> <intensity> <degrees> <elevation> <deviance> <samples>

+This keyword in a sky material will create the illusion of light cast into a map by a single, infinitely distance light source (sun, moon, hellish fire, etc.). This is only processed during the lighting phase of VMAP. + +

<red><green> <blue> Color is described by three normalized rgbvalues. Color will be normalized to a 0.0 to 1.0 range, so it doesn't matter what range you use. + +
<intensity> is the brightness of the generated light. A value of 100 is a fairly bright sun. The +intensity of the light falls off with angle but not distance. + +
<degrees> is the angle relative to the directions on the map file. A setting of 0 degrees equals east. 90 +isnorth, 180 is west and 270 is south. + +
<elevation> is the distance, measured in degrees from the horizon (z value of zero in the map file). An +elevation of 0 is sunrise/sunset. An elevation of 90 is noon. + +
<deviance> is the number of degrees for the half-shadow. General values up to 2 or 3 are acceptable. The real sun has a solid angle of about half a degree. + +
<samples> is the number of random jitters distributed over the solid arc (~16). + +

DESIGN NOTE: Sky materials should probably still have a vmap_surfacelight 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 vmap_sun value and a higher vmap_surfacelight value. Heavy clouds diffuse light and weaken shadows. The opposite is true of a cloudless or nearly cloudless sky. Insuch cases, the "sun" or "moon" will cast stronger, shadows that have a greater degree of contrast. + +

Design Trick: Not certain what color formula you want to use for the sun's light? Try this. Create a light entity. Use the level 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 material.

+ +

4.5 vmap_surfaceLight <light value>

+ +The texture gives off light equal to the <light 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 qer_lightimage keyword 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. + +

4.6 vmap_lightimage <texturepath/texturename>

+The keyword vmap_lightimage generates lighting from the average color of the TGA image specified by the +vmap_lightimage. + +

The keyword sequence for generating light on a vmap_surfacelight should be ordered as follows: + +

  1. vmap_lightimage ; (the texture providing the light and the color of the light) +
  2. qer_editorimage ; (the editor-only image used to select the source map for the texture) +
  3. the average color of the light emitted from the material is calculated from the lightimage.)
+ +

The reason vmap_lightimage is specified for the light in the example below, is because the blend map is predominantly yellow, and the designer wanted more yellow light to be emitted from the light. + +

Example: Taking light from another source texture + +

+// Vera Visions Material
+{
+	// base TGA (used because the material is used with several
+	// different light values
+	diffusemap textures/gothic_light/ironcrosslt2.tga
+
+	// this TGA is the source for the color of the blended light
+	vmap_lightimage textures/gothic_light/ironcrosslt2.blend.tga
+
+	// emitted light value of 10,000
+	vmap_surfacelight 10000
+
+	{
+		program lightmapped
+		map $diffusemap
+	}
+	{
+		program unlit
+		map textures/gothic_light/ironcrosslt2.tga
+		blendFunc filter
+	}
+	{
+		program unlit
+		map textures/gothic_light/ironcrosslt2.blend.tga
+		blendFunc add
+	}
+}
+
+ +

4.7 vmap_lightsubdivide <value>

+This allows the user to define how large, or small to make the subdivisions (triangles) in a textured surface, particularly aimed at light-emitting textures like skies. It defaults to 120 game units, but can be made larger (256 or 512) for sky boxes or smaller for light surfaces at the bottoms of cracks. This can be a dominant factor in processing time for VMAP lighting. + +

4.8 surfaceparm <parm>

+ +

The surfaceparm keyword is not only read by the VMAP compiler, but also by the renderer. A few keywords will only apply to any one of them. + +

All surfaceparm keywords are preceded by the word surfaceparm as follows: surfaceparm fog or surfaceparm noimpact. + +

4.8.1 alphashadow
+This keyword applied to a texture on a brush, patch or model will cause the lighting phase of the VMAP process to use the texture's alpha channel as a mask for casting static shadows in the game world. + +

Design Note: Alphashadow does not work well with fine line detail on a texture. Fine lines may not cast acceptable shadows. It appears to work best with well-defined silhouettes and wider lines within the texture. Most of our tattered banners use this to cast tattered shadows.
+ +

4.8.2 areaportal
+A brush marked with this keyword functions as an area portal, a break in the VMAP tree. It is typically placed on a very thin brush placed inside a door entity (but is not a part of that entity). The intent is to block the game from processing +surface triangles located behind it when the door is closed. It is also used by the BSPC (bot area file creation compiler) in the same manner as a clusterportal. The brush must touch all the structural brushes surrounding the +areaportal. + +

4.8.3 clusterportal
+A brush marked with this keyword function creates a subdivision of the area file (.aas) used by the bots for navigation. It +is typically placed in locations that are natural breaks in a map, such a sentrances to halls, doors, tunnels, etc. The intent is keep the bot from having to process the entire map at once. As with the the areaportal parameter, the affected brush must touch all the structural brushes surrounding the areaportal. + +

4.8.4 donotenter
+Read as "do not enter." Like clusterportal, this is a bot-only property. A brush marked with donotenter will not affect +non-bot players, but bots will not enter it. It should be used only when bots appear to have difficulty navigating around some map features. + +

4.8.5 fog
+Fog defines the brush as being a "fog" brush. This is a VMAP function that chops and identifies all geometry inside the +brush. The General material keyword fogparms must also be specified to tell how to draw the fog. + +

4.8.6 lava
+Assigns to the texture the game properties set for lava. This affects both the surface and the content of a brush. + +

4.8.7 lightfilter
+Causes the VMAP light stage to use the texture's RGB and alpha channels to generate colored alpha shadows in the lightmap. For example, this can be used to create the colored light effect cast by stained glass windows. This can be used with surfaceparm alphashadow if an alpha is to be respected. + +

4.8.8 nodamage
+The player takes no damage if he falls onto a texture with this surfaceparm + +

4.8.9 nodlight
+Read as "No DeeLight". A texture containing this parameter will not be affected or lit by dynamic lights, such as +weapon effects. The VMAP compiler doesn't really care about this, but the renderer does. + +

4.8.10 nodraw
+A texture marked with nodraw will not visually appear in the game world. Most often used for triggers, clip brushes, origin +brushes, and so on. Light will pass through it, therefore beware of bleeding issues when using nodraw/caulk textures with this. + +

4.8.11 nodraw2
+Same as nodraw, but the engine won't draw it, whereas the VMAP compiler will react to the surface. So unlike nodraw, light will not pass through these surfaces. + +

4.8.12 noimpact
+World entities will not impact on this texture. No explosions occur when projectiles strike this surface and no marks +will be left on it. Sky textures are usually marked with this texture so those projectiles will not hit the sky and leave +marks. + +

4.8.13 nomarks
+Projectiles will explode upon contact with this surface, but will not leave marks. Blood will also not mark this surface. +This is useful to keep lights from being temporarily obscured by battle damage. + +

4.8.14 nolightmap
+This texture does not have a lightmap phase. It is not affected by the ambient lighting of the world around it. It does not +require the addition of an rgbGen identity keyword in that stage. + +

4.8.15 nosteps
+The player makes no sound when walking on this texture. + +

4.8.16 nonsolid
+This attribute indicates a brush, which does not block the movement of entities in the game world. It applied to +triggers, hint brushes and similar brushes. This affects the content of a brush. + +

4.8.17 origin
+Used on the "origin" texture. Rotating entities need to contain an origin brush in their construction. The brush must be +rectangular (or square). The origin point is the exact center of the origin brush. + +

4.8.18 playerclip
+Blocks player movement through a nonsolid texture. Other game world entities can pass through a brush marked +playerclip. The intended use for this is to block the player but not block projectiles like rockets. + +

4.8.19 slick
+This surfaceparm included in a texture should give it significantly reduced friction. + +

4.8.20 slime
+Assigns to the texture the game properties for slime. This affects both the surface and the content of a brush. + +

4.8.21 structural
+This surface attribute causes a brush to be seen by the VMAP process as a possible break-point in a BSP tree. It is used +as a part of the material for the "hint" texture. Generally speaking, any opaque texture not marked as "detail" is, by +default, structural, so you shouldn't need to specify this. + +

4.8.22 trans
+Light will pass through this surface, but only if neither alphashadow or lightfilter are applied. +Tells VMAP that pre-computed visibility should not be blocked by this surface. Generally, any materials that have blendfuncs +should be marked as surfaceparm trans. + +

4.8.23 water
+Assigns to the texture the game properties for water. + +

4.8.24 climb
+Marks the desired surface as a climbable surface. This currently affects the entire volume. + +

4.8.25 vehicleclip
+Blocks all movement of vehicle entities through this surface. + +

4.8.26 leakssteam
+When this surface is impacted, steam will leak out temporarily. Specific to The Wastes 1.3. + +

4.8.27 leakswater
+When this surface is impacted, water will leak out temporarily. Specific to The Wastes 1.3. + +

4.8.28 alien
+Defines that the surface is of an 'alien' material. Affects impact sound and effects. + +

4.8.29 flesh
+Defines that the surface is of flesh. Affects impact sound and effects. + +

4.8.30 foliage
+Defines that the surface is foliage. Affects impact sound and effects. + +

4.8.31 computer
+Defines that the surface is of computer parts. Affects impact sound and effects. + +

4.8.32 dirt
+Defines that the surface is of dirt. Affects impact sound and effects. + +

4.8.33 vent
+Defines that the surface is a vent. Affects impact sound and effects. + +

4.8.34 grate
+Defines that the surface is a grate. Affects impact sound and effects. + +

4.8.35 metal
+Defines that the surface is of metal. Affects impact sound and effects. + +

4.8.36 glass
+Defines that the surface is of glass. Affects impact sound and effects. + +

4.8.37 sand
+Defines that the surface is of sand. Affects impact sound and effects. + +

4.8.38 slosh
+Defines that the surface is of a liquid. Affects impact sound and effects. + +

4.8.39 snow
+Defines that the surface is of snow. Affects impact sound and effects. + +

4.8.40 tile
+Defines that the surface is of kitchen/bathroom tiles. Affects impact sound and effects. + +

4.8.41 wood
+Defines that the surface is of wood. Affects impact sound and effects. + +

4.8.42 concrete
+Defines that the surface is of concrete. Affects impact sound and effects. + + +

4.8.43 fl_r1
+Reserved for custom games. This can be anything. + +

4.8.44 fl_r2
+Reserved for custom games. This can be anything. + +

4.8.45 fl_r3
+Reserved for custom games. This can be anything. + +

4.8.46 fl_r4
+Reserved for custom games. This can be anything. + +

4.8.47 fl_r5
+Reserved for custom games. This can be anything. + +

4.8.48 fl_r6
+Reserved for custom games. This can be anything. + +

4.8.49 fl_r7
+Reserved for custom games. This can be anything. + + +

Back | Home | Next + + + diff --git a/ch04/pg4_1.htm b/ch04/pg4_1.htm new file mode 100644 index 0000000..ce3dd1f --- /dev/null +++ b/ch04/pg4_1.htm @@ -0,0 +1,55 @@ + + +Vera Visions Material Manual: Editor Specific Material Instructions + + + +

Vera Visions Material Manual

+
+

5 Editor specific material instructions

+These instructions only affect the texture when it is seen in the level editor. They should be grouped with the surface +parameters but ahead of them in sequence. + +

5.1 qer_editorimage <texture path/texturename>

+This keyword creates a material name in memory, but in the editor, it displays the TGA art image specified in qer_editorimage (in the example below this is textures/eerie/lavahell.tga). + +

The editor maps a texture using the size attributes of the TGA file used for the editor image. When that editor image represents a material, any texture used in any of the material stages will be scaled up or down to the dimensions of the editor image. If a 128x128 pixel image is used to represent the material in the editor, then a 256x256 image used in a later stage will be shrunk to fit. + +

Design Notes: The base_light and gothic_light materials contain numerous uses of this. It can be very useful for making different light styles (mostly to change the light brightnesses) without having to create a new piece of TGA art for each new material.
+ + +

+// Vera Visions Material
+{
+	qer_editorimagetextures/eerie/lavahell.tga // based on this
+	qer_nocarve // cannot be cut by CSG subtract
+	surfaceparm noimpact // projectiles do not hit it
+	surfaceparm lava // has the game properties of lava
+	surfaceparm nolightmap // environment lighting does not affect
+	
+	vmap_surfacelight 3000 // light is emitted
+	vmap_tessSize 256 // relatively large triangles
+	cull disable // no sides are removed
+	
+	deformVertexes wave 100 sin 5 5 .5 0.02
+	fogparms 0.8519142 0.309723 0.0 128 128
+	{
+		program unlit
+		map textures/eerie/lavahell.tga // base texture artwork
+		blendFunc GL_ONE GL_ONE // blend additively over everything else
+	}
+}
+
+ +

5.2 qer_nocarve

+A brush marked with this instruction will not be affected by CSG subtract functions. It is especially useful for water and fog textures. + +

5.3 qer_trans <value>

+This parameter defines the percentage of transparency that a brush will have when seen in the editor (no effect on game +rendering a tall). It can have a positive value between 0 and 1. The higher the value, the less transparent the texture. +Example: qer_trans 0.2 means the brush is 20% opaque and nearly invisible. + +

Back | Home | Next + + + diff --git a/ch05/pg5_1.htm b/ch05/pg5_1.htm new file mode 100644 index 0000000..eb56a8c --- /dev/null +++ b/ch05/pg5_1.htm @@ -0,0 +1,176 @@ + + +Vera Visions Material Manual: Stage Specific Keywords + + + +

Vera Visions Material Manual

+
+

6 Stage Specific Keywords

+Stage specifications only affect rendering. Changing any keywords or values within a stage will usually take effect as soon +as a vid_reload is executed. VMAP ignores stage specific keywords entirely. + +

A stage can specify a texture map, a color function, an alpha function, a texture coordinate function, a blend function, and a few other rasterization options. + +

6.1 Shader specification

+ +
6.1.1 program <shadername>
+Specifies the GLSL vertex/fragment shader program to use on this surface. +This needs to be first command within every stage. + +

6.1.2 permu <key> <value>
+Set a shader permutation for the above named program. This is effectively how you change parameters of some vertex/fragment shader programs. Which permutations each shader supports is up to the individual shader. Keep in mind that each unique combination results in another compile of said shader program and so comes at a price. + +

6.2 Texture map specification

+
6.2.1 map <texturepath/texturename>
+Specifies the source texture map (a 24 or 32-bit TGA file) used for this stage. The texture may or may not contain alpha +channel information. There are special keywords that may be substituted in lieu of an actual +texture map name: + +

6.2.2 clampmap <texturepath>
+Dictates that this stage should clamp texture coordinates instead of wrapping them. In short: The texture does not tile. + +

6.2.3 animmap <frequency> <texture1> … <texture8>
+The surfaces in the game can be animated by displaying asequence of 1 to 8 frames (separate texture maps). These animations +are affected by other keyword effects in the same and later shader stages. + +

<Frequency>: the number of times that the animation cycle will repeat within a one second time period. The +larger the value, the more repeats within a second. Animations that should last for more than a second need to be expressed as decimal values. + +
<texture1> …<texture8>: the texture path/texture name for each animation frame must be +explicitly listed. Up to eight frames (eight separate .tga files) can be used to make an animated sequence. Each frame is +displayed for an equal subdivision of the frequency value. + +

Design Notes: To make a texture image appear for an unequal (longer) amount of time (compared to other frames), repeat that frame more than once in the sequence.
+ +

+// Vera Visions Material
+{
+	qer_editorimage textures/sfx/b_flame7.tga
+	vmap_lightimage textures/sfx/b_flame7.tga
+	surfaceparm trans
+	surfaceparm nomarks
+	surfaceparm nolightmap
+	vmap_surfacelight 1800
+	cull none
+
+	{
+		animMap 10 textures/sfx/b_flame1.tga textures/sfx/b_flame2.tga textures/sfx/b_flame3.tga textures/sfx/b_flame4.tga textures/sfx/b_flame5.tga textures/sfx/b_flame6.tga textures/sfx/b_flame7.tga textures/sfx/b_flame8.tga
+		blendFunc GL_ONE GL_ONE
+
+	}
+	{
+		animMap 10 textures/sfx/b_flame2.tga textures/sfx/b_flame3.tga textures/sfx/b_flame4.tga textures/sfx/b_flame5.tgatextures/sfx/b_flame6.tga textures/sfx/b_flame7.tga textures/sfx/b_flame8.tga textures/sfx/b_flame1.tga
+		blendFunc GL_ONE GL_ONE
+	}
+	{
+		program unlit
+		map textures/sfx/b_flameball.tga
+		blendFunc GL_ONE GL_ONE
+	}
+}
+
+ +

6.3 Blend Functions

+Blend functions are the keyword commands that tell the renderer how graphic layers are to be mixed together. + +

6.3.1 Simplified blend functions:
+The most common blend functions are set up here as simple commands, and should be used unless you really know what you are +doing. + +

6.3.1.1 blendFunc add +
This is a shorthand command for blendFunc GL_ONE GL_ONE. Effects like fire and energy are additive. + +

6.3.1.2 blendFunc filter +
This is a shorthand command that can be substituted for either blendFunc GL_DST_COLOR GL_ZERO or blendFunc GL_ZERO GL_SRC_COLOR. A filter will always result in darker pixels than what is behind it, but it can also remove color selectively. Lightmaps are filters. + +

6.3.1.3 blendFunc blend +
Shorthand for blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA. This is conventional transparency, where part of the background is mixed with part of the texture. + +

6.3.2 Explicit blend functions:
+Getting a handle on this concept is absolutely key to understanding all shader manipulation of graphics. + +

BlendFunc or "Blend Function" is the equation at the core of processing shader graphics. The formula reads as follows: + +

[Source *<srcBlend>] + [Destination * +<dstBlend>] + +

Source is usually the RGB color data in a texture TGA file (remember it's all numbers) modified by any rgbgen and alphagen. In the shader, the source is generally identified by command MAP, followed by the name of the image. + +

Destination is the color data currently existing in the frame buffer. + +

Rather than think of the entire texture as a whole, it maybe easier to think of the number values that correspond to a single pixel, because that is essentially what the computer is processing … one pixel of the bit map at a time. + +

The process for calculating the final look of a texture in place in the game world begins with the precalculated lightmap for the area where the texture will be located. This data is in the frame buffer. That is to say, it is the initial data in the Destination. In an unmanipulated texture (i.e. one without a special shader script), color information from the texture is combined with the lightmap. In a shader-modified texture, the $lightmap stage must be present for the lightmap to be included in the calculation of the final texture appearance. + +

Each pass or "stage" of blending is combined (in a cumulative manner) with the color data passed onto it by the +previous stage. How that data combines together depends on the values chosen for the Source Blends and Destination Blends at each stage. Remember it's numbers that are being mathematically combined together that are ultimately interpreted as colors. + +

A general rule is that any Source Blend other than GL_ONE (or GL_SRC_ALPHA where the alpha channel is entirely white) will cause the Source to become darker. + +

6.3.3 Source Blend <srcBlend>
+The following values are valid for the Source Blend part of the equation. + +

GL_ONE This is the value 1. When multiplied by the Source, the value stays the same the value of the color information does not change. + +
GL_ZERO This is the value 0. When multiplied by the Source, all RGB data in the Source becomes Zero (essentially black). + +
GL_DST_COLOR This is the value of color data currently in the Destination (frame buffer). The value of that information depends on the information supplied by previous stages. + +
GL_ONE_MINUS_DST_COLOR This is nearly the same as GL_DST_COLOR except that the value for each component color +is inverted by subtracting it from one. (,i.e. R = 1.0 - DST.R, G = 1.0 - DST.G, B = 1.0 - DST.B, etc.) + +
GL_SRC_ALPHA The TGA file being used for the Source data must have an alpha channel in addition to its RGB channels (for a total of four channels). The alpha channel is an 8-bit black and white only channel. An entirely white alpha channel will not darken the Source. + +
GL_ONE_MINUS_SRC_ALPHA This is the same as GL_SRC_ALPHA except that the value in the alpha channel is inverted by subtracting it from one.(i.e. A=1.0 - SRC.A) + +

6.3.4 Destination Blend <dstBlend>
+The following values are valid for the Destination Blend part of the equation. + +

GL_ONE This is the value 1. When multiplied by the Destination, the value stays the same the value of the color information does not change. + +
GL_ZERO This is the value 0. When multiplied by the Destination, all RGB data in the Destination becomes Zero (essentially black). + +
GL_SRC_COLOR This is the value of color data currently in the Source (which is the texture being manipulated here). + +
GL_ONE_MINUS_SRC_COLOR This is the value of color data currently in Source, but subtracted from one(i.e. +inverted). + +
GL_SRC_ALPHA The TGA file being used for the Source data must have an alpha channel in addition to its RGB channels (four a total of four channels). The alpha channel is an 8-bit black and white only channel. An entirely white alpha channel will not darken the Source. + +
GL_ONE_MINUS_SRC_ALPHA This is the same as GL_SRC_ALPHA except that the value in the alpha channel is inverted by subtracting it from one. (i.e. A=1.0 - SRC.A). + +

Doing the Math: The Final Result + +
The product of the Source side of the equation is added to the product of the Destination side of the equation. The sum is then placed into the frame buffer to become the Destination information for the next stage. Ultimately, the equation creates a modified color value that is used by other functions to define what happens in the texture when it is displayed in the game world. + +

6.3.5 Default Blend Function
+If no blendFunc is specified then no blending will take place. That's just a fact of life. + +

6.4 depthFunc <func>

+This controls the depth comparison function used while rendering. The default is "lequal" (Less than or equal to) +where any surface that is at the same depth or closer of an existing surface is drawn. This is used for textures with +transparency or translucency. Under some circumstances you may wish to use "equal", e.g. for light-mapped grates that are alpha tested (it is also used for mirrors). + +

6.5 depthWrite

+By default, writes to the depth buffer when depthFunc passes will happen for opaque surfaces and not for translucent surfaces. Blended surfaces can have the depth writes forced with this function. + +

Back | Home | Next + + + diff --git a/index.html b/index.html new file mode 100644 index 0000000..035888a --- /dev/null +++ b/index.html @@ -0,0 +1,64 @@ + + +Vera Visions Material Manual: Table of Contents + + + +

+

Vera Visions Material Manual

+ +

Revision #14

+ +

modified by Marco 'eukara' Hladik + +

Original version by Paul Jaquays & Brian Hook +

(with additional material by John Carmack, Christian Antkow, Kevin Cloud, & Adrian Carmack)

+
+

Table of Contents

+1 Preface: Making Your Own Materials +
2 Introduction + + +3 General Material Keywords + + +4 VMAP Specific Material Keywords + + +5 Editor specific shader instructions + + +6 Stage Specific Keywords + + + diff --git a/styles/design.css b/styles/design.css new file mode 100644 index 0000000..e98ae2b --- /dev/null +++ b/styles/design.css @@ -0,0 +1,23 @@ +body { font: 12pt "Times New Roman"; + margin-left: 5mm; + margin-right: 5mm; + text-align: justify; + background: #ffffff; + color: #000000 } +h1 { font: bold 24pt Arial, Helvetica } +h2 { font: bold italic 18pt Arial, Helvetica } +.subheading { font: bold 16pt Arial, Helvetica } +:link {color: blue; + text-decoration: none; } +:visited {color: purple; + text-decoration: none; } +h6 { font: 10pt "Times New Roman" } +.MsoToc2 { font: bold small-caps 12pt "Times New Roman" } +.MsoTitle { text-align:center; + font: bold 24pt "BankGothic Md BT"; + letter-spacing:2.5pt } +.heading { font: italic 10pt "Times New Roman" } +.subcontents { font: 10pt "Times New Roman" } +.tip { font: 10pt "Comic Sans MS" } +.type { font: 10pt "Courier New" } +.menu { font: 10pt Arial, Helvetica } \ No newline at end of file