Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 119

  Click here to go to the first staff post in this thread.   Thread: Player Models Documentation

  1. #81
    have a look at jaymod forums

  2. #82

    Re: Player Models Documentation

    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?

  3. #83

    Re: Player Models Documentation

    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
    Quote Originally Posted by MistaSparkle View Post
    and every time Nail comes in and ruins it

  4. #84

    Re: Player Models Documentation

    Quote Originally Posted by VonBulow View Post
    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?
    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. --> import plugin for 3DSMax 6
    If you don't do it, someone else will!

  5. #85

    Re: Player Models Documentation

    could really neede it!!!

  6. #86

    Re: Player Models Documentation

    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

    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.
    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)
    // 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.
    // 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
    // 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)
    // 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.
    // NUMMDXFILES is the number of mdx files we generate from this skl file using this definition file
    // 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:
        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:
        <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/".
    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:
    |-[animations] - contains animation group files (*.anim)
    |    |
    |    |-[human]
    |    | |
    |    | |-[base] - contains human/base animation set files (*.mdx/*.aninc)
    |    |-[scripts] - contains animation scripts
    |    |
    |    |-[<theme>]
    |        |
    |        |-[allied] - contains Allied character definitions
    |        |
    |        |-[axis] - contains Axis character definitions
                |-[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:
        |-[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
        | - the "default" body skin
        |-head.md3 - the head model
        |-head.tga - the head texture
        | - 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.
    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

  7. #87

    Re: Player Models Documentation

    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!!
    I'm an engineer, lets just asume I'm right...

  8. #88

    Re: Player Models Documentation

    cant believe it was never released

    mebe next ET birthday SD will be nice to us?

    Last edited by private101; 13th Feb 2009 at 09:41.

  9. #89

    Re: Player Models Documentation

    Quote Originally Posted by private101 View Post
    cant believe it was never released

    mebe next ET birthday SD will be nice to us?

    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

  10. #90

    Re: Player Models Documentation

    Quote Originally Posted by Tyrlop View Post
    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....
    I'm an engineer, lets just asume I'm right...

  11. #91

    Re: Player Models Documentation

    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

  12. #92
    Occasionally AFK
    Join Date
    Apr 2005
    't looks like a room
    Most Recent Awards:

    Re: Player Models Documentation

    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.
    "Respect is everything" - GTA2
    "Notheeeeeng is final." - Bongoboy

  13. #93

    Re: Player Models Documentation

    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)
    Last edited by private101; 15th Feb 2009 at 00:03.

  14. #94

    Re: Player Models Documentation

    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

  15. #95

    Re: Player Models Documentation

    "LOD".. what's that?
    I'm an engineer, lets just asume I'm right...

  16. #96
    Tapir Stalker nUllSkillZ's Avatar
    Join Date
    Jan 2004
    Most Recent Awards:

    Re: Player Models Documentation

    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.

  17. #97
    Occasionally AFK
    Join Date
    Apr 2005
    't looks like a room
    Most Recent Awards:

    Re: Player Models Documentation

    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.
    "Respect is everything" - GTA2
    "Notheeeeeng is final." - Bongoboy

  18. #98

    Re: Player Models Documentation

    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

  19. #99

    Re: Player Models Documentation

    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 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.
    I'm an engineer, lets just asume I'm right...

  20. #100

    Re: Player Models Documentation

    Quote Originally Posted by maddness View Post
    This is a wonderful website buddy and an informative post!!! i am new here and i found this site very interesting and informative ,, you are a professional blogger i think i have a great interest in such things…thank you for the post buddy and keep on posting nice stuff like this in future as well.
    Quote Originally Posted by Jameskarl View Post
    Wolf ET source was release at Having recently discovered. For private using, but for teams intending the great mode which will improve ET reputation and bring more people.
    Bots are getting penetrant nowadays


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts