Player Models Documentation

[Jaquboss]

have a look at jaymod forums

[VonBulow]

I’m running an ET server with NoQuarter on it and I would really like to import some models from RtCW that I could then assign to certain GUIDs. Could someone point me in the right direction, how should I do this?

Are there any plugins for 3DsMax 2008 that will allow me to import RtCW models, make them a bit more HD, and then save them so they can be used in ET?

[Nail]

You’ll need permission from Activision and Grey Matter to use SP models, Activision and Nerve for any MP specific. Wouldn’t count on it

[YourFather_CZ]

[QUOTE=VonBulow;174893]I’m running an ET server with NoQuarter on it and I would really like to import some models from RtCW that I could then assign to certain GUIDs. Could someone point me in the right direction, how should I do this?

Are there any plugins for 3DsMax 2008 that will allow me to import RtCW models, make them a bit more HD, and then save them so they can be used in ET?[/QUOTE]
I think there is not any free import/export plugin for 3DSMax7 and newer.
I recommed Milkshape instead 3DSMax - it’s much better if you’d like to import/export some models. But as Nail wrote - you need permission for modification RtCW models.

http://www.maxplugins.de/max8.php?search=rtcw&sort=Author --> import plugin for 3DSMax 6

[twt_thunder]

could really neede it!!!

[rstu339]

前不久曾说过，FIA有意实施新的F1规则，主要目的是减少赛车对环境的影响，并降低成本，使赛车技术对现实世界更有价值。其中一项要求就是将减速能量存下来用于加速，使出弯后加速更为凌厉，或者“尾随-甩出-超车”式的进攻更容易得手。现在，第一个商业化的产品已在开发中，Xtrac获得了Torotrak的专利授权，将利用后者的圆环曲面传动方案，开发高效、紧凑、速比连续可变的传动装置，在F1赛车上实现能量回收机的设想。而且我们也很容易预见，它会出现在普通的道路车辆上。 所谓圆环曲面在这里就是指圆环内圈的表面形状，你可以想象出一个多纳圈，用砂子把它中央的孔塞实，之后你如果有本事把多纳圈吃干净，那么剩下的砂型就是圆环曲面了。是不是象个沙漏瓶的小腰？在这个细腰的中间截开，就是Torotrak变速器的核心——两个尖对尖的转盘，其中一个当动力输入用，另一个别无选择，就只好用来输出了。 光靠两个尖顶着肯定是传递不了动力的，更别提变速了。于是在转盘之间还安置了两到三个滚轮。两个转盘对向夹紧，就会夹住这些滚轮，输入转盘转动时，会带着滚轮转，输出转盘自然也跟着转起来。看得出，力是通过滚动摩擦传递的。那么怎样实现变速呢？只要让滚轮的轴线摆动起来就行了。开始时滚轮的一边顶着输入转盘半径较大的位置，另一边按在输出转盘靠近尖顶的地方，就是低档。随着滚轮的摆动，速比便会越来越小，而且，这个变化是连续的，即CVT。现在市场上常见的CVT是皮带轮+带或链条的式样，与之相比，这种圆环曲面变速器的效率更好，而且能传递更大的扭矩，Torotrak的演示车就是辆Ford的SUV，475Nm扭矩的5.4升V8发动机充分证明了这种传动方案的负载能力。Torotrak还为变速器取名IVT，即infinitely variable transmission，以示区别。 还记得Atkinson循环吗？很多人类发明都要在历史长河里经世累代地潜水，才能修成正果，圆环曲面变速器也是如此。早在1877年，Charles Hunt就申请到了专利，而直到1920年代，经Frank Hayes改进之后才推向市场，在1930年前后安装到Austin 7上。Perbury公司在1960～1980年代期间对其继续完善，成果甚至打动了军方——在著名的鹞式战机上用来带动一台25千瓦的发电机，虽然扭力不是很大，但转速特高，从7000到17000rpm。1986年BTG集团接手相关业务，又过了十几年，掌握这项技术的部门脱离了BTG，才有了今天的Torotrak。 当今材料的发展使这种变速机构日臻完善。理论上，转盘和滚轮是紧紧地贴在一起的，这样才能产生摩擦力，但事实上它们并没有真的接触，这要归功于一种特别开发的长分子链摩擦液。这种液体在压力之下粘度也会大涨，不但能传递摩擦力，还能形成0.05至0.4微米的液膜，将转盘和滚轮隔开。要形成如此薄的膜，肯定也离不了精密的加工技术和精良的钢材。给Torotrak加工转盘、滚轮的是光洋精工（去年初和丰田工机合并，现在的名字叫JTEKT），它的当家产品就是滚珠轴承。无独有偶，日本精工NSK也为Jatco加工类似的部件，不用说也知道NSK是干什么的。Jatco为日产制造的Extroid被称为半圆环曲面变速器，说白了就是曲面的圆弧短了点，速比变化范围只有4.36，不得不借助液力变扭器滋补一下扭力，但也不是说它无扶鸡之力，只要车子一动起来，变扭器就能立即锁住，无需再劳动了。相比之下Torotrak的底气要冲一些，它的演示机型速比跨度已经达到了6.05，所以才敢号称“无限可变”。 典型的圆环曲面变速器由两组机构串列而成，这样传递的扭力可以加倍，而尺寸也不会比一般的齿轮式变速箱更大。由于滚轮被禁锢在圆环曲面内，其转轴用不着承受任何负载。转盘受液压驱动沿轴向夹紧，而夹紧力度则由电控装置根据传递扭矩的大小来调节。 Torotrak完整的IVT变速器中，不仅有一个圆环曲面变速机构，还有一套行星齿轮。低速的时候，发动机一方面直接连到行星架，另一方面通过圆环曲面变速机构驱动太阳轮，从而实现从前进到倒车的速度连续变化，中间当然有完全停止的状态，因此称它速比无限可变。换言之，理论上其输出扭矩也可以变到无限大，控制系统通过控制速比就能克服很棘手的障碍，另一方面，速比的改变在曲轴仅转过半圈的瞬间里就能完成，所以不用担心因突然过载而损坏发动机或传动机构。只是这种状态下，按照美国CAFE工况测算，平均动力损耗超过19%，故而只用于倒车和起步。车速提高后，行星架被脱开，太阳轮和外齿圈被锁在一起，动力完全通过环形曲面变速机构传递。 再回到动能回收上来，圆环曲面装置本身肯定不能吸收、存储和释放动能，干这活儿的是一个飞轮（就是图中那个虚的大圆辊子）。Torotrak的变速装置也没有取代常规的多档齿轮式变速器，它的角色其实是连接飞轮和变速器的桥梁，通过调节速比，让动能以最优的方式在两者之间来回走动，而不是完全通过刹车盘散失掉。这种模式不但结构紧凑——Torotrak相信商业化的变速单元会轻于5公斤，而且其能量传递效率甚至高过90%，明显优于电机-蓄电池模式。F1对尺寸和重量的要求都非常严苛，如果成功的话，普及到其它领域就是轻而易举的事。 Xtrac将只提供变速单元，飞轮部分还要各车队自行开发（所以是虚的），Torotrak可以提供控制程序方面的专家意见。

