Printable Version of Topic

Posted by: Chapo 19/01/2014 - 20:55:37

STANDARD Textures names:

• Regularly Tiling Textures (a-z, 0-9), are used for regular brushes, and for entity brushes. (Glass textures are regular textures made transparent thru entity flags.) If the textured brush not an entity, then that brush will blocks VIS. This catagory is the majority of all textures.
  (Note: Window/Glass is just a regular texture, in an entity in texture mode, with an FX of 90ish.)
  problems = If over-stretched or under-shrunk a texture may cause compile failure. If clipped, carved, or vertex manipulated the brush involved may cause a compile error due to perpendicular texture.
  
  
• Randomly Tiling Textures (-0 to -9), in concept: if you use -0name texture of a series, any of these -0 to -9 will be substituted in randomly. (Sometimes using ANY of the -#name will start the randomization process.) If it is not an entity, then the brush textured with randomly tiling texture blocks VIS.
  problems = In some mods or video cards random textures may only work correctly in games played in software mode, also textures must match and tile well, and in some mods & video cards if a texture starting with -1 to -9 is used out of the series (instead of one starting with -0) on the map by mapper then that texture is treated like a regular texture, no random substitution happens. So you will have to test how this is working for you in your mod, but also think about what might happen with some player's video card that differs from yours.
  Another possible problem is with non-square faces - each face may get a different texture, and since they are not square the textures may not line up as they should. Furthermore, if the faces involved are small enough, even if square they may have problems: one face may get a corner of one texture, and another a different corner of another texture so that they no longer seem related.
  For example: a texture with a door and window and gutter, one face gets a piece of door texture, one gets the wall, one gets a piece of pipe, and one a piece of window - but you never see the whole combined. Because of its problems, many top mappers just do not use random textures, and prefer to hand place every texture to make sure it will work right.
  
  
• Regular Animating (+0 to +9), if +0texturename is used on a brush, then the animated series up to +9 will continuously "play" on the brush. Waterfall is an animated texture that should be tied to func water. If the regular animating textured brush not tied to an entity, it will block VIS, usually. (You can also make an animating texture with +A to +J prefixes instead of +0 to +9.)
  problems = if +1 to +9 is used on a brush, then sometimes there is no animation, only that texture is shown....and sometimes there is. Using a texture number out of sequence on a brush such as a +3name may cause a problem, use the +0 or rename the texture you want without the prefix. textures must combine well. The prefixes MUST start with +0 (or +A) and must NOT skip a number/letter in the sequence, although you do not have to go to the highest number. And finally using animated textures may slightly increase some client lag, and certainly loading a whole series into memory will increase your texture memory size/Max_MipTex.
  
  
• Switchable Animating (+A), +Atexturename is like regular animating above, except there is one extra texture in the series starting with the symbol +A instead of a number. If the brush involved is made a named func wall or other entity, then a trigger can target it and switch from the +0 to +9 animation to the "stopped" +A texture. (Reportedly you can also switch between series, with both +0texturename to +9texturename and +Atexturename to +Jtexturename so that you can switch between both animated series running. You can also make a +Atexturename to +Jtexturename with one extra +0texturename texture for the stop.)
  problems = as regular animation. Also MUST be an entity to be able to switch, therefore it never blocks VIS.
  
  
• Rad/Light Textures (~), ~texturename may give off light, but ONLY if listed with correct data in the lights.rad file or mapname.rad file. A light textured brush can be made switchable LOOKING using a +A prefixed texture name instead of ~, as the same way as Switchable Animating textures above. (Most other textures, like animated or regular, can also give off light if listed in lights.rad file. The ~ really does nothing, it is just a mappers convenience.) Note that the light given off can only be made switchable by a special compiling code using Merle's compiler, or by using a non light giving texture and putting a light entity in front of it.
  problems = bad compiles stop lights from working. too many different light types (8) shining on any brush may cause compile crash. But 8 *identical* lights do not cause a problem. Memory used is the square of the number of lights on a brush face, 4 light types = 16 times the memory usage of 1 light type on a brush face - for EACH brush. If +Aname is used for a switchable light, the the light in the room may NOT change with the switched texture.
  
  
• Masked/Transparent Textures ({), {texturename is used for invisible, or partially transparent textures, like ladders. It needs to be used with an entity like func_wall or func_illusionary with solid mode and fx set at 255. Texture for transparent part must be 0 0 255 blue, in wad editor Wally palette position #255. A brush with Masked/Transparent Textures must be tied to an entity, cannot block VIS.
  problems = this texture is often made incorrectly, or set up incorrectly with the entity - be careful! Even totally invisible textures still make wpolys. ALL sides of a brush should be the same texture. This texture also causes an extra pass on many video cards, which may result in some small lag to some client player's computers.
  
  
• Liquid/Water Procedural (!), if this texture covers a brush then the engine assumes it is liquid and treats it like such. If you would like it see-thru, then you have to tie to entity func_water and set the flags. A brush with water texture does not block VIS in any way.
  problems = ALL sides of a brush must be the same water texture. Also water tends to be visible EVERYWHERE in a map through walls, which can cause lag. (Solution?: use a func_illusionary instead of func_water, then un-select smart edit. In the key of skin, add the value "-3". Now it should sound like water, and if you jump it will not hurt, just like water. Possible problem: the water_surface may only be seen by one side top.) This texture also causes an extra pass on many video cards, which may result in some small lag to some client player's computers.
  
  
• Contents_Current (!cur), a variant of Liquid/Water Procedural, current textures basically make water with built-in a very FAST current in the expected direction. This affects not just players, but even spectators.
  Reserved names are: !cur_90, !cur_0, !cur_270, !cur_180, !cur_up, or !cur_dwn and have the effect of a current 90 degrees/0/270/180 or a push up or down (respectively).
  problems = ALL sides of a brush must be the same water texture. Also water tends to be visible EVERYWHERE in a map through walls, which can cause lag. In addition, if used UP a player may walk or bounce on water....This texture also causes an extra pass on many video cards, which may result in some small lag to some client player's computers.
  
  
• AAATRIGGER (AAATRIGGER), used to help mappers visualize invisible brush entities, like triggers. usually invisible, but should NOT be used as a regular texture - it causes a compile problems and lighting problems. A brush with AAATRIGGER must be an entity so it does not block VIS.
  problems = if visible causes compile problems, and causes lighting problems along with scrolls & resizes in map, and can make HL & mods crash.
  
  
• CLIP (CLIP), used to block player movement. A brush covered in CLIP does not stop grenades or gunfire, it is invisible, and it does not block VIS.
  problems = misuse can be irritating, and ALL sides of a brush must be CLIP, no mixing textures allowed.
  
  
• HINT/SKIP (HINT/SKIP), a pair of textures of limited use, to split VIS leaf/portals so that line-of-sight problems & r_speeds lag can be reduced in some situations. A brush covered with HINT/SKIP is invisible, transparent, does not make wpolys, does not affect players, & does not block VIS directly.
  problems = hard to understand usage, and misuse may increase r_speeds; also ALL sides of a brush must be either HINT or SKIP, no other textures mixing allowed. Also HINT/SKIP cut all brushes in their portal, and HINT keeps on cutting across the BSP level until it reaches a new portal.
  
  
• ORIGIN (ORIGIN), used to denote the axis of swinging platforms, doors, trains, vehicles, and pendulums. A brush covered with ORIGIN must be part of an entity. A brush covered with ORIGIN is invisible, does not block VIS.
  problems = if alone in map, visible, or if more than one ORIGIN used per entity then it causes compile crash; ALL sides of a brush must be ORIGIN, no mixing textures allowed.
  
  
• Scroll (SCROLL), used for scrolling signs or conveyor belts. Reportedly a brush covered with SCROLL may be switchable with a +A texture like animated, although I have never been successful. A brush covered with SCROLL must be an entity, does not block VIS.
  problems = if custom, the texture may require square size, such as 128x128; SCROLL texture and conveyor entitys are difficult to work with.
  
  
• SKY (SKY), used for sky environments. A brush covered with SKY can give off light when a light environment entity is used and ALL sides of the brush are covered with SKY. SKY brushes do not create wpolys, so SKY cause less lag than regular {invisible textured brush faces, although sometimes there is a drop in fps. (NULL texture is the only one that totally drops faces, see below.) A brush covered with SKY can block VIS, if there is no way to "peek around/over" it and if you compile with VIS -full.
  problems = if zoner's compiling tools are not used, then mapper must block off sky with CLIP brushes, or players can "Get out of map"...it is swimable as water if a player gets into it, but black colored. A brush covered with SKY are transparent within a map, if you can see around it. A brush covered with SKY does not create wpolys, it is rendered in a manner similar to sprites; and so like sprites one can only measure the lag caused by the fps(frames per second). A SKY texture will not give off light if one side of the brush is not SKY, and bad compiles also stop SKY light from working.
  
  
• Translucent (@ or TRANSLUCENT), this is a rarely used texture not listed in the sdk. It is a regular texture always without any clip, so you can walk thru a brush covered with it! If a brush covered with TRANSLUCENT is not an entity, then it blocks VIS! Good uses are for walkthru bead doors, curtains, curtain of falling dust, a cloud, or very tall elephant grass.
  problems = must be very thin, or may lead to hall-of-mirrors problems, somewhat experimental and TRANSLUCENT may not work with all mods.
  
  
• Decals (various), a decal is a greyscale texture from the decals.wad, and is placed with a decal entity. It is scaled(sized) and oriented according to the texture of the face it is on. It does not count against w_polys/r_speeds, but is treated like a sprite for lag. You can add rendermodes to the decal entity, which allows a different monochrome color other than grey.
  problems = many players have decals turned off to reduce lag, so they will not see your decal in the level - so do not make it vital. Before VHE/WC3.4, decals were hard to move or remove. Since decals are tied in size and orientation to the texture under them, it limits your ability to manipulate the texture.

EXPERIMENTAL & non standard Textures:

• NULL (NULL), developed by Merle in Valve ERC forums, to be used like CAULK in Quake, or SKIP in HL - except it can be mixed on a brush with other textures. NULL will remove that covered brush face from the map. A brush covered with NULL will not block VIS. NULL requires a custom reworking of Zoner's Compiling tools that Merle made, available at: HL SDK forum.
  problems = hall-of-mirrors problems, and will probably be many others....
  
  
• BEVEL (BEVEL), developed by Cagey in Natural Selection forums, brush faces with this texture will not expand during the clipnode/hull part of CSG compiling. This can be used to clarify clipping so that "invisible walls" that sometimes occur will not happen. For this texture to work, you would need Cagey's improved clipping & plane code in your compiler.
  problems = misused, you can mess up the hulls, so that players move through & get stuck in walls & floors.
  
  
• NOBUILD (NOBUILD), developed by the Natural Selection mod, brush faces with this texture will not allow NS structures to be built on them.
  problems = Only works with NS.
  
  
• seethrough (seethrough), developed by the Natural Selection mod, brush faces with this texture will not visible/will be see though to NS commanders, and will not cause hall of errors problems like NULL. This is for the commander mode in NS only.
  problems = looks bad to players when seen. Only works with NS.
  
  
• VIS one way (), proposed in Valve ERC forums, but not under development. A brush covered with VIS one way would block VIS line-of-sight in one direction, but not the other - sort of a one way glass except for only VIS. VIS one way would be of the same type invisible order as HINT/SKIP and CLIP.
  problems = will probably be many....

SOUNDS for Textures:

• Texture sounds (various textures), the materials.txt file lists the textures that have special sounds associated with them when shot or walked on. It is best NOT to change this file, since everyone has the same standard file, but to change instead the name of your texture to match one of the names in the materials.txt file.
  problems = check there is not another texture of the same name in one of the WADs you are using in WC.
  You may also wish to learn about the buggy env_sound entity.

ANIMATIONS for Textures:

• Sprite/model animations for Textures (various textures), in new HL mapping technology, it has been reported that for some mods(DoD?), some textures can be tied to sprite/model gib animations when shot at, besides the usual decal action or sound effects. For example: a sandbag giving a dust puff when hit, or metal/stone texture giving a spark when shot.
  problems = unknown.

Page © http://www.slackiller.com/tommy14/hltexture.htm copied on 17b for "memory" purpose.