-
Notifications
You must be signed in to change notification settings - Fork 16
Textures
Base docs from Half-Life Professional SDK 2.0; I cut out unnecessary information.
Regular tiling textures can be named anything.
A Half-Life innovation is the randomly tiling texture set. This texture is very useful for organic materials or for organic damage to regular textures. With a random texture family, each texture is designed to tile seamlessly with any other member of the family, and by applying the first member of the random set to a wall, the engine will display that wall with a randomly tiled assortment of all members of that random set.
There can be up to ten members of a randomly tiling set. The naming convention is that all members of the family have the same name, preceded by -X, where X is a digit from 0 to 9, in ascending order. For example, a six texture random set would be named -0texname.bmp to -5texname.bmp.
Note that by applying the first member (the -0 texture) of the set to a brush, you apply the whole set. If you apply any other member of the set, then the wall appears with only that member and no other
Random textures work in software, but not GL. // проверил работает в GL на Half-life WON.
// Randomly tiling textures in action: https://www.youtube.com/watch?v=NNv17T02WlY
Textures can animate as well. Creating a set of animating textures merely means naming them in the sequence order you wish them to animate in. They animate at a 10hz rate, and this cannot be changed. Name the first texture of the sequence +0texname.bmp, then proceed on up to +9texname.bmp (you can have a maximum of 10 frames of animation.) The textures will loop endlessly during the game.
These are animating textures that have a switchable state: they can either be animating or they can be off. To create a switchable animating set, create a regular animating set as described above, but also add a frame called +Atexname.bmp. This will be the off state for the texture. If a button is textured with the switchable animating set, it changes according to the button state. If a func_wall is textured with a switchable animating set and is the target of a trigger or button, it will change textures upon triggering.
You cannot switch from one animating state to a different animating state. Brushes can start off textured either with the +0texname texture or the +Atexname texture, and will toggle appropriately.
Masked textures are textures that have transparent sections to them, with other sections that are opaque. In Half-Life, most of the ladders, grates, and railings were done with masked textures.
To create a masked texture, paint the texture as you would normally, then paint in the “holes” in the texture by using the color 0 0 255 (pure blue). Any pixel of pure blue will become transparent in the engine. Note that a pixel of color 0 1 255 (amazingly indistinguishably close to pure blue) will not be transparent.
Make them func_wall or func_illusionary entities, give them a rendermode of “solid” and a renderamount of “255”, and they will appear correctly.
The name of a masked texture must start with a {.
Creating good water textures takes experimentation. Liquid textures can be 64x64 or 128x128 in size, and are designated as liquids by placing a “!” before their name, thus !texname.bmp is automatically understood by the engine to mean a water brush.
Fog color is handled by certain color registers in the texture: a color register is a palette location. Color register 0 is the first color of the palette, color register 255 is the last. Fog color is handled by color register 3 in a water texture, and the fog density is handled by color register 4. The density value is drawn from the R value of that register (G and B are ignored), so pure red is the densest fog and black is the least dense fog.
Textures in Half-Life can be specified to throw light, as if they were _light entities. To do so, they must be referenced in a RAD file. A texture thus referenced will always throw light: every example of that texture in the level will throw identical light. Further, this light cannot be turned off, so creating on/off textures for lights that one expects to switch should not be given qrad values: those lights need to be _light entities.
There are three types of RAD file: lights.rad, a global RAD file; designer.rad, a specifiable RAD file; and levelname.rad, a RAD file that is automatically parsed if it exists in the map directory when compiling a map of the same name. The designer.rad supersedes the lights.rad, and the levelname.rad supersedes the designer.rad, in case a texture is specified in multiple files. Qrad will not run if lights.rad is not present in the \valve directory.
A texture can be given an RGB value in the RAD file, or an RGBV value. RGBV values are a little easier to understand sometimes, but you may use either. The amount of light a texture throws off is directly proportional to how much of that texture is visible, so TexlightA on a 4x4 pixel face may throw off very little light, while the same texture on a 128x128 pixel face may flood a room completely with light. It’s best to decide on a light value for a texture and use that texture similarly under all circumstances: that’s the best way to know what things will look like in the engine. A designer usually handles the RAD file for a map, but the texture artist should know how textures get used in this way.
A RAD file is a text file that looks like this:
TexlightA 255 0 0
TexlightB 25500 36000 1000
TexlightC 128 128 0 10000
TexlightD 100 128 225 1000
<…>
The first texture is just RGB values, the second is RGB where the texture needs to be really powerfully bright: perhaps it will always appear on very small faces but be asked to throw a lot of light, like a small halogen bulb. As you can see, with three values like that, it can be tough to know exactly what color light the thing is, because there’s no paint program that will show you what the values 25500 36000 1000 work out to. The better way is to add the V number, so you can more readily understand the exact color (by bringing up a paint program and generating the color you want, and writing down the RGB values). Increasing or decreasing the strength of the light is merely a matter of adjusting the final number up or down. Given an RGBV sequence, the RGB values must be between 0 and 255. The V can be anything. Given just RGB, they can be any value, but again, it’s tougher to predict what the light will be, and tougher to adjust the texture to be brighter or darker while maintaining the same hue.
Half-Life models use a 16-bit color space, even though each individual texture is only 8 bits. You can use any combination of 8 bit textures on your model, even though they have different palettes. This is a useful way to extend the color range of your model; you can put all of your flesh textures (for example) into one map and your clothing textures into another, which will give each texture much finer color resolution than combining all of these areas into one palette. Some hardware accelerator cards (notably older Voodoo based accelerators) impose a slight speed penalty for converting each individual palette to the final 16-bit model. Thus a model containing two maps that have identical palettes is somewhat faster than the same model using two maps with different palettes. Palette index numbers are only important if you are making multiplayer models with team colors (see p. 40). Textures that do not support color remapping have no other limitation on their palettes.
Texturegroups are a mechanism for including multiple alternate textures in a model, similar in many ways to bodygroups. Texture groups are created in the QC file (see the $texturegroup command, p. 47). A texturegroup consists of a series of texture maps that can be applied to the same geometry -- ie maps painted for the same UV coordinates. Only one map is applied in 3dStudio – the others are indicated in the QC file and swapped onto the model at runtime. The QC file defines the texturegroup by finding all of the faces which use the member of the group as their texture. The different maps can be swapped by game code to create an animated texture effect, such as the blinking eye of the Houndeye. You could also use texture groups to create damaged or wounded versions of a texture, or cyclical motions like a rolling tank tread. All of the textures in a texture group will be loaded whenever a model is active (even if not all are visible) so plan for the extra memory required if you intend to use texture groups.
Half-life models do not currently support Mip-mapping, a technique for optimizing the appearance and memory usage of textures at varying distances. Geometry created in WorldCraft, however, does support mip-mapping. It may be difficult to achieve seamless integration between a character and an environment built in WorldCraft because of this disparity, so plan accordingly. If texture sampling artifacts are particularly annoying, you may consider implementing a crude form of mip-mapping using texture groups.
Half Life allows you to remap two color ranges for multiplayer models, allowing you to use the same models and textures for different teams in multiplayer. To support team color remapping, textures must be named “DM_Base.bmp” (only one map with this name is allowed per model, naturally). Remappable textures are 8 bit .bmp files like regular textures. There are two remappable ranges of 32 colors each, from palette index 193 through 224 and 225 through 256. The colors in these ranges can be reset in code, or using the standard selector in the multiplayer options section of the launcher. Remapping affects hues only – the saturation and value of the new color are identical to those of the old color. For this reason pure greyscale, with a saturation of zero, would not remap properly.
The Half-Life engine offers a unique kind of texture that you can use to simulate reflective or shiny surfaces. A Chrome map is similar to what many 3-d packages refer to as environment or reflection maps. Rather than gluing the texture to the vertices of the model, a chrome map moves with viewer’s eye, giving the impression of a reflection that moves across the surface of a stationary object. Unlike a true reflection map, however, the chrome map is never changes its orientation relative to the viewer – thus you cannot walk around a chrome map object and see the “back” reflection. For this reason your chrome maps should be indistinct and suggestive, rather than mirror-like images intended for clear reflections. Chrome maps are best for somewhat irregular surfaces where their limitations can’t be perceived as easily. Flat planes, which the view would expect to have a real mirror-like reflection, will usually break the illusion. All chrome maps must be 64 x 64 pixels. They can use any palette. To indicate to the exporter that a maps is a chrome map, simply include the word “Chrome” in its name, ie, “MyChrome.bmp” When a chrome map is projected onto the model, it is stretched at the top and sides to give a spherical impression. The effect is akin to wrapping a square piece of wrapping paper around an object in a single motion. Chome maps are wrapped around objects by smoothing group. This means that the bounding volume for the spherical projection is based on the bounding box of all the faces in the model which share this chrome map and have a common smoothing group ID applied to them. To create an impression of greater complexity within a reflective object, you can break up the “chrome” area into a number of smoothing groups, each of which will use a unique projection of the chrome and thus will look somewhat different from the others
https://www.the303.org/tutorials/gold_texture_p7.htm (Archived copy)
https://www.the303.org/tutorials/gold_texture_p9.htm (Archived copy)
The env consists of 6 separate textures (each on the side), format: texnameside.tga (24-bit) or texnameside.bmp (8-bit). Where side can be: bk, dn, ft, lf, rt, up
From /modname/gfx/env/
For map it set in worldspawn (entity?) key skyname