[ischbinz]

unlucky the link in the 1st post don t work -
inside it are some essential informations -

dunno why this page is nt included there:( think most of you know this pages:)
http://tramdesign.planetwolfenstein.gamespy.com/tutorials/etdocs/

i found the missing page on a webarchive - but i dunno if i m allowed to host it…

Wolfenstein: Enemy Territory Documentation
© 2003 Splash Damage, Ltd. All Rights Reserved.
	
Player Models HowTo
The player model system in Enemy Territory exists out of multiple parts. This document will elaborate on all the different files needed, how to create them and how to fit them together. There are quite a few files involved per player model, so good media management is a requirement.

The File Types
.mdm 	Skeletal meshes. These files contain all surfaces with vertex positions, their bone weighting and UV information. Tags are saved to this file as well.
.mdx 	Skeletal animation files. These files contain the bone positions for multiple frames. Frame bounding box data is present too.
.md3 	MD3 files are old Q3 style meshes. They can be vertex-animated and are primarily used for head and attachment models.
.anim 	Animation groups. These files reference a set of mdx files and include their animation frame descriptors.
.aninc 	Animation inclusion files. They contain the names of animation sequences and their properties like starting frame, duration, frame rate, etc.
.skin 	Skin definition files. They are used in combination with a mesh to define the shader to be used with specific surfaces. They are also used to specify which models the game code has to attach to player models.
.script 	Animation script files. These define possible state combinations and are used by the game code to find out which animation sequences to play in those situations.
.char 	Character files. They combine all of the above files into a valid character that can be referenced from game code and map scripts to spawn a player or bot with a certain look.

A Quick Overview of the Exporting Process
It all starts with a mesh tied to a biped in MAX. Using the SkelOut plugin, this will be saved to a SKL file. Then, BuildMDS will use this file to create a MDM file and one or more MDX files. Tie these together with an animation group, an animation script and some skin files and you have yourself a new model.

From MAX to SKL
To install the SkelOut plugin, copy the skelout.dle file to the plugins directory in your MAX dir. (Re-)starting MAX will load the plugin.

The export process for an ET compatible version 2 SKL file requires you to have everything you don't want in the game hidden in MAX. All surfaces and tags that remain and will have to be exported into the MDM files will have to be frozen; else they'll get converted into bones. The only objects that remain unfrozen and unhidden should be the biped sections that the skeleton uses.

It's very important to make sure the biped is set to rigid, both during development and exporting to ensure what you see in MAX is the same as what you will see in-game.

Now hit file->export, select Wolfenstein Skeleton Export (*.SKL) from the dropdown box and enter a filename. Click on save and you will get a dialog box where you can enter multiple values for exporting.

Specify the start frame, end frame and the frame rate at which you want to have the SKL exported. The default frame and sample rate of 15 should be fine in all cases. Make sure you select version 2 for MDM exports, else you won't be able to create proper MDM or MDX files.

Hit OK and the plugin should start exporting. Minimize MAX for the process to go faster as it won't have to render the frames as it goes.

Providing no error messages pop up you should have made yourself a SKL file.

BuildMDS
To convert the SKL file to MDM and/or MDX files a tool called BuildMDS is used. Before this tool is used some understanding about the ideas behind MDX and MDM is required.

