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)
No edit summary
Line 4: Line 4:




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


* somewhat default
* somewhat default
Line 11: Line 11:




=== ASE: ===
=== ASE ===


* larger uncompressed size since it is text (compressed size is probably OK?)
* larger uncompressed size since it is text (compressed size is probably OK?)
Line 17: Line 17:




=== OBJ: ===
=== OBJ ===


* the only format added specifically for TDM, so not very widespread
* the only format added specifically for TDM, so not very widespread
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.
Line 65: Line 65:
== textures and images ==
== textures and images ==


=== TGA: ===
=== 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.




=== 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 😃
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: ===
=== JPG ===
Lossy format, but pretty small and rather fast to load.
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.
I think it is usually used for screenshots and maybe GUI images, otherwise not popular.




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


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


== sound files: ==
== sound files ==


=== OGG: ===
=== 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.

Revision as of 11:20, 6 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 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.