 |
Nuclide
Software Development Kit for id Technology
|
|
Nuclide
Software Development Kit for id Technology
|
The engine handles all the file formats related to model files.
Table of supported model formats:
| File Extension | Type | Description |
|---|---|---|
| mdl | Animated, Vertex | Quake 'Alias' Model |
| md2 | Animated, Vertex | Quake II Model |
| md3 | Animated, Vertex | Quake III Arena Model |
| mdx | Animated, Vertex | Kingpin Model |
| mdl | Animated, Skeletal | Half-Life Model |
| iqm | Animated, Skeletal | Inter Quake Model |
| vvm | Animated, Skeletal | Vera Visions Model |
| psk | Animated, Skeletal | Unreal Engine Model |
| zym | Animated, Skeletal | Zymotic Models |
| dpm | Animated, Skeletal | Darkplaces Model |
| gltf | Animated, Skeletal | GL Transmission Format |
| glb | Animated, Skeletal | GL Transmission Format Binary file |
| spr | Sprite | Quake I variant, Global Palette |
| spr2 | Sprite | Quake II |
| spr32 | Sprite | Darkplaces variant, uncompressed 32-bit color |
| obj | Static | Wavefront Object |
| lwo | Static | LightWave Object |
| ase | Static | Autodesk ASCII Scene Export |
Formats available in plugin-form:
| File Extension | Type | Description |
|---|---|---|
| mdl | Animated, Skeletal | Source Engine Model |
Vera Visions Model, also known as VVM or IQM-FTE is the main skeletal model format.
Features that the original IQM exporter (by Lee Salzman) did not offer:
Some features that our extended specification (VVM) has to offer:
NOTE: Using any of the VVM features is not supported in any engine other than FTEQW
The tool's output will let you know if you're outputting an IQM compatible file or not.
It also has a re-engineered exporter that takes control files as input, rather than a giant command-line string. This was done because some models have hundreds of model parameters in The Wastes.
In 2016 when we had our first prototype of The Wastes, we started out using DPM for tool-chain related reasons and quickly migrated to IQM. However we needed a better system for handling reproducible output files. The original tool only handled compilation via plain command-line parameters which was not good enough.
The input command file (.qc) syntax is obviously inspired by qdata and other tools such as studiomdl. So if you're familiar with those tools you know exactly what to expect.
We then went on and designed extensions that we needed to make the game work, for example a generic model-events system that'd call events in the game-logic when a certain key-frame in the model is displayed.
More complicated things were hit-meshes, for more accurate hit detection of body parts as well as sub-models that made the action of shooting body-parts off possible.
We developed this together with David of FTEQW, since this had to be developed in conjunction with the FTEQW built-ins that'd later be exposed to the game-logic.
However, the initial extensions to the IQM format in FTE were designed by us; and this is the exporter that was used to make our game.
You can grab a binary build of FTE 1 (basically a generic, non The Wastes specific version) and use the 'modelviewer' command in the console. The console can be opened via Shift+ESC.
If you want to see for example the Winston viewmodel, type modelviewer models/weapons/v_winchester.vvm
As you already know, the VVM exporter (vvmtool) takes inspiration from Valve's studiomdl in terms of usage. There are slight syntax differences, primarily because the way some features are implemented differ drastically.
For example, model events can be stacked and applied to many animation sequences at once. There is no way to do so with studiomdl.
Any .vvm consists of multiple input files. These can come in the following formats:
Make sure that when you use animated files, that the bone naming and bone order is consistent among them.
This file is the head of the format. It specifies how the input files are loaded in, with additional useful commands on how to manipulate the input data. Many of these features would not be possible with an internal, modeling program specific exporter for VVM.
Here's an EXCERPT of a control file from **The Wastes*:
That's a really complicated control file, but it highlights a few things:
However, a model control file doesn't need to be this complicated:
This is models/props/computers/terminal01.qc from The Wastes.
What each line means:
output specifies the resulting final output file name and location relative to the control file.
materialprefix just appends this string to any referenced material. Ideally it's the location where the .vvm itself is stored in your game filesystem.
rotate Simply rotates all input files by 90 degrees on the Y/Yaw axis upon importing.
scene Tells it to load one input file, which is a reference. If it was an animation it'd specify a framerate via the 'fps X' parameter.
You grab your copy of vvmtool and you either drag and drop your control file onto it, or run it via command-line:
vvmtool.exe foobar.qc
It should be as simple as that!
Some helpful tips for your content creation journey.
I recommend getting a single reference, plus the animations into your game first, then adding events and other necessary commands on top.
You can use the console command vid_reload to force the engine to flush the model/texture cache and to reload an updated model from disk. Really useful when iterating over model exports.
If you're using the Blender Source Model tools, as of 2021, it still doesn't down-mix certain animation features into the .smd format.
This is a problem with the Blender exporter, not vvmtool (as it also won't work in studiomdl).
So if your bones seem completely messed up, try .fbx instead.
If you absolutely need to use .smd, export it as .fbx in Blender, import said output back into Blender and then export as .fbx.
