User:SirYodaJedi/Notepad
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
MAP/VMF | Blender |
---|---|
X | -Y |
Y | -X |
Z | -Z |
This can be useful when manually combining static props with shared materials to reduce draw calls in Source (improving performance), which is generally more reliable than automatic Static Prop Combine. I also use this when converting Quake III patch meshes into prop_statics for porting to Source, by putting an info_null where I want the prop_static's relative origin to be.
id Tech 2
id Tech 3
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
- Andrew 'dONKEY' Dunn's tutorials (Archived) - An extensive series of tutorials on Quake III mapping from back in the day
- Reply to forum post "How to paint your nick?" CrinklyArse on Quake3World.com:
How can I change my name color? |
---|
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 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 |
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
Example: $modelname "my_nickname\my_model.mdl"
Using relative paths instead of absolute paths is recommended, for privacy reasons.
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.
- 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).
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.
Source
- 2x MSAA
Linear | 0.00 | 0.5 | 1.00 |
---|---|---|---|
RGB | 0 | 128 | 255 |
- 4x
Linear | 0.00 | ??? | ??? | ??? | 1.00 |
---|---|---|---|---|---|
RGB | 0 | ??? | ??? | ??? | 255 |
- 8x MSAA
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 |
- 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.