-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added basic formats supported by the engine
- Loading branch information
1 parent
ba78990
commit 8241df6
Showing
16 changed files
with
810 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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" | ||
} | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
Oops, something went wrong.