View source for User:SirYodaJedi/Notepad

__FORCETOC__
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 [[User talk:SirYodaJedi|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.}}
}}
{{note|[[MAP]] and [[VMF]] coordinates are pretty easy to convert to {{blender|2}} coordinates:
{{table|
{{tr| {{th|[[MAP]]/[[VMF]]}} {{th|{{blender|2}}}} }}
{{tr| {{td|X}} {{td|-Y}} }}
{{tr| {{td|Y}} {{td|-X}} }}
{{tr| {{td|Z}} {{td|-Z}} }}
}}
{{todo|Actually, the mapping is 1:1; the difference is between MDLs and MAP/VMF, which is a simple 270° rotation around the yaw. Yui plz fix?}}}
This can be useful when manually combining [[prop_static|static props]] with shared materials to reduce draw calls in {{src|2}} (improving performance), which is generally more reliable than automatic [[Static Prop Combine]]. I also use this when converting {{quake3|2}} patch meshes into prop_statics for porting to {{src|2}}, by putting an info_null where I want the prop_static's relative origin to be.
}}

== {{idtech2|4}} ==
{{tip|For [[VHLT]]-style autophong in [[ericw-tools]], add the following [[KV]]s to {{ent|Worldspawn}}:
{{codeblock|<nowiki>"_phong" "1"
"_phong_angle" "44"</nowiki>}}
The angle threshold might require the latest dev builds.}}

== {{idtech3|4}} ==
Since the Quake 3 page is going to be deleted (being irrelevant to wiki topic), here's a few things I might find useful if I ever get into IdTech 3 mapping
* [https://web.archive.org/web/20220828203135/http://www.leveldk.co.uk/tutindex.htm Andrew 'dONKEY' Dunn's tutorials (Archived)] - An extensive series of tutorials on Quake III mapping from back in the day 
* [https://www.quake3world.com/forum/viewtopic.php?f=7&t=7760 Reply to forum post "How to paint your nick?" CrinklyArse on Quake3World.com]:
{{quote|sign=CrinklyArse|source=[https://www.quake3world.com/forum/viewtopic.php?f=7&t=7760 Quake3World.com]|text={{collapse|title='''How can I change my name color?'''|1=
When typing your name into the console, enter a caret: ^ (by holding down the SHIFT key, and pressing number 6 on the top row) and then a number between 1 and 7. The caret will disappear, and now all the text you type will be in a different colour. You can switch colors as often as you like. When you press return, the name is saved into your Quake 3 config so u only have to type it once. 

The color codes are as follows<br>
^1 = Red<br>
^2 = Green<br>
^3 = Yellow<br>
^4 = Blue<br>
^5 = Light Blue<br>
^6 = Magenta<br>
^7 = White 

The same color codes can also be used to color chat text 

'''How can I make my text blink or fade?'''

These are features of OSP. OSP knows an additional number of ^ controls next to the standard colors. Here's a list of the OSP controls: 

^B or ^b = this makes your text blink<br>
^F = only makes the text visible the 1st half of a second<br>
^f = only makes the text visible the 2nd half of a second<br>
^X[rrggbb] = Gives the text a colored shadow. Replace [rrggbb] with the hex value of the desired color. Example: ^XFF0000 is red and ^X777777 is some kind of grey.<br>
^N = This resets all the ^ controls, making the text behind it look like normal again<br>
{{nbsp}}<!--fixes some alignment stuff-->}} }}
{{tip|Use {{code|Curve > Re-disperse > Rows}} after creating a regular (not exact) cone in Jack to make it less bullet shaped, like the exact cone, while keeping the benefits of the non-exact version having better UVs.}}

== {{GoldSrc|4}} ==
{{tip|[[Half-Life MDL]]s store a path and filename in their header, but {{goldsrc|4}} usually doesn't care what's written there; you can rename the model and change what folder it is located in, unlike {{src|4}}. 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.<br>
Example: {{code|[[$modelname]] "my_nickname\my_model.mdl"}}<br>
Using relative paths instead of absolute paths is recommended, for privacy reasons.
{{warning|The internally stored filenames ''are'' used for reading from textures and animations which are stored in separate MDLs. Make sure to remove {{ent|$externaltextures}} and {{ent|$sequencegroupsize}} from the QC file, if present (these commands shouldn't be used; they cause more issues than they fix).}}
{{note|{{src|4}} mostly doesn't care, except for {{csgobranch|4}}. Some tools do use the internal names, however. Additionally, [[Source 1 MDL|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|Shower thought: Ordinarily, {{cmd|zhlt_embedlightmap}} breaks water textures, because it results in textures that start with {{code|__}}, but water textures need to start with {{code|!}}. 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.
{{modernIdea|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 {{code|__}} to {{code|!}}.
# Create a WAD with the renamed textures using {{wadmaker|4.1}} (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 {{ent|func_conveyor}} by adjusting the {{code|rendercolor}} of the brush entity. The303 has [https://the303.org/tutorials/gold_texture_p7.htm 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. {{code|1=speed = (( G * 256 ) + B ) / 16 }}
The latest versions of {{mess|4}} have a script that can calculate this automatically.
}}

== {{src|4}} ==
{{modernImportant|The barbed wire model in {{dods|4}} shouldn't be used as a {{ent|prop_static}}, as it has multiple [[submodel]]s (resulting in a major VRAD shadow bug) and lacks a collision mesh, both issues stemming from it being a port from {{dod|4|nt=1}}. 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 {{ent|prop_static}}s are lit per-vertex, subdividing them increases lighting quality. I use less-subdivided versions as {{ent|$lod}} models when doing this.}}
{{tip|To work around the bug with {{ent|%tooltexture}} requiring mipmaps, you can use {{vide|4}} 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 [[BSPZIP#Compression|compressed BSP]].}}
{{tip|Press {{key|C}} to toggle {{hammer++}}'s 3-point clipping.}}

; 2x MSAA
{| class="wikitable"
|-
! Linear
| 0.00 || 0.5 || 1.00
|-
! RGB
| 0 || 128 || 255
|-
|}

; 4x

{| class="wikitable"
|-
! Linear
| 0.00 || ??? || ??? || ??? || 1.00
|-
! RGB
| 0 || ??? || ??? || ??? || 255
|-
|}

; 8x MSAA
{| class="wikitable"
|-
! Linear
| 0.00 || 0.06 || 0.18 || 0.31 || 0.43 || 0.56 || 0.68 || 0.81 || 0.98 || 1.00
|-
! RGB
| 0 || 15 || 46 || 80 || 110 || 143 || 174 || 207 || 238 || 255
|-
|}
{{tip|Regarding [[lightmaps]]:
* Player-navigable space should use luxel scale 8, like Quake II 2023 (lower than this can frequently result in lightmap seams due to subdivision)
** If it's a huge displacement that Hammer won't let be luxel scale 8, then luxel scale 12 also works (avoid odd luxel scale values, though)
* Surfaces that the player can't see up-close should be luxel scale 16 or higher (more than 64 is generally overkill)
* Select surfaces near dense shadow casters (particularly grates and foliage) can be luxel scale 4 or lower if deemed artistically appropriate (but be careful to not go below that too much, or 32-bit vrad may hang)
* If you need higher resolution lightmaps than luxel scale 4 provides, you probably should be using models. Prop_static lightmaps are finicky to set up, and only work natively in 2013 MP and Gmod, but they can be a *lot* more dense than brushes/disps.

also, if you're on 2013 MP, the extra file size is negligible because you can compress the BSP with BSPZip.
}}