Starting to Model for TDM

Modeling Software

Most modelers on the team use Lightwave or Blender. Anything that can save in either .lwo (prefered) or .ase format is acceptable, however. There is an ASE exporter available for Blender at the Doom3World forums, otherwise ask somebody in the Dark Mod Forums. 3dsMax can be used to model and import/export .ase files.

Making the Model

You will need to make, for each individual object:

• a highpoly model. There's no poly limit to this--make it as detailed as possible.
• a lowpoly version of the same size and basic shape (see dimensions below).

The detailed version is used, by Doom 3, or another tool such as ORB or xnormals, to generate a normalmap with all the details on it. This normalmap is then used with the lowpoly model to fake higher detail. See Renderbump for more information on using D3 to generate normalmaps.

• Lightwave: Your model needs to be tripled before being used in game (SHIFT+T), or D3 will spit out tons of warning messages.
• Blender: The ASE exporter will automatically convert all your faces to triangles.
• 3dsMax: turn to poly, max sides 3, turn to edit mesh before export.

Model and Texture Dimensions

Aim for approximately 5000 polys for significant AI, and less than 500 for most common objects. Generally, objects that might only be used once in a scene (like a well) can have higher polys, but objects that might appear many times (like lights or chairs) should have less than 500. Round objects (vases, plates, etc) should have a minimum of 8-10 sides (depending on the size of the object) to appear fairly smooth. Less important parts of an object (like the legs of a stool) can have fewer sides to keep polys down.

About 200-250 polys is the average for most smallish size props, like weapons or lights. Even our wide bookshelf model is less than 250 polys, so it's not always dependent on size.

If you can do it for less, that's great, but you don't generally need to sacrifice detail just to get a model less than 200 polys.

Texture sizes go in powers of two: 2, 16, 32, 64, 128, 256, 512, 1024, 2048. D3 will automatically rescale TGA textures that are not in powers of two, which could stretch your texture and waste processing time. Note that the dimensions of DDS textures absolutely have to match powers of two, otherwise they appear black in-game.

Naming Conventions

The following convention should be used for naming all new model additions to TDM (many existing models do not follow this convention, and over time effort will be made to update them). The goal is consistency among names based on ordered characteristics, and this convention is also shared with material names. Obviously some descriptors which apply for materials may not apply for models.

1. Object Type descriptor first. As a model is an object, this descriptor is mandatory. It's a window, a door, a chest...
2. Material descriptor next. Optional. Remember that skins might exist. Made from marble, wood, mud...
3. Size descriptor next. Optional. It is large, small...
4. Quality descriptors next. Optional. Remember that skins might exist. Texture-wise, it is rough, new, cracked...
5. Color descriptors next. Optional. Remember that skins might exist. What color is it? red, green...
6. Number Increment next. Mandatory. Which of the list is it? 001, 002...

If establishing precedent (creating a new Size descriptor, e.g., "huge"), try to avoid ambiguity and unnecessary overlapping with other descriptors (e.g., "enormous"), and set a good example others will follow.

Examples:

1. chest_001

This name omits all but the mandatory descriptors. If valuable information about the object can help differentiate it from others, optional descriptors may be added. If it is indeed generic, this name is fine.

Why is this preferred? Some existing models are named by other than Object descriptor first. Since the Editors sort models into lists based on the filename, sorting is made useless in this case, and the user is forced to search all models manually.

2. door_wood_battered_005

This highly descriptive name omits a Size descriptor and a Color descriptor.

Why is this preferred? Some existing models are named by quality descriptor first (e.g., 'battered_door...'). This is an inconvenience for the user, because they were looking for a 'door', not a 'battered'.

It should be noted that a given descriptor could be double-stage if needed, for example, lamp_wall_ (uses two object descriptors), as long as it either follows precedent or establishes a good one. In this case, care should be taken not to trample over the next-in-line descriptor for existing items (e.g., lamp_woodlandforest conflicts with sorting of lamp_wood), nor to separate the object from those with which it belongs.

Where to Save your Model and Textures

Models should be saved in the models/darkmod tree. See Model Folder Structure for specific information about where to put things.

Grid Alignment and Origin

Please make sure your models are grid-aligned (the bottom of the object rests on a grid line in your modelling software). If they don't, it can be difficult to get the model to sit on the floor or other surfaces in the editor.

Re: Origins. D3 uses the origin of the model to determine physics for movement--moveable objects will rotate around the origin when they are bouncing around. Any model that will likely be made into a moveable object (basically any unattached object smaller than a chair) should have its origin where its center of gravity would be.

Large objects that are not likely to be moveables, like desks or wardrobes, can have their origin at the bottom of the object, for easy placement on the floor.

An exception would be something like trees that an author might possibly sink into the ground far enough to reach outside the world. In this case have a centered origin would be best so the origin stays inside world.

Objects that might be designed to swing or rotate (like a hanging sign) should have their origin at the point of rotation.

Collision and Shadow Meshes

Collision models should be used on most objects for several reasons. They can help simplify pathfinding databases for AI and weapons, they also simplify the shape of the object so it can be moveable. If an object is going to be static and not move, like a pillar it's collision model can be as complex as you want, however this defeats the purpose of a collision mesh. Generally you want to make the collision mesh as simple as possible while retaining the basic shape of the model. This will guaranty that arrows will bounce of of it, or stick to it in a realistic way. If the mesh doesn't match the original object close enough you will get things like arrows bouncing off the air next to the model, or arrows that go through the model.

Collision models must be exported with the original object mesh. This makes them hard to see in the editor, but the collision surface can be toggled so it's not a problem. Collision meshes won't be seen in game, nor will their effects if done properly.

A static object can use one or more collision models, the purpose of this is to apply different materials to the colllision model. For instance, the generic Doom collision soundslike stone when an arrow bounces off of it, and arrows will always bounce off of it. However Dark Radiant allows the use of material specific collision shaders. So a chest can be made of metal and wood, an arrow will bounce of the metal parts and stick into the wood parts. The number of collision meshes on a static object is undetermined but should be limitless. This is a good way to simplify collision while retaining the objects material types. A collision model overrides an objects shader types, so if you export with collision try to seperate it into materials.

Examples of collision shader names: tdm_collision_wood, tdm_collision_ceramic

Moveable objects must have collision models unlike static objects. These meshes have to be very simple. Currently the exact specs of a moveables collision mesh are under debate. You will often see these specs stated as 16 polys, no concave polys, ect... But it is possible to make workable collision models with both of the above, however it is very unlikely and you are lucky if it works. Most of the time if you do break those rules you will get an unstable mesh that will fly across the room when frobbed, sometimes even resulting in SHAS (Sudden Heart Attack Syndrom) when the player dies without warning. So sticking to those guidlines is usually best and can still result in a decent collision model in most cases. Multiple collision meshes have been successfully exported also, however they only use the material type of the first collision model loaded, this can also lead to instability. Generally simple shapes work best, just try to make it fit your object as close as possible.

Shapes that work well for moveable collision models are cubes, pyramids and cylinders (up to 7 sides seems to work well).

For an idea what will work look at models in the model viewer. Of course a crate has a cube, a gear will have a cylinder, a lamp might have a pyramid. Objects that use unconventional shapes that defy the rules above are keys and the silver teapot.