Q3Map / Q3Map2 Common Errors
The following is a collection of common error messages that occur when compiling maps and levels with Q3Map or Q3Map2. For a full list click here »
December 31, 2015, 08:24:44 AM by kat
When using q3data.exe
to convert an ASE
model to MD3
) the process fails with an "Too many surfaces in ASE
" error irrespective of the models complexity (created from brush volumes
************ ERROR ****************Cause
Too many surfaces in ASE
The error is caused by the ASE model being converted having more than one texture/shader assigned - a simple cube with different textures on each side for example has 6 different textures/shaders. For an MD3 model to be valid it can only have a single texture/shader assigned per mesh (note that all textures are considered 'shaders', the white outline displayed in Radiants Texture Inspector indicates an explicit shader referencing a particular image for a particular effect).Solution
Depending on the model the following can be used to mitigate or eliminate the problem;
- combine all the images into a single 'map' (may require editing UV's in a 3D application, and/or editing textures in image-editor).
- use a single texture/shader only.
- split the model into a number of independent sections (one mesh per single texture/shader).Additional notes
Care should be taken to ensure models being converted (for use in vanilla idTech 3 powered games - Quake 3, Medal of Honor, Return to Castle Wolfenstein
etc.) are no larger than 1024 units (512 units in the +/- XYZ axes from grid centre) else vertices outside the volume will be folded back into valid space. And should have no more than 1024 vertices (vertex count) - smoothing may increase apparent vertex use due to coincidental pairing to break surface continuity
June 26, 2015, 04:53:46 PM by kat
The Q3Map and Q3Map2 Common Errors list is a collection of Questions & Answers relating to common error messages that occur when compiling brushwork, maps and levels with Q3Map or Q3Map2 for games using idTech 3 (formally the Quake 3 engine).
A partial list was originally posted on the Quake3World
level editing forums before the big f.u.b.a.r. of late 2004 where a good proton of the site was lost, including the Error List. Thankfully a forward thinking chap (thanks scourge34
) has an archived copy saved, which was used as a basis for the below. The Common Errors list should be considered an ongoing active resource that had been updated over a number of years by several helpful and dedicated individuals from the Quake3World community.
The Common Errors list is not
a complete list of all the possible error messages that might crop up, but a comment on the more frequent and common errors and problems
that arise from editing and creating content for games based on the Quake 3 engine.
June 26, 2015, 04:32:53 AM by kat
ProblemERROR: wglMakeCurrent failed.. Error:[n]
is usually associated with having Anti Aliasing enabled
in your graphics card control panel when trying to use the the various flavours of the Radiant editor; QeRadiant
or Doom 3/Quake 4 Radiant
The editor is intolerant of Anti Aliasing
and will often display various forms of the "wglMakeCurrent failed"; error - giving a 'value' that refers to a specific error code reference (a number that refers to a specific error) - when it's run and finds AA enabled.How do I fix ERROR: wglMakeCurrent failed.. Error:[value]Anti Aliasing
will need to be disabled
via the control panel of your graphics card vendors drivers; there will be a setting somewhere in the control panel that deals specifically with Anti Aliasing settings, make sure they're disabled
or set to "Application Decide
" or similar - in effect the GXF card is being told to use whatever AA settings it finds when as game is run; uses 'internal' game specific AA settings - or you can append the following to the editor short cut;
This applies specifically to wglMakeCurrent failed errors
produced when running Doom 3 Radiant
and Quake 4 Radiant
(D3Edit and Q4Edit) and needs to be appended to the editors startup icon as per the "getting the editor to run" tutorial here and here.
If that still doesn't work then remove the two *.cfg files placed the 'base' folder of the game, usually;
This is especially so if copying a previous install of Doom 3 or Quake 4 to another location on your system or if you have updated the graphics card, replacing an old with new card.Other causes of wglMakeCurrent failed errorsMulticore CPUs
and their support is also noted to be causing problems in relation to wglMakeCurrent for all versions of the Radiant family; GTK Radiant, QeRadiant and D3/Q4 Radiant. If you find that you're running dual or multi core CPUs and getting the wgl error then you may need to 'limit' your CPUs per application (application dependant). Tomshardware has a useful article and utility that can be used to this effect which 'fixes' the wgl error in relation to Radiant and multicore CPUs.
- Getting the most from your CPU buck
- THG Task Assignment manager
note: "...drag and drop the THG program to windows startup dir so you don't have to worry about starting it first. You can also .. rightclick on the radiant process in the taskmanager and set cpu affinity there" [Radinator]
June 26, 2015, 04:24:38 AM by kat
What is MAX_MAP_EDGES?
As the error name suggests, this crops up during the compiling of *.maps when they contain more than an allowable limit of EDGES
A polygon (commonly called 'tris' in mapping parlance), as used by game engines, is constructed of three distinct elements;
- Face (the bit you see in game)
- Vertexes (points of reference in 3D space)
- Edges (connections between vertexes)
Each of these 'elements' has a physically hard coded limit in the engine
; a maximum number of allowed 'units' (of that element type) over which the compile process with stop if breached, so in the case of MAX_MAP_EDGES
, the limit of 60,000+ (or thereabouts) has been exceeded resulting in the compiler crashing and spitting out that message.Why does it MAX_MAP_EDGES happen?
It usually happens as a result of badly constructing your map, specifically 'where' and 'how' brushes butt up to each other.
Design note: 'bad' in this context can mean overly detailed brushwork (a map full of fiddly brushwork or detailed architectural features) as opposed to poorly made/constructed brushwork; this error can occur irrespective.
Depending on what compiler options were used, it will create an extra vertex or split where brushes butt up to each other; this is done to prevent a number of related issues ("sparklies") but as an 'optimisation' method it inadvertently causes the max map edges error.How can I fix MAX_MAP_EDGES?
Generally there are two ways to fix it;
Better construction methods
- Better map construction techniques
- Converting brushwork to models
means paying closer attention to how brushes are connected to each other; a general rule of thumb is to try and make things 'even', and 'neat' rather than haphazard based on the assumption that the compiler will 'fix' it. It won't and as shown above, the process will tell you.Converting brushwork to either ASE or LWO models
(if the game allows for it) is the better option as models tend to be 'optimised' already. The kind of things that are generally regarded as good candidates for conversion to models are any elements that get used repeatedly, anything that's overtly detailed (has tiny physical features) or objects that are placed or rotated at odd angles.
June 26, 2015, 04:20:19 AM by kat
During the compiling of a Quake 4 MP map the following error may crop up;
WARNING : idCollisionModeManagerLocal::ChopWindingWithBrush: primitive [n] more than 128 windings
Where [n] is a number associated with the corrupted brush (primitive)Solution
This happens for a similar reason to when the error crops up during Quake 3 map compiles as explained here
As this error can happen with very large brushes try cutting large brushes into small segments.