Skip to content

Commit

Permalink
Added basic formats supported by the engine
Browse files Browse the repository at this point in the history
  • Loading branch information
FriskTheFallenHuman committed Mar 7, 2024
1 parent ba78990 commit 8241df6
Show file tree
Hide file tree
Showing 16 changed files with 810 additions and 2 deletions.
3 changes: 3 additions & 0 deletions _config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,9 @@ callouts:
doom3:
title: Doom 3 Only
color: doom3
doom3bfg:
title: Doom 3 BFG Edition Only
color: doom3
wolf09:
title: Wolfstein (2009)
color: wolf09
Expand Down
4 changes: 2 additions & 2 deletions docs/engine/cm/cm.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,8 @@ From this point the `.cm` file must be named and placed in the same directory as
# Note

{: .etqw}
> Enemy Territory: Quake Wars encrypt its files so its hard to see what change and what not.
> Encrypted models has the post fix of `b` in this case `.cm**b**`
> Enemy Territory: Quake Wars binarizes its files so its hard to see what change and what not.
> Binarize models has the post fix of `b` in this case `.cmb`
{: .wolf09}
> This system is deprecated in Wolfstein (2009)
95 changes: 95 additions & 0 deletions docs/engine/fileformats/ase.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
---
layout: default
title: Ascii Scene Export (.ase)
parent: File Formats
grand_parent: Engine Documentation
nav_order: 1
---

# Overview

---
ASE stands for Ascii Scene Export. This is an ascii text based format associated with 3DS Max. It is not limited to that application, but support in other applications is dependent on import/export scripts or plugins.

The Doom 3 engine uses the ASE format for static meshes.

# Export

