Nexuiz has a wide range of player models. Some of them are okay, some of them are slightly okay, some of them just are weird. If you have skills in modelling you may feel urged to improve on this situation. This document shall serve as a quick guide into how to create player models for Nexuiz.

Nexuiz supports player models in basically two formats: MD3 and ZYM. So let's have a look what each of those have to offer.

MD3 is the native format of Quake 3 Arena from id Software. It's an oldschool, vertex-animated format. Note that you of course still do skeleton-based animation in your modelling application and that this then gets converted on export. Given how widespread games based upon the Quake 3 engine are many modelling apps have export utilities for MD3.

MD3 has the advantage of being supported in many modelling applications and the disadvantage that (due to animation data being stored for each vertex) files tend to be bigger than e.g. ZYM.

ZYM is the format all current official Nexuiz player models are stored in. It uses skeleton-based animation (no conversion to vertex animation on export) and happens to be self-controlled, meaning that whole animation-sequences and their timings are stored in the model and the gamecode only selects between those sequences. This is different from e.g. MD3, where each frame of the animations gets a frame number and the game code selects frame after frame with fitting timing to create the impression of a fluid animation.

ZYM is created from files in SMD format. SMD happens to be a format being used for model creation for the game Half-Life. So first you have to export your model into SMD format and then convert that to ZYM using the zmodel program (the Blender export script may combine those two steps into one step, offering usability advantages). The idea behind this: The mesh (with a standard-skeleton) is exported into its own SMD file and zmodel adds the animation information from other SMD files, which only store animations without a mesh. Nexuiz has two or three premade animation sets which can be applied to any mesh stored in SMD with a fitting skeleton.

ZYM has the advantage of usually being smaller than MD3 but the distinct disadvantage of having the creation path perceived as more complex.

Get hl2_smd_mesh_export.py from http://morfar.affro.net/nexuiz/modelling/justscripts.zip

This is a HL2 SMD export script, and it should work for Nexuiz. You need zmodel installed in your PATH (on OS X, you have to compile zmodel and put it in /usr/local/bin).

If you don't have zmodel available you can compile on your own.

1. Mac: Download and install Xcode (somewhere on the Apple site). Linux: Install the usual build setup (GCC and whatnot).
2. Get zmodel.c and makefile from http://svn.icculus.org/twilight/trunk/zmodel/, and run “make” in that directory (using Terminal.app if you're on a Mac or your favorite terminal if you're on Linux).
3. Do “sudo mv zmodel /usr/local/bin/”
4. (enter password)

Then move hl2_smd_mesh_export.py to whereever Blender expects its scripts in.

For using that script, you have to know:

• The script exports a SINGLE mesh with an attached armature. If you have multiple meshes, JOIN (J key) them first. You can't have multiple armatures.
• The script creates the .zym file and a directory named like your model with SMD files. The .zym file can be used as Nexuiz player model. In case you need to edit something in the control file, the .txt file is included too, and you can run zmodel on it (from Terminal.app, again).
• The actions for the model animations have to be named like follows (without the stuff in the parentheses):

0-die1-20n (0.5 seconds)
1-die2-20n (0.5 seconds)
2-draw-20n (0.35 seconds)
3-duck-20n (any duration, but should be instant)
4-duckwalk-20 (any duration)
5-duckjump-20 (any duration, but should be instant)
6-duckidle-20 (any duration)
7-idle-20 (any duration)
8-jump-20n (any duration, but should be instant)
9-pain1-20n (2 seconds)
10-pain2-20n (2 seconds)
11-shoot-20n (0.2 second recommended, but cut off when shooting anim is over)
12-taunt-20n (unused by the code, 1 second allocated)
13-run-20 (any duration)
14-runbackwards-20 (any duration)
15-strafeleft-20 (any duration)
16-straferight-20 (any duration)
17-dead1-20 (must be identical to the last frame of die1)
18-dead2-20 (must be identical to the last frame of die2)
19-forwardright-20 (any duration)
20-forwardleft-20 (any duration)
21-backright-20 (any duration)
22-backleft-20 (any duration)

That is because the export script sorts them by the number in front, and the number at the end is the frame rate (you may change that to your preferred frame rate). Currently, the frame rate set globally in blender is ignored (because I have no idea how to get that in the export script API). The “n” means “not looped”.