Q3Map / Q3Map2 Common Errors

Problem
When using q3data.exe to convert an ASE model to MD3 (ase2md3) the process fails with an "Too many surfaces in ASE" error irrespective of the models complexity (created from brush volumes).

************ ERROR ****************
Too many surfaces in ASE
Cause
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.

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.

Problem
ERROR: 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, GtkRadiant 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;

+r_multiSamples 0
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;

Quake4Config.cfg
editor.cfg
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 errors
Multicore 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]

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 map construction techniques
• Converting brushwork to models

Better construction methods 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.

Problem
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.