idTech editing hints & tips

Below is a list of essential editing hints and tips for idTech4 powered games (formally known as the 'Doom 3' engine); currently Quake Wars, Quake 4, Prey and Doom 3, but future idTech games may be support. For full list click here ».

*.bsp export for 3DS Max

July 12, 2015, 05:43:45 PM by kat
Although 'volume' based levels can be made using 3DS Max, because the eventual format used needs to be specially compiled, it's not possible to export content from Max directly to *.bsp. BSP is a data structure rather than just a file-dump. This means the contents of a working file are analysed and broken down into a series of structures that are optimised in a way that removes some material. This isn't possible through a simple 'export' mechanism, so content has to exported to another format. However, it's not possible to simply export the contents of a Scene to a single model because the way those are handled in game would result in an unusable level (models are processes and culled based on bounding-box not surfaces). That being said models can still be used...

The general solution to exporting volume based content from 3DS Max is essentially two-fold;
  • use a *.map export script.
  • section the level and export a series of models.
If a *.map export script exists divide the level into simple 'convex' shapes and complex molded structures, i.e. flat walls, floors and other architectural features that describe the level versus statues, shaped fittings and features. Export the former group to *.map and the latter to a supported mesh format such as *.ase, *.obj etc. Both can then be opened in a level-editor like GtkRadiant and once rebuilt as the content was originally in Max, can then be properly compiled to BSP using a MAP2BSP compiler (dmap, q3map2 etc.).

An alternative to the above is to export content from Max to *.3ds which can then be opened and processed in Gmax before being compiled using the BSP compiler included with the Tempest Gamepack. This approach woul typically mean rebuilding certain elements of the level and retagging content so the Tempest gamepack knows what to do with certain structures.

More information on working with models and volume based level design using a 3D application can be found on the tutorials page.

Scale models (mapobjects) in GtkRadiant

July 12, 2015, 06:00:42 AM by kat
Using different entity key/values to resize models

Models and other mesh based misc_model entities are fixed-sized items that once imported or loaded into GtkRadiant or other *.map editor for use, cannot ordinarily be altered. This is a disadvantage when their size needs to be changed as this would normally require the model be opened in the program used to created it, adjusted and then re-exported to the new size. Where the same model is used in multiple locations, each at different sizing, this can be an issue - a unique asset for each instance of the same mesh.

To solve this two different key/value properties sets (pairings) can be assigned to a given instance of the object to change its size in one of two ways;
  • uniformly ('globally')- scales the XYZ axes by the same value.
  • unevenly ('locally') - scales each XYZ axis independently.
Increase Model Scale
To scale models in Radiant do the following;
  • Select the model entity and access the "Entity Inspector" ("N").
  • To scale on all axes;
    - Key "modelscale".
    - Value "2".
  • To scale individual axes;
    - Key "modelscale_vec".
    - Value "4 1 2".
In the example above, "modelscale/2" re-sizes the mesh so its twice the default size. Using "modelscale_vec/4 1 2" scales the "Z" axis twice as large (up/down), the "X" axis four times as large (left/right), leaving the "Y" axis at its default (front/back).

Reduce Model Scale
To reduce the size of models decimal fractions need to be used - where "1.0" equals the default size "0.75" is three quarters that, "0.5" is half sized and so on, along all or specific axes.

Design note: although GtkRadiant can be used to edit content for idTech 4 powered games, changing the size of models using the above key/values pairs only works in the editor, they do not carry over into the game because the compiler doesn't understand the parameters. This means that most content that needs to be variable sizes will have to be made 'uniquely' for purpose.

Error: map compile "Leak" but there is no 'leak'

July 11, 2015, 07:57:03 PM by kat
When compiling a level for idTech an error keeps appearing saying there's a "Leak" where there isn't one.

