User:SirYodaJedi/Notepad

From Valve Developer Community
Jump to: navigation, search

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.pngTip: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.pngNote:The alpha channel of DXT5 is great. It's the same as ATI1N, except it's properly supported by Source.
Tip.pngTip: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.pngTip: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.pngTip: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.pngTip: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.
Note.pngNote:MAP and VMF coordinates are pretty easy to convert to Blender Blender coordinates:

This can be useful when manually combining static props with shared materials to reduce draw calls in Source Source (improving performance), which is generally more reliable than automatic Static Prop Combine. I also use this when converting Quake III Quake III patch meshes into prop_statics for porting to Source Source, by putting an info_null where I want the prop_static's relative origin to be.

id Tech 2 id Tech 2

Tip.pngTip: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.

GoldSrc GoldSrc

Tip.pngTip:Half-Life MDLs store a path and filename in their header, but GoldSrc GoldSrc usually doesn't care what's written there; you can rename the model and change what folder it is located in, unlike Source Source. This can be used to add a signature to your model without affecting performance; just compile the model to an existing subfolder with the appropriate name.

Example: $modelname "my_nickname\my_model.mdl"
Using relative paths instead of absolute paths is recommended, for privacy reasons.

Warning.pngWarning:The internally stored filenames are used for reading from textures and animations which are stored in separate MDLs. Make sure to remove $externaltextures and $sequencegroupsize from the QC file, if present (these commands shouldn't be used; they cause more issues than they fix).
Note.pngNote:Source Source mostly doesn't care, except for CS:GO engine branch CS:GO engine branch. Some tools do use the internal names, however. Additionally, Sorse models are compiled directly into the game's models directory instead of the QC file location, so this process is more tedious there.
Warning.pngWarning: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.
Tip.pngIdea:What might be possible to do is to:
  1. Compile the map with the embedded lightmaps.
  2. Decompile the resulting map using BSP tree method.
  3. Extract the textures from the BSP. Change the prefix from __ to !.
  4. Create a WAD with the renamed textures using WadMaker WadMaker (This streamlines the process of fog).
  5. 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.
  6. Open the .MAP in the map editor, and delete everything that isn't the water.
  7. Clean up any faulty geometry, then paste special into your original uncompiled map.
  8. If certain generated textures are identical, change the faces used by them to use the same texture (saving texture usage).
Tip.pngTip: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 MESS have a script that can calculate this automatically.

Source Source

Icon-Important.pngImportant:The barbed wire model in Day of Defeat: Source 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 Day of Defeat 1.3. I'm working on separating it into separate models, but I currently only have the first submodel done.
Note.pngNote: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.pngTip:Since prop_statics are lit per-vertex, subdividing them increases lighting quality. I use less-subdivided versions as $lod models when doing this.
Tip.pngTip:To work around the bug with %tooltexture requiring mipmaps, you can use VIDE 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.pngTip:Press C to toggle Hammer++'s 3-point clipping.