The reason these model formats have their meshes and animation data separated is so that multiple meshes can share the same animation data which has the potential to greatly reduce the games' memory footage. There is only one requirement to make this work, namely that all bones that a mesh references must be present in the animation data. So basically the bone structure in the MDX files always has to be the same, or a superset of, the bone structure in the MDM files. To ensure this, a parent MDX file will have to be specified when exporting related MDM or MDX files. How this file is generated and where it has to be referenced will be explained later on.

Before you will be able to convert a SKL file, you need two additional files. A .skd file and a .ski file. The skd file is used to define the spine bones and the way the torso bends. Besides that it contains information about the models' LOD. Here is an example of a skd file:

//
// MDS definition file
//
// (read in by BUILDMDS when building the MDS file)
//
//-----------------------------------------------------------------------------------------

VERSION 1

//-----------------------------------------------------------------------------------------
//
// SPINE BONES
//
// This is used to scale torso rotations to create a smooth transition along the spine
//
// Always make sure NUMWEIGHTS specifies the correct number of bones listed
//
// NOTE: this is also used to determine where the torso starts. so if you decide to give the
// first spine element a torso weight of 0, it will be deemed as belonging to the legs, so it will
// show legs animations. so best set it to a very low number (eg. 0.0001) so that it remains
// connected to the torso.
//
// NOTE2: any descendant bones of those listed here will be deemed as belonging to the torso. So
// make sure any legs bone do not descend from any of these bones.

NUMSPINEBONES 3

// NOTE: cant use the "spine" since it is the parent of the thigh's
//"Bip01 Spine" 0.1

"Bip01 Spine1" 0.30
"Bip01 Spine2" 0.55
"Bip01 Spine3" 0.85

//-----------------------------------------------------------------------------------------
//
// MISC INFORMATION
//
//
// LODFRAME is the animation frame index to use when creating the collapse map for LOD.
// The best frame to use for this is a crouching position where all elbow and knee joints are bent,
// otherwise the LOD levels won't take into account that these joints will often be bent, and will
// result in forced straight legs and arms in lower LOD levels.
//
// NOTE: a NEGATIVE lod frame translates to ( NUMFRAMES + LODFRAME ), so you can assign
// the second last frame and not have to update it each time the frame count changes

LODFRAME 4274

// LODSCALE can be used to vary the speed at which a model decreases it's LOD with range. It would
// be wise to give a low detail model a lower LODSCALE than a model with much higher detail.

LODSCALE 1.0

// LODBIAS can be used to set a fixed amount by which to adjust all LOD calculations for this model.
// This will effect the in-game LOD calculations by this amount, applied before 0.0 - 1.0 capping is
// applied.
// Negative values will decrease LOD falloff, so a value here of -1.0 will mean a model will always
// show full detail, assuming r_lodbias is 0.

LODBIAS 0.0

The comments in this example should explain the syntax and the usage well enough for you to create your own skd files.

The ski file is the export information file that BuildMDS uses to know which base MDX to use and which MDX files to export from a certain SKL file. An example:

//
// MDX export information file
//
// (read in by BUILDMDS when building the MDM/MDX files)
//
//-----------------------------------------------------------------------------------------

VERSION 1

//-----------------------------------------------------------------------------------------

// COMPILEBONESFILE links to the .mdx skeletal file that this mdm uses during compile, to grab the
// bonenames from and translate these to boneindices (this path is relative to the compiler). It needs
// to be generated before the .mdm can be generated. MDX files use it as well to remap their bones.
// It's a good idea to have a base (dummy) mdx file that is used to generate all the other mdx and mdm
// files of. For this file is required to be there (if it's not and it's listed in the mdxfiles
// list it will be generated automatically first), unless you are making the base mdx ofcourse. In that
// case give a COMPILEBONESFILE name of "BASEMDX". When that's the case then the mdx listed first in
// the mdxfiles list will be used as a base. Which naturally means that the skl used with this definition
// file has to be the skl that provides the base bonesetup.

COMPILEBONESFILE "BASEMDX"

// NUMMDXFILES is the number of mdx files we generate from this skl file using this definition file

NUMMDXFILES 2

// Here are the mdx file details listed. Syntax is <outputfilename> <startframe in .skl> <endframe in .skl>

"base.mdx" 0 4869
"self_inject.mdx" 4870 4886

This file should be self-explanatory as well, but to ensure nothing will go wrong some extra information regarding the COMPILEBONESFILE entry is needed. When exporting the first MDM and set of MDX files from a SKL that will provide the base MDX, the value of COMPILEBONESFILE needs to be set to "BASEMDX". This is required to show BuildMDS that we are using this SKL as a base.

Whenever a MDM or MDX is exported from other SKL files belonging to the same set of shared animations and meshes as this base MDX, COMPILEBONESFILE should point at a MDX file generated from the base SKL. This allows BuildMDS to remap the bones in other SKL files to ensure compatible MDM and MDX files are generated.

Keep in mind that whenever a new bones structure is required; for example if more bones are being used than the base provides, a new base MDX will have to be generated and all MDM and MDX files in the same set of animations will have to be converted again.

Now let's move on to the actual usage of BuildMDS. If you want to generate a MDM file and optionally a set of MDX files (you can set NUMMDXFILES to 0 in the ski file to choose not to generate any of these), you use the following command line:

buildmds <sklfile> -mdm [-verbose] [-force] [-dest name]