Open the level in GtkRadiant or other *.map editor and inspect the brushwork for obvious cracks, splits, gaps or holes. For ease of use doing this, during compile a "Pointfile" is generate outlining the path to the 'leak' from the point of view of the entity that was being processed at the time the leak was discovered. This is displayed in the editors Camera view as a thick red line. To load it; after compile from Radiants "File" menu click "Pointfile..." (e.g. "File Pointfile..."). The red 'trace' line will appear. Simply follow this to discover the exit point (note: the line isn't always direct, more often its quite a meander around the level as a result of areas being open or closed to each other).

Pointfile showing path to a leak

Non-solid volumes
If that produces no errors then check to see if any of the levels structure volumes have not inadvertently been assigned a shader with a 'non-solid' surface property, or have not been converted to "Detail", both are considered to be non-structural in that they do not seal the internal workings of a level from the Void, thus they cause leaks.

Buried Entity
Alternatively, although the following may not actually produce a "Leak" error, they do cause "Leak" issues for other aspects of the compilation process, especially where AI are used; check to make sure there are no game entities, models or brush-based entities buried in structural brush volumes. Check light entities, AI spawn markers, target_[names] and any other entities placed around the map. Note: depending on the entity type, differing amounts of burial may cause a leak; a model (mesh) needs to be buried beyond its origin point (the cross-hair marking its point of rotation/origination), whereas the base of an info_player_start being buried may be sufficient.

Game entity buried in brush volume

Duplicate Plane
Finally if none of the above are an issue its likely the level contains a broken brush volumes which, whilst it continues to be visible, is broken to the compiler causing a gap and leak to occur. To fix these types of issue use brush cleanup, which highlight for removal any defunct brush volume. To do this from Radiants "Plugins" menu select "bobToolz Brush Cleanup". If this still doesn't fix the problem start a new level and then import the old one - make sure to "Import" rather than "Open" the map.

wglMakeCurrent: setting Processor Affinity

July 10, 2015, 04:23:03 AM by kat
Depending on the version of GtkRadiant, problems may occur when running the editor on Windows based computer with multi-core CPU's. Usually the issues tends to manifest as a "wglMakeCurrent" error of some kind [1] [2] [3], in this instance, the result of multi-core CPU's, as an unresponsive or slow Camera or grid view (may also exhibit corrupt display).

To fix the error, assuming it's not attributed to one of the other reasons wglMakeCurrent issues happen, is to set the number of CPU cores that can be used when running GtkRadiant, essentially throttling the system. To do this start Radiant and once open right-click the "Task Bar" and click "Start Task Manager". A window will appear, "Windows Task Manager", with the "Processes" page/tab active. Find the "GtkRadiant [n]" entry and right-click, select "Set Affinity...". Another panel will open with a list of 'cores' available. Deselect one or more (depending on the number of cores available), click "OK" to set, then close "Windows Task Manager". Once done continue editing as normal.

This may need to be done each time Radiant is started as the setting generally only apply to the application process when its active and in memory. CPU Affinity can also be set from Radiant start-up screen or once the application has fully loaded after the game environment has been set (after the game selection screen).

What are 'Sparklies' and why do they happen

July 07, 2015, 06:13:46 PM by kat
When running through a level various spots seems to 'sparkle' or 'twinkle' as the camera moves past or around them. Often there are no obvious reasons for their appearance as the area looks perfectly fine.

The white lines that can sometimes appear are commonly called "sparklies" by level designers. They are caused by almost imperceptible tiny gaps or cracks in surfaces, typically where polygons touch. The 'sparkle' aspect of the problem is essentially just the 'Void' outside the structure shining through; because the Void is often a lighter colour, and due to the way rendering shuffles pixels around as the camera moves, the net effect is a faux 'twinkle' - the effect is not specifically related to 'illumination' (although it does happen if the hairlines cracks expose lights or other effects).

There are number of reasons why 'sparklies' happen;
  • An unintentional oversight by the level designer where a gap or misalignment has been left between brush volumes - typically the result of manipulating brush volumes of too small a grid-scale, or the result of misjudging a two or three-point clip operation.
  • A "rounding off" error caused by an incomplete math calculations of coordinate data related to the position of vertex points in space; minute discrepancies co-locating vertices can extrapolate out to result in gaps and hairline cracks.
  • A 'bad' or 'corrupted' brush volume that's the result of manipulating a brush too much, or doing so at odd angles of orientation (making a terrain for example), or from cutting or otherwise clipping a volume poorly. All can cause brush volume data to be corrupt leading to miscalculations at compile.
  • A gap caused by improper brush optimisation when Patch Mesh objects are used; essentially brush volumes should be split where they meet patch mesh object so BSP can properly structure the layout of polygons in a given area. Where this is not done the compiler makes a 'best guess' and cuts, leading to gaps and cracks when this is misjudged.
How to determine what's causing sparklies

Simple Gaps
Generally speaking because the error tends to be of a fixed location - sparklies always tend to appear in the same place - it should be possible to fix the problem by opening the level in Radiant or other editor and thoroughly inspecting the offending area to see if an actual gaps exists. If they do delete the offending volumes and reconstruct before re-compiling the level.

Duplicate Planes/Bad Brush
If there are no gaps then it's likely the result of a rounding off error, a bad or corrupt brush volume, in which case run bobToolz "Brush Cleanup" ("Plugins bobToolz Brush Cleanup") to remove the malformed volume or data (this may remove the actual brush from the level). In some instances this won't fix the problem so the area will need to be deleted and rebuilt.

Patch Mesh Sparklies (T-Junctions)
If the appearance of 'sparklies' are near a curve or other patch mesh structure it means the point where brush and patch meet[1] needs to be better optimised to prevent errant splits (or T-Junctions). In Radiant inspect the area and cut the brush so its the same size and angle relative to the patch mesh and move or cut brush structures to match edge-for-edge or more typically edge-to-corner[2].

Graphics Card Drivers
If none of the above fixes the problem then it means the appearance of sparklies could be down to a graphics card rendering error. Although this is rare for modern cards, some older models for which drivers are no longer available can still exhibit the problem. Sparklies can also occur as a result of over-clocking or over-heating hardware.
KatsBits Web
Search KatsBits using StartPage
  • Visit KatsBits Store today
  • Blender Art Magazine