Topic: ERROR: Too many surfaces in ASE

[kat]

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

Code: [Select]

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

[ratty redemption]

are these restrictions only for idtech 3 games like rtcw?

is it still possible to build larger maps in blender for those games, if they are broken into 1024 size segments?

[kat]

The limitations apply to MD3 only. If they are exceeded funny things start to happen depending on the tools used to generate the MD3 data; using Milkshape for example structure outside the 1024 bounds are folded back into valid space, whereas this won't happen using Blender, gmax, 3DS Max - the former (MilkShape) will result in a usable model in terms of it being loadable into game, whereas the latter generally won't, at least not without some error or console warnings.

If models needs to exceed the 1024 bounds it's best to use another format like ASE, or OBJ, FBX (support varies depending in the game and the version of Radiant used). If models need to be large and animated there's generally no option but to use MD3, they will need to be broken down into sensible sections (although this may present synchronisation issues between the different parts).

Building a level in Blender etc., i.e. exporting large level pieces as models rather than 'mapobjects', is subject to the same limitations depending upon the format of choice, ASE can be used without too much issue in most instances (MD3 is impractical for this), the primary concerns are just to make sure the level is sectioned (to account for VIS), and each is centered and properly grid snapped before export.

[ratty redemption]

understood to all that, i think. and it sounds like md3 is best used for just characters?

[kat]

The MD* formats used per idTech generation are generally proprietary and used for 'dynamic' content, i.e. anything that needs to interact with the game environment in some way so not just characters but also mapobjects, pickup items etc.

[ratty redemption]

so animated map objects like say a medieval catapult would use that format? what about doors? or would they be brush based?

[kat]

In theory MD3 can be used in either case, as a stand-along model or the replacement for a brush-based entity like a func_door - the former is loaded into Radiant as a misc_model, the latter using the "model2/[path]" key/value entity pairing.