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 ».
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...Solution
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.Resources
More information on working with models
and volume based level design using a 3D application
can be found on the tutorials page
July 12, 2015, 06:00:42 AM by kat
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.Solution
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;
Increase Model Scale
- uniformly ('globally')- scales the XYZ axes by the same value.
- unevenly ('locally') - scales each XYZ axis independently.
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.
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.Pointfile
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).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.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.
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
], in this instance, the result of multi-core CPU's, as an unresponsive or slow Camera or grid view (may also exhibit corrupt display).Solution
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).
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.Solution
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;
How to determine what's causing sparkliesSimple Gaps
- 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.
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 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.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.