File formats

A list of file formats usable in TDM:

Models

LWO:

• somewhat default
• small uncompressed size since it is binary
• loading code can be slow and (some people have reported) it can sometimes break your model (smoothing groups might be a pain)

ASE:

• larger uncompressed size since it is text (compressed size is probably OK?)
• loading code can be slow and (some people have reported) it can sometimes break your model (smoothing groups might be a pain)

OBJ:

• the only format added specifically for TDM, so not very widespread
• uncompressed size is large because it is text (compressed size is probably OK?)
• loading is very fast and does not "fix"/break your model, you'll get exactly the topology & smoothing you exported

Ragdolls

The only format is .af text format, which is handmade for Doom 3. No changes here since Doom 3.

It is notoriously hard to create/edit. The only tool is the Windows-only builtin command editAFs, and this is the only in-game editor which has no outside alternatives. We wanted to port it to either DarkRadiant or at least better GUI framework, but it did not happen (yet).

Animation

MD5:

• md5mesh --- Doom 3 custom text format which represents a mesh attached to skeleton (joints, weights, etc.)
• md5anim --- custom text format that represents an animation of a skeleton.

MD3:

This is Doom 3 custom text format which represents linear vertex morphing.
It is rarely used, but it is a perfect fit in case animation is clearly not "skeletal" (e.g. animated grass or water).

Others:

• Some hardcoded pieces of code which transform a mesh into something else, that are enabled via "deform" keyword in a material. The most known example is particles. All of this is very specific and uses custom formats.
• Maya ascii format (.ma, mb), currently no further known info on it.
• OpenFlight model (.flt), currently no further known info on it.

Video:

• The mainstream format is mp4 + h264 + aac for FMV.
• There is also still legacy support for ROQ which is an old format used in Doom 3.

I think all the other formats are disabled in the FFmpeg build that we use.

In-game videos

One specific case is animated textures (e.g. water), and they are usually implemented as a pack of copy/pasted if-s in a material file, which point to different frame images. Something like "Motion JPEG/TGA/PNG/DDS" 😃 Maybe one day we will make this approach easier to use...

textures and images

TGA:

The simplest uncompressed format, basically default in case compression is not used.

PNG:

Lossless compression, but pretty slow to load. Should be OK for some GUI images, but probably not a good idea to e.g. write all normal maps as PNGs: I imagine loading times will increase noticeably if we do so 😃

JPG:

Lossy format, but pretty small and rather fast to load. I think it is usually used for screenshots and maybe GUI images, otherwise not popular.

DDS:

This is container which can in principle store both compressed and uncompressed data, but I think we use it only for precompressed textures. TDM supports DXT1, DXT3, DXT5, RGTC compressed formats (each of these formats has a bunch of pseudonymes).

If you use compressed DDS, then you can be sure it will be displayed as is, as no further processing it applied to it. Sometimes it is good, sometimes it is bad. The engine has fast compressor/decompressed for all texture compression formats, so if you supply TGAs and they are compressed on load, you only lose in mission size.

Images inside guis (briefing, readables) use the same material loading system, so they should support all the same image formats.

sound files:

OGG:

• Relatively widespread open format with lossy compression.
• Default used format
• OGG files are loaded on level start, but decompressed on the fly.

WAV:

• Simple uncompressed sound file.
• Larger than OGG. Potentially higher quality.
• The "shakes" feature of materials specifically asks for WAV.