The SKL filename should be specified without extension. Verbose can be specified to generate extra information about the conversion process, force can be used to override the up-to-date checks done on MDM and MDX files relative to the source SKL file and force an export at all times. The MDM will be named after the SKL file, although this can be overwritten by using the dest parameter.

To only generate MDX files, the following command line is to be used:

buildmds <sklfile> -mdx [-verbose] [-force]

Both the command lines mentioned use the ski file to determine the filenames of the MDX files to generate.

There are more command line parameters available for BuildMDS, but most aren't relevant to the MDM and MDX conversion process. Some of them aren't used at all while some others might actually cause the process to malfunction. So unless you know what you're doing it's best to stay away from them.

Animation Groups
Now a set of compatible MDX files has been generated, an animation group needs to be made to tie them together. The syntax of this file is as follows:

animgroup
{
    animfile <mdx file>
    {
        #include <aninc file>
    }
}

There is no limit to the amount of mdx files that can be specified in one animation group.

The aninc file that is included through the #include statement specifies which animation sequences are present in the related MDX file and has the following syntax:

<animation name> <first frame> <length> <looping> <fps> <move speed> <transition> <reversed>

All of which should be on one line. Any number of animation sequences can be specified in one aninc file, the only limit is the total amount of individual animation sequences that can be handled by the game. A small example aninc file:

        // SELF INJECT
        self_inject        0    16    0    15    0    0    0

This one specifies only one animation, but every MDX file can have one or multiple animation sequences.

You can create multiple animation groups for a set of compatible MDX files, to create subsets for certain characters. This is useful if there is, for example, a cigarette smoking animation that is compatible with the default human set but this sequence is only used on certain levels. A separate animation group can be created for humans that smoke and referenced from a character definition that gets used only in those levels that require the animation. This prevents the game from having to load the smoking animation on levels that don't use it.

Another use is if you have two characters that use the same animation set and script, but each has its own death animations (which will be referenced from the animation script using the same animation names, such as death_knife), you then can create two animation groups for these characters and tie them up in two different character definitions. Useful if you have, for example, a scripted character you want to die in a certain way.

Skin Files
Skin files have two functions. They are used in combination with models where their primary function is to define which shaders are to be used on the surfaces of a model. Their secondary function, which only applies to skin files for the head and body models, is to attach accessory models to the body or head. The syntax is very basic, namely:

<key>,    "<value>"

If the key is the name of a surface, the value is an absolute path to a shader or texture to be used for this surface. For accessory attachment keys, the value is an absolute path to a model to attach.

The following keys are supported for the body skin file:

md3_beltr 	Attaches to tag tag_bright.
md3_beltl 	Attaches to tag tag_bleft.
md3_belt 	Attaches to tag tag_ubelt.
md3_back 	Attaches to tag tag_back.
md3_weapon 	Attaches to tag tag_weapon.
md3_weapon2 	Attaches to tag tag_weapon2.

And for the head skin file:

md3_hat 	Attaches to tag_mouth, gets removed when a headshot is given.
md3_hat2 	Attaches to tag tag_mouth.
md3_hat3 	Attaches to tag tag_mouth.

Character Definitions
Character files are used to describe a full character and tie all the files that define the way a player or bot looks. They have the following syntax:

characterDef
{
    <keys and values>
}

The following set of keys is supported:

mesh <mesh> 	The mesh file to use. (MDM or MDS)
animationgroup <animation group> 	The animation group. If a MDS is used, this should point to an old-style animation config.
animationscript <animation script> 	This points to an animation script file.
skin <skin file> 	The skin file used for the mesh. The actual filename gets derived from this string and the mesh filename. If you have "players/soldier/body.mdm" as mesh and "default" as skin, it will look for "players/soldier/body_default.skin".
animatedHead 	If this keyword is present, the code assumes the head model used for this character supports facial animation.
undressedCorpseModel <mesh> 	Mesh used for when a Covert Ops steals the uniform of a corpse. (MDM or MDS)
undressedCorpseSkin <skin> 	The skin file used for the undressed corpse.
hudHead <head model> 	Mesh to use for the hud head. (MD3)
hudHeadSkin <skin> 	The skin file used for the hud head.
hudHeadAnims <animation inclusion file> 	Hud head animation descriptions.

Enemy Territory File Tree Structure
For Enemy Territory the following file structure is used:

