Jump to content
  • News

    • By Thunder in TWT's ET Bible
         0
      Contents
      Model Types Player Models Weapon Models Tags Animations Paths Skins And Textures MD3 Limits Model Types
      An MD3 model contains a set of meshes and tags. Some in-game Quake models are actually composites of several MD3 files. For example, a player model consists of head.md3, upper.md3, and lower.md3 files. Tags within these files tell Quake how to assemble the model files into one single model.
      Misfit Model 3D is capable of loading and saving a single MD3 file, or loading and saving all files in a player model as one model.
      If you attempt to load a file named head.md3, upper.md3, or lower.md3 and the other two files are present, MM3D will ask you if you want to load all sections as a player model. Answer Yes to load all three files as one model. Answer No to load only the specified model file.
      When you save a model, it will be saved as a player model if the following conditions are met. If any of the following conditions are not met, the model will be saved as a single MD3 file.
      The saving file name is head.md3, upper.md3, or lower.md3 The model contains at least three points; one aech named tag_torso, tag_head, and tag_weapon. The model contains at least one group beginning with h_ (for head meshes), u_ (for upper body meshes), and l_ (for lower body meshes). The MD3_composite meta data value is not set to 0 (zero) If the model is saved as a player model the animation.cfg file will be created automatically. If the model is saved as a single file, no animation.cfg file will be created.
      Skin files are read automatically for player and non-player models. Skin files are never created or modified by MM3D. If you wish to change or create a skin file you must do this step manually.
      Player Models
      A typical MD3 player model might be 60 GL units tall and 15 wide (would be a human size). The base of the feet should be at -24.
      Player models consist of three model files: head.md3, upper.md3, and lower.md3. Usually these correspond to head, torso, and legs respectively. These three models are connected with tags (Points in MM3D). The weapon the player is holding is also connected to the player model with a tag.
      Typical Tags for player models:
      Model File Tags in model head.md3 tag_head upper.md3 tag_head, tag_torso, tag_weapon lower.md3 tag_torso  
      You can have multiple skins for a player model. Each md3 file should have a corresponding skin file (head_default.skin, lower_default.skin, upper_default.skin). Usually there are at least three skins for a player model: _default.skin, _red.skin, and _blue.skin. For more on skins see Skins and Textures.
      Player models need an animation.cfg file to specify which frames correspond to in-game actions. An animation.cfg file might look like the example below. All animation sequences should have at least one frame.
      NOTE: It is very important that the animations in your model are in the same order as the Quake MD3 animations listed in the animation example. Animations that are out of order or missing may cause problems with the animation export.
      Head models do not have animations, they are joined with the upper body mesh and follow the tag_head point in that mesh. If you want to animate the head, you can have the tag_head way out of bounds in upper.md3 and do all the head animations in the torso (upper) meshes. You should still make a head model because it is used in the HUD).

      Example animation.cfg:
      //Quake3 player animation file sex m footsteps normal // first frame, num frames, looping frames, frames per second 0 32 0 25 // BOTH_DEATH1 (twirl death) 32 1 1 25 // BOTH_DEAD1 (end of twirl death) 32 35 0 20 // BOTH_DEATH2 (other side twirl death) 67 1 1 20 // BOTH_DEAD2 (end of other side twirl death) 68 25 0 25 // BOTH_DEATH3 (backflip death) 93 1 1 25 // BOTH_DEAD3 (backflip dead) 94 39 0 15 // TORSO_GESTURE 133 7 0 15 // TORSO_ATTACK (regular attack shooting) 140 11 0 15 // TORSO_ATTACK2 151 5 0 15 // TORSO_DROP (drop weapon) 156 6 0 15 // TORSO_RAISE (raise weapon) 162 31 0 10 // TORSO_STAND 193 11 0 10 // TORSO_STAND2 94 12 12 15 // LEGS_WALKCR 107 12 12 15 // LEGS_WALK 120 12 12 17 // LEGS_RUN 133 14 12 17 // LEGS_BACK 148 12 12 14 // LEGS_SWIM 159 6 0 8 // LEGS_JUMP 167 6 0 12 // LEGS_LAND 172 6 0 10 // LEGS_JUMPB 178 6 0 10 // LEGS_LANDB 185 6 6 5 // LEGS_IDLE 192 7 6 5 // LEGS_IDLECR 200 6 6 20 // LEGS_TURN Weapon Models
      A typical MD3 weapon might be 5 GL units wide and 45 long. They usually would have no animations, although it should be possible to add animation by modifying the Quake 3 code. You can also add texture animations with shaders. Weapons have a tag named tag_weapon that attaches to the player model's tag_weapon tag in the upper body mesh.
      Tags
      Quake 3 uses tags to join models to each other. MM3D loads tags as points, so if you want to create a tag make a Point (more details about points). The point name should be whatever you want the name of the tag to be. The red axis of the tag is forward, the blue axis of the tag is up, and the green axis of the tag is left. For example you want the red side of that tag to face front for tag_weapon.
      The MD3 orientation for tags is not the default orientation for MM3D points, so you must rotate any points you create into the correct orientation.
      Animations
      MD3 animations specify vertex positions for each vertex for each frame of each animation. This can be tedious. When creating a model from scratch it is usually easier to save the model in MM3D format and create skeletal animations. Then when you are ready to export to MD3, convert the skeletal animations to frame animations using the Animation Sets Window and save as an MD3.
      Because of the enormous overhead of saving undo information for animations upon insertion and deletion of vertex and face primitives, you are not allowed to add or remove primitives from a model that has frame animations. You may, however, merge another existing model into the one you are working on. This is another reason why it is best to work with MM3D files and skeletal animations and only export MD3 files when necessary.
      MM3D will save all frame (vertex, mesh deformation) animations when saving as MD3.
      Paths
      When an MD3 model is saved, path information is stored in the model. Quake3 uses a VFS (virtual file system), and you must tell Quake3 where your files are located in this VFS. For example a player model might be located in the Quake3 VFS at models/players/man/. So all the models and textures should probably be located in there and when you make a pk3 file (zip file really), it should contain that directory hierarchy.
      We still need MM3D to save paths and filenames with models/players/man/. This is where the MD3_PATH metadata attribute comes in. You should set the MD3_PATH metadata attribute to models/players/man/. MD3 Filter will append all filenames that gets stored in the MD3 file to MD3_PATH. So your body.tga texture when saved would be written in the MD3 file as models/players/man/body.tga. When quake3 opens it that is where it will look in the VFS.
      Note: The Quake 3 VFS does not start with a /.
      Skins and Textures
      The MD3 filter can load any image type as a texture if MM3D can use it. When looking for a texture file it ignores the extension and finds any loadable texture with the the right file name (regardless of extension). For example if the model says it should use a file called body.tga, MD3 Filter could use body.png if it exists.
       
      MD3 filter looks for texture images and skin files in the same directory as the model regardless of the values for paths contained in the model.
       
      In general the MD3 filter attempts to load skins in the following manner:
      First it will look for .skin files with the following pattern. {modelName}_*.skin It will load all images inside those skin files. It will set the material to the image contained in {modelName}_default.skin. If no .skins files are there it will use shaderName specified in the model to look for a texture file. If that does not exist it will look for a valid texture whose filename matches {meshName}.*  
      When saving MD3 models it sets the shader name to the name of the texture that is assigned to the group. Also note that Quake3 by default only loads TGA and JPG files.
      A skin file should be of the form indicated below.
      mesh_name,MD3_PATH/textureFilename
      and example upper_default.skin:
      u_body,models/players/man/default_b.tga
      u_cape,models/players/man/default_c.tga
      Currently MD3 Filter will not load .shader files. These are files that could do complex OpenGL operations. You can still use shader files with your model inside Quake3 by creating the shader manually. Here is a example:
      Set group texture to meshName.tga Create a shader file called meshName.shader Quake3 should see meshName.shader and use it because MM3D set it to look for meshName.* and Quake3 should take the shader file first. Check your model in Quake3 MD3 Limits
      The MD3 file format has several limits that you should consider when making a model for this format. These are outlined below. If your model has more that the MD3 limit, the file will not be saved correctly and you should get a error message.
      Only faces and verticies in a group get saved. The MD3_PATH+file name cannot be longer than 63 characters.  (Textures and model names) The group name and point name cannot be longer than 63 characters. Maximum of 1024 animation frames Maximum of 16 Points (Quake 3 Tags) Maximum of 32 Groups Maximum of 256 Textures per Group Maximum of 8192 Triangles per Group Maximum of 4096 Verticies per Group                  
      Source:(http://www.misfitcode.com/misfitmodel3d/olh_quakemd3.html)
    • By Thunder in TWT's ET Bible
         0
      Wolfenstein: Enemy Territory
      Custom Model Depot Yard
      MDM MDX unofficial specification
      Here is the data structure of mdm and mdx which I am using in the tool. but there is no guarantee to ensure this document saying truth. So use these info at your own risk.
      Player model in ET
      Each character used in ET is assigned in characters of pak0.pk3. There are some files to define a character, they refer what class it is, what mesh it uses, what animation group it uses, what mesh it uses when it is undressed, what model its head is.
      The mdm is a mesh data file for player models. mdm includes the surfaces and tags. The surface is a geometric data of model or polygon data. Skinning the surfaces with textures, the model appears in ET. The tag is a position info to attach another model to this model. The tag has its position and degree at each frame.
      The mdx is a animation data file which contains bone structure and frames. The bone is a skeltal model data. Each bone has its length and its parent bone. The frame is a 3D-position data of the bones. one of the mdx frames have slightly different bone position compared with the previous frame. Thus a series of those frame will make an animation of a action. Ordinarily the mdx has several(or massive) number of animations in it.
      A combination of mdm and mdx makes the polygons live, act, be a player.
      This system is extremely good for sharing the animations which are used by the similar models. For example, ET only has one mdx( precisely there are more but they are a little ) to be used by the player models, 5 classes of allies and axis team. If we need to create the animation data for each model as like RtCW, The file size will be more bigger and memory requirements will be higher.
       
      However the combination of mdm and mdx is valid when they have the same bone structure. This means that we must create new mdx if we make a non-humanlike model or a small or tall person. I myself think that separating the model data into a set of meshes, tags and bone structure and frames is better if we want to make a small or large human model.
       
      MDM Data Structure
      [MDM] | |--[MDM HEADER] | |--[Surface] | | | |--[Header] | |--[Vertex] | |--[Triangle] | |--[Collapsemap] | |--[Bone Reference] | : | |--[Tag] | : | |--[EOF] [MDX] | |--[MDX HEADER] | |--[Frame] | | | |--[Frame State] | |--[Compressed Bone Frame] | : | |--[Bone] | : | |--[EOF] Detail Data Structure
      Here is a data specifications of mdm and mdx. Repeatly I say, they are not guaranteed to be right.
      MDM HEADER
      MDM HEADER is the header section of mdm. There are information of version, location, Level of Detail, number and offset of the surfaces and tags and so on.
      MDM HEADER Name Type and Size Description MDM Identification char * 4 Magic Number. It should be 'MDMW'. MDM Version int32 * 1 mdm version. It should be 3. MDM Name char * 64 Name and virtual path to this mdm. LoD Bias float * 1 These are coeffcients of Level of Detail. LoD Scale float * 1 Number of Surfaces int32 * 1 Number of surfaces this mdm has. Offset to Surfaces int32 * 1 Offset to the address of the surfaces from this header. Header size is fixed then this value also fixed. Number of Tags int32 * 1 Number of tags this mdm has. Offset to Tags int32 * 1 Offset to the address of the tags from this header. Offset to EoF int32 * 1 Offset to EoF of this mdm. Otherwords this mdm file size. Surface
      Surface is a mesh data which will be seen as a part of the player model in ET. Generally a mdm has several surfaces. They are almost separated upper and lower parts, also hands and torso. Example:
      MDM SURFACE HEADER Name Type and Size Description Surface Identification int32 * 1 ID or version of surface. It should be 0x00000009. Surface Name char * 64 Name of this surface. Generally it refers what part it is. Such as u_body, l_legs. Shader Name char * 64 Name and virtual path of the shader to apply this surface. The ET mdm has nothing here. The skin file defines what shader this surface uses. Shader Index int32 * 1 ?? I dont know what this means. However this is always 0. LoD Minimum int32 * 1 This determines the maximum LoD effect on this surface. Offset to MDM Header int32 * 1 Offset to MDM Header from this surface address. always negative value. Number of Vertices int32 * 1 Number of vertices this surface has. Offset to Vertices int32 * 1 Offset to the address of the vertices data from the head of surface data. Number of Triangles int32 * 1 Number of triagles(polygons) which consist of this surface. Offset to Triangles int32 * 1 Offset to the address of the triangles data from the head of surface. Offset to Collapsemap int32 * 1 Offset to the address of the collapsemap. The collapsemap is the list of triangle indices in order to apply LoD. This list indicates the triangle(or vertex?) will be omitted in that order. Number of Reference Bones int32 * 1 Number of the bones which are used when this surface will be rendered with calculating its vertices. Offset to Reference Bones int32 * 1 Offset to the address of the reference bone list. Offset to Next Surface int32 * 1 Offset to the next surface or this surface data size. Name Type and Size Description MDM SURAFCE VERTEX is a vertex data of this surface.
      MDM SURFACE VERTEX Name Type and Size Description Vertex Normalized Vector float * 3 Normalized vector of this vertex. Maybe used for lightening effect. Texture Coordinates float * 2 UV coordinates of the texture image. 3 vertices will cut an triangle image which their potisions are refered by this uv coords from the texture. This value is standardized so ranges from 0 to 1. Number of Bone Weights int32 * 1 Number of the bone weights which will affect this vertex. Weight is a element to determine where the vertex is. The vetex potision is calculated by summation of the multiple of the weight and its position of each bone.
      MDM SURFACE WEIGHT Name Type and Size Description Bone Index int32 * 1 Index number of the bone which affect the vertex. Weight float * 1 A coefficient how much this bone affects the vertex position. A summation of this value must be 1. Position Vector float * 3 The position vector of vertex when this bone is treated as an origin. Triangle is combinations of 3 vertex indices to buld a polygon.
      MDM SURFACE TRIANGLE Name Type and Size Description Vertex Indices int32 * 3 3 vertex indices to make a polygon. Collapsemap data is not specified yet. Reference Bone data is the continuous number of the bone index. They are int32 and their amount is same as the number of Number of Reference Bones in Surface Header.
      Tag
      Tag is popular for Quake3-Engine-Based game modders. Tag is used to attach another model to this model. mds which has been used in RtCW has different tag data type. mds treat the tags as bones so the position of tag will be changed at each frame.
      MDM TAG Name Type and Size Description Tag Name char * 64 Name of this tag. Rotation Matrix float * 9 A 3*3 rotation matrix to calculate another model's pose or angles. Attach Bone Index int32 * 1 Index of the bone which this tag is attached to. Position Vector float * 3 The position vector of tag when attached bone is treated as an origin. Number of Reference Bones int32 * 1 The number of bones to calculate the tag's parent bone position. Ther are from a root bone to the previous bone of the attached to. Offset to Reference Bones int32 * 1 The relative offset to the Reference Bones data from the head of this tag data. Offset to Next Tag int32 * 1 Offset to the next tag data or this tag data size. Reference Bone List int32 * Number of Reference Bones Index list of the Reference Bones. MDX HEADER
      MDX Header refers the version, numbers and offset of the frame and bone structure of this mdx.
      MDX HEADER Name Type and Size Description MDX Identification char * 4 ID of mdx, it should be 'MDXW'. MDX Version int32 * 1 MDX version, should be 2 for now. MDX Name char * 4 Name and virtual path of this mdx. Number of Frames int32 * 1 Number of the frames this mdx has. Number of Bones int32 * 1 Number of the bones this mdx has. Offset to Frames int32 * 1 Offset to the address of frames from the header. Offset to Bones int32 * 1 Offset to the address of bones from the header. Torso Parent Bone Index int32 * 1 Bone Index to be a torso parent. Offset to EoF int32 * 1 Offset to EoF of mdx otherwords size of this mdx. MDX FRAME
      Frame is a state of the skeltal model at a moment. It can be the scene of firing Panzer, or dying by the head shot, or Nazi salutling. There are 2 sections in Frame, Frame State and Compressed Bone Frame. Frame State refers the bounding box of this model at this frame and a base position which will be used as the parent bone by the root bone. Compressed Bone Frame is the bone position data at this frame. "Compressed" means that each data is not 32bit, but 16bit.
      MDX FRAME STATE Name Type and Size Description Bounding Box Vector 1 float * 3 The relation of 1 and 2 is diagonal. The box area created by using vector 1 and 2 to the box diagonal positions is called Bounding Box. The Bounding Box is used for checking collision or hitting box or trigger entity and so on. Bounding Box Vector 2 float * 3 Local Origin float *3 The origin position which is used at this frame. Bounding Sphere Radius float * 1 Another Bounding area, sphere type. Used for the explosion damage etc. Parent of Root Bone Tfloat * 3 The position used by calculatin of the root bone position. The Compressed Bone Frame follows after Frame State. It will repeat same times as the number of bones.
      MDX COMPRESSED BONE FRAME Name Type and Size Description Angle(Pitch) int16 * 1 These are used to calculate the rotation matrix of this bone. Angle(Yaw) int16 * 1 Angle(Roll) Type and Size (unused?) int16 * 1 Maybe this is inserted to make an unit of Compressed Bone Frame has 32bit order. Offset Angle(Pitch) int16 * 1 This is used to calculate where is this tag. Offset Angle(Yaw) int16 * 1 To know the bone position, you have to summation the vectors which are calcurated by using ( Parent Distance, 0 , 0 ) as a start vector, rotating it with Offset Angles.
      To convert angles to radian, just do this: Radian = 2 * 3.14 * Angle / 65536.0
      MDX BONE
      Bone Structure is like a puppet. A puppet has joints and fixed-length bones. Bones in ET is so. The meshed are attached around the bones. If a bone moves, mesh moves. If a bone is rotated, mesh is rotated as well.
      MDX BONE Name Type and Size Description Bone Name char * 64 Name of this boen. Index of Parent Bone int32 * 1 Index of the parent bone to calculate this bone position. Torso Weight float * 1 Coeeficient how much this bone tends to be like torso. Parent Distance float * 1 Distance from this bone's parent. Flag(?) int32 * 1 If this bone is a tag, this value is 1 or not, 0. but in ET there is no longer tags as bones, this is always 0. References and Thanks
      http://mojo.gmaxsupport.com/Articles/MDSFileFormat.html
      Chris Cookson speced the mds, and this is extremely helpful for ET modder as well. Thanks that great documents.
    • By Thunder in TWT's ET Bible
         0
      Unofficial Return to Castle Wolfenstein MDS File Format Spec v1.0 By Chris Cookson (cjcookson@hotmail.com)  
      Contents
      Introduction MDS In a Nutshell MDS Data Structures Limits The Collapse Map Poly Counts Introduction
      This document is my attempt at providing some documentation on the MDS format used in Return to Castle Wolfenstein. It's totally unofficial, so bear with me if certain areas are a little vague or inaccurate. Most of the information was gleaned by myself using a hex editor and many nights of MAXScripting, but huge thanks go to Ryan Feltrin for providing me with the crucial last bits of the MDS puzzle; Richard Crowder for getting me to continue working on my MDS importer (as well as providing loads of help and advice); and TiCaL for all his help. Cheers, guys!
      I'm assuming you're familiar with the basics of 3D, Quake 3 mods, and skeletal animation with smooth mesh deformation, so I won't cover these topics in much detail.
      MDS In a Nutshell
      So what's in an MDS file? The main things are:
      A skeleton, or hierarchy of bones, some of which represent tags (as in Quake 3) A number of triangle meshes, known as surfaces Animation frames in the form of skeletal poses Runtime LOD data for each surface: the intriguingly named collapse maps Tags are simply bones named with the special prefix "tag_" and work in a similar way to tags in Quake 3. In RTCW, they are mainly used as mount points for weapons, ammo packs, heads, mouths (for effects like cigarette smoke) and so on.
       
      MDS Data Structures
      These are the main data structures present in an MDS file:
      MDSHeader MDSBone MDSTag MDSFrame MDSCompressedBoneFrame MDSSurface MDSVertex MDSWeight MDSTriangle I've used a C/C++ like notation with explicitly sized types for clarity. For example, uint32 is a 32-bit unsigned integer, sint16 is a signed 16-bit integer and so on. floats are assumed to be 32 bits in size, and chars 8-bits. Note that as there are some hard limits on the numbers of certain structures, so the unsigned/signed distinction is probably overkill.
      MDSHeader struct MDSHeader { uint32 ident; // "MDSW" uint32 version; // 0x0004 char name[64]; // Model name eg. "body.mds" float lodScale; // LOD Scale float lodBias; // LOD Bias uint32 numFrames; // Number of animation frames uint32 numBones; // Number of bones uint32 offsetFrames; // Offset of animation frames (see MDSFrame) uint32 offsetBones; // Offset of bones (see MDSBone) uint32 torsoParent; // Index of torso parent bone uint32 numSurfaces; // Number of surfaces uint32 offsetSurfaces; // Offset of surfaces (numSurfaces * MDS_Surface) uint32 numTags; // Number of tags uint32 offsetTags; // Offset of tags (numTags * MDS_Tag) uint32 offsetEnd; // Offset of end of file }; This structure is located at the very start of an MDS file.
      The torsoParent index probably refers to the bone that controls the overall orientation of a player's torso.
      MDSBone struct MDSBone { char name[64]; // Bone name sint32 parentIndex; // Bone parent index (-1 if root) float torsoWeight; // 0.0 to 1.0 float parentDist; // Distance from parent bone to this bone's pivot point uint32 flags; // Bit 0 is set if bone is a tag }; Defines a bone used to deform the MDS model's surface meshes during animation. The torsoWeight value is apparently used to scale the torso rotation and torso parent bone.
      MDSTag struct MDSTag { char name[64]; // Name of tag float torsoWeight; // 0.0, 0.3 uint32 boneIndex; // Index of bone this tag is attached to }; Defines a tag/attachment point for weapons, MD3/MDC head models and particle effects. Each tag has a corresponding bone in the skeleton, with the same name as the tag (eg. tag_head).
      MDSFrame struct MDSFrame { float[3] bboxMin; // Bounding box min float[3] bboxMax; // Bounding box max float[3] localOrigin; // Local origin float radius; // Radius of bounding sphere (used for runtime culling) float[3] parentOffset; // Offset of parent bone from origin // Following this structure is a list of compressed bone frames MDSCompressedBoneFrame bones[numBones]; }; This structure is present at the start of every animation frame. Following each MDSFrame is a sequence of MDSCompressedBoneFrames, with one entry for each bone in the model's skeleton.
      The parentOffset vector defines the offset of the parent bone from the world origin.
      MDSCompressedBoneFrame struct MDSCompressedBoneFrame { sint16[4] angles; // Defines the bone orientation sint16[2] offsetAngles; // Defines the direction of the bone pivot from this bone's parent }; A bone keyframe that defines position and orientation per frame. The first 3 entries in the angles array are stored in (pitch, yaw, roll) order. The 4th entry is just padding and can be safely ignored (it's typically set to zero anyway). The offsetAngles are stored in (pitch, yaw) order.
      In RTCW, pitch, yaw and roll are defined assuming that +X is forward, -Y is right and +Z is up, with right handed rotations. For example, a positive pitch will tilt down towards -Z. To convert the compressed 16-bit angles into degrees, simply scale them by 360.0 / 65536.0.
      To obtain the origin of the bone's local coordinate system, create a rotation matrix from offsetAngles using its pitch and yaw values. Construct a 3D point with the parentDist value stored in the bone's MDSBone structure as the x component, with y and z components set to zero (ie. [parentDist, 0, 0]). Transform this point using the offsetAngles rotation matrix and add it to the bone's parent's origin to get the bone's own origin. If the bone has no parent, use the parentOffset coordinate stored in the MDSBoneFrame for this frame in place of the parent's origin.
      To correctly orient the bone, construct its rotation matrix from angles using the roll, pitch and yaw (in that order) values. Together with the bone origin, this rotation matrix defines the bone's coordinate system for the current frame.
      Take a look at MDSData.ms and MDSLoader.ms in my MDS Importer to see how I managed to load the bone information into gmax/max.
      MDSSurface struct MDSSurface { uint32 ident; // Always 0x0008 char name[64]; // Name of surface char shader[64]; // Name of shader uint32 shaderIndex; // Used in game only sint32 minLod; // Minimum Lod level sint32 offsetHeader; // Offset of this surface header, always negative uint32 numVerts; // Number of vertices uint32 offsetVerts; // Offset of vertices (MDSVertex * numVerts) uint32 numTris; // Number of triangles uint32 offsetTris; // Offset of triangles (MDSTriangle * numTris) uint32 offsetCollapseMap; // Offset of the collapse map (uint32 * numVerts in size) uint32 numBoneRefs; // Number of bone references (bones that influence this surface) uint32 offsetBoneRefs; // Offset of bone refs (uint32 * numBones) uint32 offsetEnd; // Offset of the end of this surface, from start of MDSSurface header. // The next surface (if there are more) can be found at this offset. }; A surface is a triangle mesh rendered using a single shader. Each surface has its own collection of vertices (each influenced by one or more bones) and triangles. The bone references aren't indexed by the MDSWeight structures, which instead index into the main bone list. The bone refs provide a list of all the bones referenced by a surface's MDSWeight structures, which is often less than the total number of bones in the model.
      The collapse map is a list of target vertices for each surface vertex. The mapping from a mesh vertex to a target vertex defines an edge collapse. By successively collapsing edges and removing triangles that become degenerate after these collapses, the surface can be simplified automatically. It's also possible to go the other way, adding triangles right back up to the original full level of detail. This is known as a progressive mesh system and is used by RTCW to dynamically adjust the individual levels of detail for all onscreen MDS models whilst the game is running. See the collapse map section for a few more details on this dead funky technique.
      The minLod is likely to be the lowest possible detail level. This is the point in the collapse map at which the engine should stop edge collapsing to prevent the mesh becoming noticeably distorted, even when in the distance.
      MDSVertex struct MDSVertex { float[3] normal; // Vertex normal vector. In base pose/model space I presume. float[2] texCoords; // Texture (s,t) co-ordinates uint32 numWeights; // Number of bone weights affecting this vertex uint32 fixedParent; // Stay equidistant from this parent float fixedDist; // Fixed distance from parent MDSWeight weights[numWeights] // List of weights follows }; A surface vertex, which must have at least one weight.
      Not 100% sure on the fixedParent and fixedDist entries, but they are probably used to prevent certain vertices straying too far from certain bones (causing visually unacceptable distortion) during animation.
      MDSWeight struct MDSWeight { uint32 boneIndex; // Index of bone in the main bone list float weight; // Bone weighting (from 0.0 to 1.0) float[3] xyz; // xyz bone space position of vertex }; There is an MDSWeight structure for every bone that has some influence over a vertex. Bones with higher weights have more influence over the final position of a vertex during animation. For example, a weight of 1.0 will mean the corresponding bone (indicated by boneIndex) totally defines the position of the vertex. The weight values stored in each MDSWeight for a single vertex should all sum to 1.0.
      If you want to know more about how the smooth mesh deformation process works, check out Game Programming Gems I for some good articles. Also, have a look at the function "SkinBaseSurfaces" in the MDSLoader.ms MAXScript from my MDS Importer where I manually 'skin' the initial base pose mesh before handing it over to the Skin modifier to do the rest of the work.
       
      MDSTriangle struct MDSTriangle { uint32[3] vertexIndices; // 3 indices into the surface's vertex list }; A triangle in a surface.
      Limits These are the upper limits imposed by RTCW on the numbers of various data structures in an MDS file:
      Max no. verts = 6000 Max no. triangles = 8192 Max no. bones = 128 Max no. surfaces = 32 Max no. tags = 128  
      The Collapse Map
      Here are some ramblings on the collapse map structure that might be of use:
      The collapse map (as introduced here) is used for runtime dynamic LOD (level of detail) adjustment. In Quake 3, separate models where switched between according to the estimated on-screen size of each player model. The system used in Wolfenstein automatically adjusts the triangle count of the model up and down as its on-screen size changes without requiring any additional models! Cool, eh?
       
      Models that can have their detail adjusted by edge collapses (and the opposite, vertex splits) are known as progressive meshes. Technically, RTCW uses view-independent progressive meshes or VIPM as it's known to its friends. The particular variant used in RTCW is based on the one described by Stan Melax in his polygon reduction article, which you can find on his web site along with example programs and source.
      There has been a lot written on progressive meshes in the last few years, and I'd recommend you consult Game Programming Gems I and II for some great articles by Jan Svarovsky and Tom Forsyth on the topic. Charles Bloom also has some very interesting VIPM notes on his web site. Finally, if you don't mind academic papers, the relevant work by Hugues Hoppe is essential reading.
      Creating the collapse map involves picking the edge collapse that causes the least visible difference, doing the collapse and repeating with the remaining edges until the mesh cannot be simplified any more. Once all the collapses are done, the mesh vertices are sorted into collapse order (last one to be collapsed is first) and the collapse map is written out. It would be far too time consuming to manually pick the edge collapses in the best order, so this process is done automatically by the MDS build tool. A fully featured exporter is free to choose edge collapses in any order, but for best results some time should be spent on developing a good error metric.
      Polygon Counts
      As a rough guide, here are total poly counts for some MDS models:
      Helga: 1246 Trench: 1162 ProtoSolider: 2601 Venom: 1656 Multi: 1268 1250 tris seems about typical for an average player model.
       
      The End
      Copyright (C) 2002 Chris Cookson

    blueprints tutorials we might need

    Thunder
    By Thunder,

     


    Making a character in Blender

    Thunder
    By Thunder,

     


    UV making

    Thunder
    By Thunder,

     


Portal by DevFuse · Based on IP.Board Portal by IPS
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.