Various unsorted notes. Feel free to copy this information elsewhere, but please don't remove or edit any information. If something is inaccurate, please post on my talk page or ping/PM me on Discord, so that I notice promptly.
General
Tip:If you want your level to be believably structured, don't greybox! Instead, use simple brushwork with simple low-quality placeholder textures that get the point across. Have textures for different surface types (grass, dirt, concrete, brick, sand, computer, etc.), but don't spend too much time making the placeholders look pretty. This ensures that different areas of your map are unique, without hassling over fine-grain specifics. It also allows for a better idea of how a map will be lit, as it provides a better indication of what areas are what general colors.
Note:The alpha channel of DXT5 is great. It's the same as ATI1N, except it's properly supported by Source.
Tip:If a texture is a single color with a gradient alpha channel, then DXT5 will almost always be sufficient, as the alpha channel of DXT5 has 4 explicit values and 4 interpolated values for each 4x4 texel block. This 8 total values for a 16 texel block; the RGB data only has 4 total values per block (three if DXT1 in a block with alpha).
Yes, you could theoretically use an A8 texture and use material coloring for the same VRAM footprint, but A8 is a pretty poorly supported format.
Tip:Don't use DXT3; it takes up the same amount of space as DXT5, but only can have 16 total alpha values for the entire texture (which are the same values for every texture). Re-saving the alpha of a DXT3 texture as DXT5 will actually result in more accurate mipmaps, due to allowing interpolation to take place in 8-bit space.
Tip:Normal maps can use ATI2N or DXT5 to get higher-quality compression than DXT1 at only double the size (both DXT5 and ATI2N have the same VRAM footprint). In fact, ATI2N normal maps can be higher quality than BC7 normal maps. ATI2N works because blue channel can be recreated from the red and green channels in the shader (Source actually does this for ATI2N automatically). For DXT5, the red channel can be moved to the alpha channel (the green channel of DXTn has a bit more precision than the red or blue channels, literally).
Tip:Even if you don't need alpha for a specific texture, you can still use DXT5 with an alpha channel instead of DXT1 to take advantage of the alpha channel for a greyscale mask of some sort. This will take up the same amount of VRAM as if you used a separate DXT1 texture for the mask, except it is higher quality (and doesn't bias green) and doesn't require telling the shaders to treat ATI1N as greyscale instead of VirtualBoyScale.
Tip:For VHLT-style autophong in ericw-tools, add the following KVs to Worldspawn:
"_phong" "1"
"_phong_angle" "44"
The angle threshold might require the latest dev builds.
Warning:Shower thought: Ordinarily, zhlt_embedlightmap breaks water textures, because it results in textures that start with __, but water textures need to start with !. This results in the texture no longer being animated, waves no longer appearing, and backface culling being enabled. Additionally, the brush face is no longer subdivided every 64 units, which is required for waves to work correctly.
Idea:What might be possible to do is to:
- Compile the map with the embedded lightmaps.
- Decompile the resulting map using BSP tree method.
- Extract the textures from the BSP. Change the prefix from
__ to !.
- Create a WAD with the renamed textures using
WadMaker (This streamlines the process of fog).
- Open the decompiled MAP in a text editor, and do a find-and-replace edit to reflect the changed names of the func_water textures. Save the file.
- Open the .MAP in the map editor, and delete everything that isn't the water.
- Clean up any faulty geometry, then paste special into your original uncompiled map.
- If certain generated textures are identical, change the faces used by them to use the same texture (saving texture usage).
Tip:Scrolling textures can be used on entities other than func_conveyor by adjusting the rendercolor of the brush entity. The303 has a table of a bunch of common speeds, but for calculating manually:
- R: Sign. 0 is positive, and 1 is negative.
- GB: 16-bit unsigned integer.
speed = (( G * 256 ) + B ) / 16
The latest versions of
MESS have a script that can calculate this automatically.
Important:The barbed wire model in
Day of Defeat: Source shouldn't be used as a prop_static, as it has multiple submodels (resulting in a major VRAD shadow bug) and lacks a collision mesh, both issues stemming from it being a port from
Day of Defeat 1.3. I'm working on separating it into separate models, but I currently only have the first submodel done.
Note:I'm also going to port a bunch of other DoD 1.3 models, since they really deserve proper care and attention to be as high quality and faithful as possible. This includes splitting up submodels, creating collision meshes, and redoing UVs so that the textures can be padded to powers of two instead of upscaled (as upscaling would result in the textures being blurrier). Select models (such as the barbed wire) will also get variants which have had faces carefully subdivided in order to increase the quality of per-vertex static prop lighting.
Tip:Since prop_statics are lit per-vertex, subdividing them increases lighting quality. I use less-subdivided versions as $lod models when doing this.
Tip:To work around the bug with %tooltexture requiring mipmaps, you can use
VIDE to replace all the mips (and the thumbnail) with a pure black image, which improves how well the VTF will be compressed when packed into a ZIP or compressed BSP.
Tip:Press C to toggle
's 3-point clipping.