[etmain]
|
|-[animations] - contains animation group files (*.anim)
|    |
|    |-[human]
|    | |
|    | |-[base] - contains human/base animation set files (*.mdx/*.aninc)
|    |-[scripts] - contains animation scripts
|
|-[characters]
|    |
|    |-[<theme>]
|        |
|        |-[allied] - contains Allied character definitions
|        |
|        |-[axis] - contains Axis character definitions
|
|-[models]
    |
    |-[players]
        |
        |-[<theme>]
            |
            |-[allied] - contains subdirectories with Allied character media
            |-[axis] - contains subdirectories with Axis character media

A subdirectory with themed and teamed character media will use a structure similar to the following example:

[allied]
|
|-[soldier]
    |
    |-[acc] - accessory models and skin textures
    |    |
    |    |-backpack.md3 - backpack model
    |    |-backpack.tga - backpack texture
    |    |-helmet.md3 - helmet model
    |    |-helmet.tga - helmet texture
    |
    |-body.mdm - the body mesh
    |-body.tga - the body (torso) texture
    |-legs.tga - the body (legs) texture
    |-body_default.skin - the "default" body skin
    |-head.md3 - the head model
    |-head.tga - the head texture
    |-head_default.skin - the "default" head skin

Note: only allied and axis as types of players were taken into consideration here. In case another party is added, like civilians, it can slot in next to the Allied and Axis directories.

Workflow
Through working with this model system, we've setup a set of procedures that makes getting the models into the game relatively fast and painless. First of all we created a MAX file that contains the base biped with a bunch of weighted dummy triangles around it to ensure every single bone that will ever be used in game is actually referenced. This MAX file has only 1 frame, frame 0, and this frame gets exported into a SKL file that is used to create the base MDX.

Next to that, there is a set of MAX files that contain our animations. These MAX files use the same dummy mesh as the base frame. Because MDX files in a set all must have exactly the same bone setup, this method ensures that that will be the case. These MAX files are then exported to SKL files ready for converting into MDX.

The last set of MAX files is the meshes. They are single frame and the biped setup is the animation frame used to create the collapse map for LOD.

To convert everything into MDM and MDX, a batch file and a file tree that mirrors the layout of the one used by the game are combined to make it all happen with one single run of the batch file.

The picture at the right shows the basic layout of the tree and a here is a little section from the batch file, that sits next to the BuildMDS executable in the 'Player Models Exporting' directory:

@echo off

echo Generating Base MDX
buildmds source/animations/human/base/base -mdx -destdir source/animations/human/base

echo Generating Human/Base animations
buildmds source/animations/human/base/body -mdx -destdir output/animations/human/base

echo Generating Temperate/Allied meshes
buildmds source/meshes/temperate/allied/cvops/body -mdm -destdir output/models/players/temperate/allied/cvops
buildmds source/meshes/temperate/allied/engineer/body -mdm -destdir output/models/players/temperate/allied/engineer
buildmds source/meshes/temperate/allied/fieldops/body -mdm -destdir output/models/players/temperate/allied/fieldops
buildmds source/meshes/temperate/allied/medic/body -mdm -destdir output/models/players/temperate/allied/medic
buildmds source/meshes/temperate/allied/soldier/body -mdm -destdir output/models/players/temperate/allied/soldier

Due to the width of this document the lines above might wrapped, but copying and pasting it into notepad will show the proper formatting. Just in case it doesn't, every line starting with 'buildmds' takes two lines in this document but only one line in the batch file. It has the skl file listed on its line, the conversion type (-mdm or -mdx) and a destination directory.

The base MDX file sits in source/animations/human/base and all ski files should reference this file. By default, BuildMDS converts files only if there is a need for converting, which is the case if the source SKL is newer than the destination MDM or MDX. This check also applies to the base MDX. If it's newer than the MDM or MDX that is dependant on it, then this will get re-converted.

Some Generic Hints and Tips
For efficiency and to ease maintenance it would be nice if every animation sequence got its own mdx file.

Multi Player and Single Player won't have to duplicate their meshes and animation data anymore. They'll use the same meshes and animation data will be referenced through characters and animation groups.

Because the animation logic behind human players will be the same, you should only ever need one single animation script for the whole human set. Custom animations can be played by combining the script with a different animation group.

maybe someone have a idea where to host it

p.s. maybe soon i m able to create a tutorial for working playermodels. with the great help of C

[twt_thunder]

great ischbinz… well about the hosting we could host it on my webandgames domain…(i never use it to anything good anyway…)

but of course we would have to get “green light” from SD!!

[private101]

cant believe it was never released

mebe next ET birthday SD will be nice to us?

XD

[Tyrlop]

[QUOTE=private101;186682]cant believe it was never released

mebe next ET birthday SD will be nice to us?

XD[/QUOTE]
this is my biggest wish, the only wish i have in my entire life is to get mdm tools. so many things can be done with those they have a high value

[twt_thunder]

this is my biggest wish, the only wish i have in my entire life is to get mdm tools. so many things can be done with those they have a high value

you can use lightray…

[private101]

ikanattos tool still works too…

but its a bitch to have to re-physique stuff XD

but then again, i think the mdm tools would of had it too…

with mdm tools my valentines mod might have had females with bigger ( . Y . )

currently its regular sized RTCW models

thank god the axis medic mdm didn’t have spare pockets, or making suits for the guys would of been a bitch too :o

[kamikazee]

The problem with ikanatto’s tool is that 1) it’s not portable to just any platform and 2) it still needs RtCW’s MDS format, which is equally hard to find an exporter for.

[private101]

true dat…

well, is all good for me, as my 3ds max 5 works with ticals exporter…

and as to that, u still need the MDS format for the true buildmds with mdm and mdx support, if you look at the above post, buildmds is still looking for a .skl file, which is what the build mds uses for mds files…

the only difference is that its a different version of skelout, aka, has a version 2 option, which allows it to build mdm and mdx from said skl files

so regardless, the same rules apply…

ufortunately 3ds max 3 and 4 torrents are like non-existent, and all the max 5 ones that i used to get my copy of max 5 are dead

and im pretty sure that if you’re on linux or mac you could bug someone into helping you out, it takes about 2-3 mins to setup and run… but there is the skelout and buildmds problem still…

(if you want ill test it under wine for you, if youre talking about linux that is)

[ischbinz]

boh you don t neeed the 3000€ 3dsmax -
only lightray is needed - maybe milkshape for making the model itself -
the results are really good -
only one bug inside the expoted mdm of lightray - they store no “LOD” so parts of it get lost in distance -
but i think this bug can be fixed soon

this model will released @ 01.03.2009

[twt_thunder]

“LOD”… what’s that?

[nUllSkillZ]

Level Of Detail

Some of the models (md3) exist in two or three variations.
If a player is farer away a the model with less triangles is used.
Not sure where the border is.

[kamikazee]

In context of the player models, another concept of LOD is used. The models basically exists of points which form triangles and they store a map of points which can be removed to when the model is seen from afar. When going closer, more and more of the original model is shown, hence an optimal rendering.

[C11]

That is right kamikazee, playermodels use a more dynamic implementation of LOD.
It is easy to check out LOD on a playermodel in devmode…

/devmap oasis
/cg_thirdperson 1
/cg_thirdpersonangle 230
/r_showtris 1

and then change LOD (without the need to move the camera further away from the model):
/r_lodbias 100
/r_lodbias 200
/r_lodbias 0 is the default setting

[twt_thunder]

found this in gtk radiant 1.3.8 so it seems they released some notes anyway :

Putting New Models in Quake III Arena
Based on original notes by Paul Steed
Edited by Paul Jaquays

Edited 12/22/99 by ps

QERadiant.com thanks John Hutton for re-formating this manual into a more web friendly version

The purpose of this document is to explain how to set up a model for Quake 3 Arena, create the necessary animation and conversion files, and then export it into the MD3 format required by the game. It is intended to be informative only and not a tutorial on building or animating models.
The player models for Quake III Arena were built using the commercial modeling software, 3D Studio Max R2.5 (3ds Max) by Kinetix. These models were then animated using Physique and Biped, components of a plugin for 3dsMax called Character Studio (also by Kinetix). The following instructions assume that you will model and animate with 3dsMax and Character Studio.

1. Setting up the Files
   Begin in your Quake3 directory. If you don’t have one already, create a baseq3 directory. Inside the baseq3 directory, create a models directory. Inside the models directory, create a players directory. Inside the players directory, create a directory with the name of your model (we will use [character] in this document to represent information requiring the name of the model). It is generally a good idea to create a ‘work’ directory under [character] so that the [character] directory itself remains uncluttered. Place all versions of your model and temp textures here, saving the [character] directory purely for the finished model files.
2. Building and Naming the Mesh
   The mesh should be built keeping in mind the game engine needs three distinct body part grouping: the head, the upper body, and the lower body. These groupings can consist of different parts or sub-objects, but keep in mind too many sub-objects does impact performance and game play speed. A good rule of thumb is to consolidate your objects (i.e. attach them to each other) as long as they remain a part of a major group. For example, you decide to create a character that has its arms as separate objects for easier animation. Unless the arms or torso has different textures assigned to them go ahead and attach the arms to the torso. It may be more difficult to assign the vertices to the biped skeleton later on, but the efficiency of the model is much better. However, if you must keep the limbs detached for unique shader assignment then keep the following naming conventions in mind:
   2.1 Head Geometry
   All head geometry needs to begin with lower case ‘H_’ (h_head, h_glasses, h_hat, etc…). Keep in mind that the head has no animations itself other than to respond to player mouse-look input.
   2.2 Upper Body Geometry
   All upper body geometry needs to begin with lower case ‘U_’ (u_torso, u_arms, u_abdomen, etc.) This is your model’s torso and arms. The individual animations for the upper body are listed below.
   2.3 Lower Body Geometry
   All lower body geometry begins with lower case ‘L_’ (l_hips, l_legs, l_lfoot, l_rfoot, etc…). This is your model’s buttocks, legs and feet. The individual animations for the upper body are listed below.
   2.4 Tags
   Tags are connection points for other model parts and represent the limited hierarchical system of the game. They include links between the three character body parts and the weapons. Keep in mind that these tags are representations of geometry so they can be animated to represent that geometry. For example, tag_head represents the head, tag_torso represents the torso and tag_weapon represents the weapon. This is important to understand since for example, any time the character is performing a locomotive animation, the upper body can and will animate independently of the lower body, using the relative position of the tag as a base or ‘home’ position. The tags for the body parts and weapons are named tag_weapon, tag_torso and tag_head.
3. Texturing
   Once you finish building your character go ahead and attach it to your biped and do some basic test animations to make certain the mesh doesn’t deform in weird ways. Turn edges, ad faces, whatever you need to do to make sure that while animating, the character retains its mesh integrity. Handing the mesh over to another artist to assign UVW’s or assigning and texturing yourself without testing the animation integrity of the mesh is very risky. Major modifications after UV assignment can cost you valuable time resulting in re-assigning not just the UV’s, but re-attaching the mesh to your biped as well. Once your model is ready, go ahead and apply the texture to it. Typically the textures used in Q3A consist of one 256 x 256 texture for the body and one 128 x 128 texture for the head. Keep in mind that it’s best to consolidate your texture on a single page rather than break it up into smaller pages. Also some video cards cannot process a texture size larger than 256, so making a high-rez 1024 x 512 texture just won’t be seen since the card will knock it down to 256 x 128 to digest it.
4. Set Up for Animation
   Once the character is textured or skinned, bring the mesh back into 3dsMax (2.5) and attach it to an adjusted Biped using the Character Studio plug-in. As a rule of thumb, it’s always better to just assign the mesh to the biped using the default settings and then manually assign vertices to appropriate skeletal ‘limbs’.
5. Animation
   When animating the character, keep all animations in one file. It’s crucial that the animations adhere to a specific order that pertains to the separate body parts as this supports our current tag system.
   Basically the order of animations goes: full body (animations that combine both upper and lower), upper body, and lower body. Each character file has the following animations in them and for now that’s all the modeler is allowed. The division is basically death (all body parts), extraneous upper body, and dedicated locomotive animations. That way all the upper body animations can be performed at any time, separate from whatever it is that that lower body animations may be doing. There is a set number of animation types which are (in order):
   death1 (approx. 30 frames)
   death2 (approx. 30 frames)
   death3 (approx. 30 frames)

taunt (approx. 45 frames)
weapon attack (exactly 6 frames)
melee attack (exactly 6 frames)
change weapon (exactly 9 frames)
weapon idle (exactly 1 frame)
melee idle (exactly 1 frame)

crouched walk (approx. 10 frames)
walk (approx. 15 frames)
run (approx. 12 frames)
backpedal (approx. 10 frames)
swim (approx. 10 frames)
jump forward (approx. 10 frames)
jump forward-land (approx. 6 frames)
jump backward (approx. 10 frames)
jump backward-land (approx. 6 frames)
standing idle (approx. 10 frames)
crouched idle (approx. 10 frames)
turn in place (approx. 8 frames)
A good rule of thumb is to create an idle pose at the frame right after the final death frame. Keep this pose for the entire lower body and center of mass of the biped up through melee idle frame since any animation by the lower body during these frames will not register during the grab process. Similarly, once the animations for the lower body start, copy the pose for the upper body at the weapon idle frame to the first frame of the crouched walk animation and don’t animate the upper body at all after that frame. This allows you to more closely approximate what happens during the game where the upper body is basically just along for the ride as the lower body carries it along via the tag_torso.
Keep in mind that an animation.cfg has to be generated for each character that is a direct reflection of your animation file above.
6. Setting up Tags
After the modeler is satisfied with the animations for the character, it’s time to bring in the tags that up until now, have kept in a separate file. This is milestone mark that lets the modeler know that the character is nearly complete. ‘Merge’ the tags into your scene. Turn off ‘inherit scale’ for the tags under the hierarchy/link command panel in Max. Then, assign a Physique modifier (Character Studio), linking them to specific areas in the biped:
tag_torso is linked to the Biped ‘pelvis’
tag_head is linked to the Biped ‘head’.
tag_weapon is linked to the right ‘hand’.
6.1 Animate Body Tags
Now, go in and actually animate the tag_torso so that it matches the default position (established previously at approximately the standing idle frame- from the top view it looks like a perfect 90 degree triangle with the base half as wide as the length, pointing forward) when appropriate. “Appropriate” means that as the character goes through the lower body animations, if the triangle is pointing anywhere else but forward, the upper body will point that way as well since to the code the upper body IS the tag. This works out to the modeler’s advantage, though because even if the upper body LOOKS crazy in the animation you simply rely on the tag representation to compensate for it.
6.2 Handling Weapon Tags
Tag_weapon is a bit different. Basically there is no difference between view model weapons (the weapon as seen by the player when it is in use by his or another player) and the world model weapons (weapons as they are found rotating in the maps) in Quake III Arena. However, for visually clarity and identification, they are doubled in scale when they become seen as world models. They are the same object. This reduces the number of models needed the game and creates an overall more efficient system. Unfortunately a drawback to the system is that there can be only one firing animation for the character. Thusly all weapons need to fit within the grip of the character regardless of size or geometry. This also makes it impossible to see hands on your weapons or otherwise perform vertex animation on the weapons other than barrel rotations vis the tag system (tag_barrel).
Since the placement is always the same for the character’s hands on the weapons , create the animations to the point where it begins the weapon attack sequence. Then merge one of the weapon models into the character file as a guide. The weapons have a nested triangle of same dimensions as the tag_head and tag_torso triangles (each weapon in the game has this triangle saved with it. Move the weapon into a horizontal firing position (using the side view) to about where the character would be holding the weapon correctly. Then move the character’s hands into the appropriate position and link the weapon to the character’s right hand.
When you get to the point where you bring in the tags, make a snapshot of the weapon, hide the original and simply delete all the vertices and faces of the copy of the weapon object except for the nested triangle. Rename it tag_weapon, turn off the ‘inherit scale’ attributes (very important), and assign Physique to it (linking it to the ‘right hand’ of the biped) and voila. Ready to export.
Level of Detail
Each of the Quake III Arena player characters have a base model and two lower polygon versions of the model (to help with speed issues). For use in the game, the three levels of detail are file formatted as follows:

[character].[file extension]
This is the highest detail model for close up viewing
[character]_1.[file extension]
This is a slightly lower polygon model for mid distance viewing
[character]_2.[file extension]
This is the lowest polygon model for long distance viewing.
Level of detail means you need to make three versions of your model to get the best performance during gameplay. Each version needs to have the same textures assigned and same animations assigned to them in order to work in the game. The numbers you need to shoot for are 800 faces for the highest level, 500 faces for next level and 300 for the lowest level. This works out roughly to be a 60% drop in each LOD, but your numbers will vary in order to maintain mesh integrity. Most LOD’s created in Q3A were done with the plugin called MRM (multiple resolution mesh) by Intel. The stock Optimize modifier or manual optimization techniques can be applied.
8. Exporting
Once the tags are in place (also with the Physique modifier attached to them) the model is ready to export to an ase(ascii) file. To make the models available for use in Quake III Arena, the model was exported to a native 3dsMax ASCII format file called an ‘.ase’ file. This export option in Max has several check boxes to tweak and then just exports the character with its animation data (via Character Studio) to a huge ase/ascii file. Under ‘Output Options’ make sure the ‘Mesh Definition’, ‘Materials’, ‘Transform Animation Keys’, and ‘Animated Mesh’ boxes are checked. Under ‘Mesh Options’ and ‘Object Types’ make sure ‘Mapping Coordinates’ and ‘Geometric’ are the only boxes checked, respectively and let it run. Your ‘Time Configuration’ must reflect a ‘0’ starting point up through the last frame of your animation. The native Max exporter will rely on the time configuration as a guide on which frames to actually grab during the conversion process. Of course there will be better exporters available in the future…this is just how it was done for the characters in Q3A.
9. Animation Config File
The character’s animations are controlled by an ‘animation.cfg’ file where the model maker specifies reference frames and frame rates. The animation.cfg file is a text file (originally created with MS Excel) which contains the frame and animation sequence data. Place this in the model’s directory. Note, when the modeler is testing the model in Quake III Arena, changes to the animation.cfg can be made without having to re-grab the model…just do a ‘vid_restart’ at the cvar command line prompt.
Edit an animation.cfg file which matches the frame/animation sequences and place it in the character’s directory. Each animation can have different frame rates that the modeler can tweak, save out in the animation.cfg, hit ‘vid_restart’ to see the change right away in the game (no need to re-grab the model). The file for visor is shown here below in it’s entirety. You may clip this portion of the file out and use it as the basis for your own animation files.

////////////////////////////////////////////////////////////////////////////////

// animation config file

sex m

headoffset 0 0 0
footsteps normal

// first frame, num frames, looping frames, frames per second

0 30 0 25 // BOTH_DEATH1
29 1 0 25 // BOTH_DEAD1
30 30 0 25 // BOTH_DEATH2
59 1 0 25 // BOTH_DEAD2
60 30 0 25 // BOTH_DEATH3
89 1 0 25 // BOTH_DEAD3
90 40 0 20 // TORSO_GESTURE
130 6 0 15 // TORSO_ATTACK (MUST NOT CHANGE – hand animation is synced to this)
136 6 0 15 // TORSO_ATTACK2 (MUST NOT CHANGE – hand animation is synced to this)
142 5 0 20 // TORSO_DROP (MUST NOT CHANGE – hand animation is synced to this)
147 4 0 20 // TORSO_RAISE (MUST NOT CHANGE – hand animation is synced to this)
151 1 0 15 // TORSO_STAND
152 1 0 15 // TORSO_STAND2
153 8 8 20 // LEGS_WALKCR
161 12 12 20 // LEGS_WALK
173 9 9 18 // LEGS_RUN
182 10 10 20 // LEGS_BACK
192 10 10 15 // LEGS_SWIM
202 8 0 15 // LEGS_JUMP
210 1 0 15 // LEGS_LAND
211 8 0 15 // LEGS_JUMPB
219 1 0 15 // LEGS_LANDB
220 10 10 15 // LEGS_IDLE
230 10 10 15 // LEGS_IDLECR
240 7 7 15 // LEGS_TURN

//////////////////////////////////////////////////////////////////
10. The Conversion Process
The models need to be run through id’s custom md3 conversion/‘grabber’ program. The program uses the information in the Quake Data text file ([filename].qdt) to grab and convert the 3dsMax files.
10.1 The Conversion File
Create a “Quake Data” text file for the model with the extension “.qdt”. The contents for our [character].qdt file would read something like:
$asecanimconvert models/players/[character]/[character].ase -playerparms 92 155
$asecanimconvert models/players/[character]/[character]_1.ase -lod 1 -playerparms 92 155
$asecanimconvert models/players/[character]/[character]_2.ase -lod 2 -playerparms 92 155

10.1.1 “$asecanimconvert”
This is the grabber program executable.

10.1.2 “models/players/[character]/[character].ase”
This is the path to the model’s .ase file. The program looks for files starting in your Quake3\baseq3 directory.

10.1.3 “-lod 1” or “-lod 2”
This tells the converter that this is the first level of reduced detail for the model. The value “-lod 2” is for the second, or lowest level of detail for the model.

10.1.4 “-playerparms 92 155”
This tells the converter which frame the upper body anims only start (first value) and which frame the lower body only anims start (second value). The numbers here are only used as examples
10.2 Run the Conversion
When the qdt file is set up correctly, run the grabber by opening MSDOS command prompt, going to the quake3 directory containing the model files and typing in ‘q3data [character].qdt’
11. Review the Model
Load up Quake 3 Arena. Go to map Q3DM0 (or any map containing a mirror). Bring down the console and type “\model [character name]”. Hit your Show Score key (default is TAB). You should see your new model here. Tweak the frame rates in your animation.cfg file and save them. Type in “\vid_restart” on the console and hit enter to see the changes.