File formats: Difference between revisions

From The DarkMod Wiki
Jump to navigationJump to search
Datiswous (talk | contribs)
Created page with "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..."
 
Datiswous (talk | contribs)
 
(11 intermediate revisions by 2 users not shown)
Line 4: Line 4:




=== LWO: ===
=== LWO ===


* somewhat default
* somewhat default
* small uncompressed size since it is binary
* 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)
* loading code can be slow




=== ASE: ===
=== 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)


* somewhat default
* larger uncompressed size since it is text
* loading code can be slow


=== OBJ: ===


* the only format added specifically for TDM, so not very widespread
=== OBJ ===
* 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


* obj support has been added to TDM fairly recently, there aren't many missions yet that use it.
* uncompressed size is large because it is text
* loading is very fast


== Ragdolls ==
== Ragdolls ==
Line 35: Line 35:
== Animation ==
== Animation ==


=== MD5: ===
=== MD5 ===
* md5mesh --- Doom 3 custom text format which represents a mesh attached to skeleton (joints, weights, etc.)
* 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.
* md5anim --- custom text format that represents an animation of a skeleton.
Line 42: Line 42:




=== MD3: ===
=== MD3 ===
This is Doom 3 custom text format which represents linear vertex morphing.<br>
This is Doom 3 custom text format which represents linear vertex morphing.<br>
It is rarely used, but it is a perfect fit in case animation is clearly not "skeletal" (e.g. animated grass or water).
It is rarely used, but it is a perfect fit in case animation is clearly not "skeletal" (e.g. animated grass or water).
Line 48: Line 48:
<!-- converters? -->
<!-- converters? -->


=== Others: ===
=== 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.
* 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.
* Maya ascii format (.ma, mb), currently no further known info on it.
* OpenFlight model (.flt), currently no further known info on it.
* OpenFlight model (.flt), currently no further known info on it.


== Video: ==
 
== Video ==


* The mainstream format is mp4 + h264 + aac for FMV.
* 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.
* 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.
All the other formats are disabled in the FFmpeg build that we use.


=== In-game videos ===
=== 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...
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". It's also possible to display a video on a texture.




== textures and images ==
== Textures and images ==


=== TGA: ===
(Images inside guis (briefing, readables) use the same material loading system, so they should support all the same image formats.)
 
 
=== TGA ===
The simplest uncompressed format, basically default in case compression is not used.
The simplest uncompressed format, basically default in case compression is not used.
Used often for normalmap textures
* Supports transparency.




=== PNG: ===
=== PNG ===
Lossless compression, but pretty slow to load.
* 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 😃
* Supports transparency.
* Should therefore be OK for some GUI images for example, but not used on a large scale.




=== JPG: ===
=== JPG ===
Lossy format, but pretty small and rather fast to load.
Lossy format, pretty small and rather fast to load.
I think it is usually used for screenshots and maybe GUI images, otherwise not popular.
* '''Does not''' supports transparency.
Usually used for screenshots and maybe GUI images, otherwise not popular. Usually used for DarkRadiant editor image.




=== DDS: ===
=== 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).
This is container which can in principle store both compressed and uncompressed data, but is used only for precompressed textures. TDM supports DXT1 (BC1), DXT3 (BC2), DXT5 (BC3) (and 3Dc (BC5) for normalmaps, since 2.10), RGTC compressed formats (each of these formats has a bunch of pseudonymes).
DXT3 and DXT5 support transparency (but in different ways).


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.
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.
The engine has a 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.
[http://wiki.polycount.com/wiki/DXT Info on DXT compression formats]<br>
[http://wiki.polycount.com/wiki/3Dc Info on 3Dc compression format] (for normalmaps)


== sound files: ==


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


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

Latest revision as of 23:25, 19 January 2025

A list of file formats usable in TDM:

Models

LWO

  • somewhat default
  • small uncompressed size since it is binary
  • loading code can be slow


ASE

  • somewhat default
  • larger uncompressed size since it is text
  • loading code can be slow


OBJ

  • obj support has been added to TDM fairly recently, there aren't many missions yet that use it.
  • uncompressed size is large because it is text
  • loading is very fast

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.

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". It's also possible to display a video on a texture.


Textures and images

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


TGA

The simplest uncompressed format, basically default in case compression is not used. Used often for normalmap textures

  • Supports transparency.


PNG

  • Lossless compression, but pretty slow to load.
  • Supports transparency.
  • Should therefore be OK for some GUI images for example, but not used on a large scale.


JPG

Lossy format, pretty small and rather fast to load.

  • Does not supports transparency.

Usually used for screenshots and maybe GUI images, otherwise not popular. Usually used for DarkRadiant editor image.


DDS

This is container which can in principle store both compressed and uncompressed data, but is used only for precompressed textures. TDM supports DXT1 (BC1), DXT3 (BC2), DXT5 (BC3) (and 3Dc (BC5) for normalmaps, since 2.10), RGTC compressed formats (each of these formats has a bunch of pseudonymes). DXT3 and DXT5 support transparency (but in different ways).

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

Info on DXT compression formats
Info on 3Dc compression format (for normalmaps)


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.