---
- iddevnet model export page
- Maya can export ASE’s using the ActorX plugin.
- Blender via [export plugin](https://github.com/FriskTheFallenHuman/D3ModdingKit/tree/master/blender)

# File Format Syntax

---
**Format:** The format is based on identifiers, as in:

```cpp
*AN_IDENTIFIER
```

This is followed by zero or more values, or a subset of more identifiers surrounded by curly braces.

Most of the time when working with ASE’s, you will find that you have to open them to manually link the materials to a specified material shader. For example, the format for the material list may look like this when exported from actorx:

```cpp
*MATERIAL_LIST {
*MATERIAL_COUNT 2
*MATERIAL 0 {
*MATERIAL_NAME "myMaterial"
*MATERIAL_CLASS "Standard"
*MAP_DIFFUSE {
*MAP_CLASS "Bitmap"
*BITMAP "None"
}
}
}
```
Where it says:
```cpp
*BITMAP "none"
```

You must replace this with a reference to a doom material shader, like so:

```cpp
*BITMAP "//base/models/mapobjects/myModel/myShader"
```

Occasionally, for some unknown reason this reference doesn’t work in which case you should try…

```cpp
*BITMAP "//purgatory/purgatory/models/mapobjects/myModel/myShader"
```
…or…

```cpp
*BITMAP "//doom3/base/models/mapobjects/myModel/myShader"
```

{: .quake4}
> Instead of `//base` or `//purgatory/purgatory` QuakeIV seems to use
>
> `C:\Ritual\Q4ritual\game\q4base`
>
> `*BITMAP "C:\Ritual\Q4ritual\game\q4base\material\name"`
{: .etqw}
> use `*MATERIAL_NAME "material/name"`
>
> eg `*MATERIAL_NAME "textures/models/mymodel"`
{: .note}
> Subpatch a.k.a. subdivision surfaces are not supported.
>
> Models must be composed entirely of triangles.
>
> Smoothing groups are ignored by the engine.
# Further information

---
Format Specification, a bit more complete than above: [Inofficial File Format Specification at BeyondUnreal](https://wiki.beyondunreal.com/Legacy:ASE_File_Format)
31 changes: 31 additions & 0 deletions docs/engine/fileformats/cfg.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
layout: default
title: Configuration Files (.cfg)
parent: File Formats
grand_parent: Engine Documentation
nav_order: 5
---

# Overview

---

The .cfg files are ASCII text configuration files present in `/base` and used by id tech 4 based games for setting CVars, mapping player input to keys or buttons (see note below), and executing console commands. Usually the following files are available (by reading order of the engine):

- `DoomConfig.cfg`: Stores all the game’s options. It’s auto-generated by the engine so manual editing is not recommended. If you delete this file the engine will revert to a `default.cfg` file located inside one of the .pk4 files.
- `editor.cfg`: Optional. Stores all the DoomEdit relevant options. It’s auto-generated by the engine so manual editing is not recommended.
- `autoexec.cfg`: Optional. This file is read last and will override any options set elsewhere. It’s meant for user-manipulation so you can set any CVars here that you’d have to otherwise set in the game or editor shortcuts.

You can also create your own custom configuration files to load custom settings and execute console commands in notepad. You can then load these files by using the exec console command in the shortcut or adding the following line to your `autoexec.cfg`:

```cpp
exec myconfig.cfg
```
You can use two forward slashes to write comments:

```cpp
// This is a comment
```

{: .note}
> Mapping player input is accomplished through the use of the bind console command which accepts console commands, cvars, and impluses as valid input.
15 changes: 15 additions & 0 deletions docs/engine/fileformats/demo.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
layout: default
title: Demo Files (.demo)
parent: File Formats
grand_parent: Engine Documentation
nav_order: 5
---

# Overview

---

These files are recordings usually done for benchmark purposes, they can have live gameplay or static scenes and are stored in / demos. Even after the introduction of LZW compression in v1.3 they remain big files. These files are created with two console commands: `demoShot` for static scenes and `recordDemo` for rolling demos. Use the `stopRecording` console command to stop a the recording of a rolling demo.

You can playback demos with the playDemo console command (it works on both types of demos). If you wish to benchmark using a demo see the `timeDemo` and `timeDemoQuit` console commands (you should set `"com_compressDemos 0"` in the console to avoid any slowdowns during the benchmark due to decompression).
18 changes: 18 additions & 0 deletions docs/engine/fileformats/formats_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
---
layout: default
title: File Formats
parent: Engine Documentation
has_children: true
nav_order: 2
---

# Overview
{: .fs-9 }

Idtech 4, supports a variety of file formats, most of them in human readable text.
{: .fs-6 .fw-300 }

---

{: .todo }
> Write more about this section.
28 changes: 28 additions & 0 deletions docs/engine/fileformats/lang.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
layout: default
title: Language Files (.lang)
parent: File Formats
grand_parent: Engine Documentation
nav_order: 6
---

# Overview

---

`.lang` files are used for localization purposes. For every language there is a different set of files available. Each of these files contains a numbered string that is referenced from within code, GUIs or maps. Each string has to have a unique number so there are no conflicts when referenced. Language strings are simply referenced by typing `"#str_20000"` in the textfield. Replace 20000 with the intended string number.

{: .doom3bfg}
> `#font_` specify the font to be use in the sfw shell, not use in the old GUI system.
> BFG Edition does't uses hashes, instead it uses full names like `#str_adil_exis_pda_01_audio_info`
## Syntax

---

```cpp
{
"#str_20000" "Placeholder"
"#str_20001" "Placeholder2"
}
```
114 changes: 114 additions & 0 deletions docs/engine/fileformats/lwo.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,114 @@
---
layout: default
title: LightWave Object (.lwo)
parent: File Formats
grand_parent: Engine Documentation
nav_order: 2
---

# Overview

---
LWO: LightWave Object file format is a propriatary binary file format and is the standard export format used with LightWave 3D and Modo . Support in other applications is dependant on import/export scripts or plugins. LWO files cannot be editied outside of a 3D application that supports the format, i.e. they cannot be edited in Notepad or similar.

The id Tech 4 engine uses the LWO format for static meshes.

More information on the LWO format can be found in the LightWave SDK .


# Export

---

## Static Models

---
Getting a static model (like a trash can or a shrubery) in to the game is really easy. The engine reads lwo (lightwave) and ase (3dsmax) files natively so you simply save out the model in one of those two formats and you can use it in the game.

The material that is used in game is the diffuse texture specified in the model.

The relative material name is determined by searching for `"base"` in the texture path. For example, if the texture specified in the .ase is `"C:\Doom\base\textures\base_trim\red1.tga"` Then it would use the material named `"textures\base_trim\red1"`

If you are running a custom mod, then it will look for the mod name if it can't find `"base"` so `"C:\Doom\jailbreak\textures\base_trim\red1.tga"` would also work in the jailbreak mod.

The path cannot have spaces in it. Doom 3 should be installed in `"C:\Doom\"` or some other place without spaces. If Doom 3 is in the default location of `"C:\Program Files\Doom 3\"` it will not work because of the space in `"Program Files"` and the space in `"Doom 3"`

Generally speaking, as long as you keep all your assets in the final directory that it will be in, then you should just be able to use it in game without having to touch anything. Problems tend to arise if you edit your assets in one directory, then move them in to the base directory or your mod directory after you export.

If you are working on a new chair, you should work on it in

```cpp
C:\Doom3\mymod\models\mapobjects\chairs\mychair\
```
rather than working on it in

```cpp
C:\My Stuff\Models\Cool Models\Stuff For My Mod\Chair
```

then moving to the proper directory after it's been exported.

Spaces in file names are bad.

## Animated Models

---
Animated models are quite a bit more complex. The only animation system supported in Doom 3 is skeletal (no vertex animation like in Quake), and the only file format supported is `.mb` (Maya binary). The files have to be processed using a built in tool to convert the Maya files to `.md5mesh` and `.md5anim` files.

**Note for 3dstudio max:** Although Doom3 does not support animated models from max "out of the box", the people over at Doom3World wrote some nice importers and exporters, which you can find here.

This built in tool is `exportModels`. By default, it will export any models that have been modified since the last time the command was run, but you can pass it a `.def` file and it will only export the models defined in that def file. You can speed up the exportModels command by using the `g_exportMask` cvar and specifying some magic string after the export declaration (as we will see later). Setting `g_exportMask fred` will only export fred's animations, skipping all the others.

You must have Maya installed on the machine that you are exporting on otherwise it won't do anything.

The syntax for an export section looks complex at first, but is actually quite simple when you break it down into the different parts. Unlike some other declarations, the commands in an export block are executed as they are encountered. This means the order DOES matter.

There are two systems at work when you export a file. The first is the actual exporter, this is the piece that does all the work. The second is what I'm going to call the `parser`. This piece reads the export sections and passes the commands to the exporter for actual exportation.

The parser only has 5 commands, and they are really very simple:

| Command | Description
|:----------------------------|:--------------------------------|
| options [options] | Stores default options that will be used for all future export actions. Note that an options command will override any previously set options. |
| addoptions [options] | Adds a default option to the current set of default options. This is very similar to the options command, but it appends rather than overwriting the current options. |
| mesh <mb file> [options] | Exports a object from a .mb file. The options specified here will be appended to the options specified previously with "options" or "addoptions" commands. |
| anim <mb file> [options] | TODO |
| camera <mb file> [options] | TODO |

Here is a list of all the options along with a brief description of what they do:

Option |Description
-----------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
\-force |Ignored
\-game |Specify the mod name, which is where the relative paths are defined from. This should get set automatically in 1.2
\-rename [joint name] [new name] |Rename a joint
\-prefix [joint prefix] |If you have multiple characters/objects in your scene, you can give them each their own prefix so the exporter can distinguish which goes to which. Example: ZSEC \_ IMP \_ ENV_
\-parent [joint name] [new parent] |Reparent a joint
\-sourcedir [directory] |Tell exporter where to get files from
\-destdir [directory] |Tell exporter where to put files after export
\-dest [filename] |Give a new name to the file you are exporting. Default will be the same name as the Maya file.
\-range [start frame] [end frame] |Frame range for what you would like to export. Example: -range 1 10
\-cycleStart [first frame of cycle]|Shift the cycle to start on a different frame. Example: Frame 1 has left foot forward, and frame 10 has right foot forward. So if you would like your cycle to start with the right foot forward, use -cycleStart 10 to shift the cycle.
\-scale [scale amount] |Scale up or down your character during export. Example: -scale 2 will double the size of the character (scaled up from the origin).
\-align [joint name] |Will align your animation to a certain bone.
\-rotate [yaw] |Allows you to manually rotate your animation. Example: -rotate 90
\-nomesh |
\-clearorigin |
\-clearoriginaxis |
\-ignorescale |Ignore any scales you may have on some bones.
\-xyzprecision [precision] |Will take even tiny movements (translations) into consideration if you make this number lower. The default will try to compress down the animations, getting rid of tiny movements.
\-quatprecision [precision] |Will take even tiny movements (rotations) into consideration if you make this number lower. The default will try to compress down the animations, getting rid of tiny movements.
\-jointthreshold [min joint weight]|
\-skipmesh [name of mesh] |Allows you to skip certain models during export.

# Notes

- A LWO to MD5 conversion utitlity can be obtained at ~~~www.doom3world.org~~~ dead link.
- An MD5camera export script can be downloaded from ~~~www.pcgamemods.com~~~ dead link.
- Subpatch a.k.a. subdivision surfaces are not supported.
- Surface properties are not parsed by Doom 3.
- Models must be composed entirely of triangles.
- All mesh data must be on a single layer.
- Each mesh must have exactly one UV map. Doom 3 will not crash if you have more, but textures will behave in unexpected ways, mixing UV maps, using the wrong UV map, etc.
- Smoothing angle is not supported. In game, smoothing occurs across welded triangles. Seams must be created manually by unwelding vertices.
- The surface name of each surface in LightWave 3D must match the name of the corresponding material shader in Doom 3.
Loading

0 comments on commit 8241df6

Please sign in to comment.