I'm not a fan of the real life type stuff, but that's simply awsome, Nikoli.

Thank you very much for releasing this.

It figures.

Just got finished poking around the resulting .model files.
They do in fact have a CLTH reference in them. I was hoping (imagining) that the ps_ModelMunge.exe had some magic way of turning cloth into a plain old mesh.
It does, but still calls it CLTH and treats it different than the rest of the file.

Thanks for verifying the crashing bit too.  Helps cement it in my mind that the cloth just isn't gonna happen in BF1.

We have all read about how cloth doesn't do well in BF1. (What I've read is that it doesn't work at all.)

Has anyone tried switching the ModelMunge.exe in the BF1 tool bin for the pc_ModelMunge.exe in the BF2 tool bin? (with the intent of getting additional features working?)

They are different programs, but they should use simular .option switches and I would imagine they output simularly munged files? Or is the cloth code hardwired into the battlefront executable?

I will test on my own, just curious if anyone else has tried.

-edit- changed title to solved

Got it. The swbfgamers link is working.

Thanks, Phobos.

I really dig the Star Wars aliens.
Right now I'm still hung up on Sand People, but all of them need diversity.
There are tons of clones (which is fitting I guess) but so few aliens.

-edit
the file (Bith Head Mesh.7z) is comming down damaged (0 bytes.)
It's ok though, the head is it's own MODL chunk in the full model. (heh, named kopf.) I can work with that.

I would dig it.
I'm working on isolating heads and special geometries and swapping them out, exploring the potential of different body types and uniform msh's to flesh out the potential for more diverse alien/local side building.
(muscular/skinny, officer/grunt, armored/pilot, robed/not robed, ect..)

I'm still hung up on some msh specific stuff, and am currently limiting myself to stock assets till I get my msh manipulation revised into an exe. But building a supply of asset parts is one of my goals.

Bith head is right there, as I would love to see hat the potential is for a sec ops Bith asault team would look like.
Perhaps leading to a Ph'ton (Jedi Master during the Clone Wars) model.

Thanks, Phobos.
For this and your other releases.
I never would have started without the centralized info in the Encyclopedia.

Notes on SWBF .msh file structure.
I want to be able to manipulate model features and geometries without XSI. In order to do that, I need the file format.

Ande has a site dedicated to this exact information. (link: www.ande.pytalhost.eu)
If anything in this document confilcts with what he has, I would go with what he has.
Some (a lot, particularly the CLTH stuff) of the following is straight from there, as I have no way to test it.

.msh MAIN CHUNK HIERARCHY
[spoiler]
HEDR                            -Size of file from next byte to end
   +-SHVO                       -Has Shadow or not?
   +-MSH2                       -Size of file from next byte to last MODL
   |    +-SINF                  -Scene Info
   |    |    +-NAME             -Name
   |    |    +-FRAM             -Scene animation info
   |    |    +-BBOX             -Bounding Box
   |    +-CAMR                  -Camera
   |    |    +-NAME             -Camera name. Typicaly "Camera"
   |    |    +-DATA             -Camera position and direction info.
   |    |    +-ANIM             - ? Animated Camera?
   |    |    +-LGTI             - ? Light?
   |    |         +-NAME        - ? The Light's name, I assume.
   |    |         +-DATA        - ? The Light's Metrics, I assume.
   |    +-MATL                  -Material info
   |    |    +-MATD             -Material description chunk
   |    |         +-NAME        -Material name
   |    |         +-DATA        -Color information
   |    |         +-ATRB        -Attributes of Texture
   |    |         +-TX0D        -Texture name
   |    +-MODL                  -Model geometry, skeleton, nulls, ect
   |         +-MTYP             -MODL type
   |         +-MNDX             -Model index #
   |         +-NAME             -MODL name
   |         +-PRNT             -Parent MODL NAME
   |         +-FLGS             -Visible/Hidden
   |         +-TRAN             -Transform/Translation
   |         +-GEOM             -Geometry
   |         |    +-BBOX        -Bounding Box
   |         |    +-SEGM        -Standard Geometry
   |         |    |    +-SHDW   -Shadow
   |         |    |    +-MATI   -Material index #
   |         |    |    +-POSL   -Vertex locations
   |         |    |    +-WGHT   -Weights
   |         |    |    +-NRML   -Vetrex Normals
   |         |    |    +-CLRL   -Vertex color
   |         |    |    +-CLRB   -Vertex color
   |         |    |    +-UV0L   -UV map
   |         |    |    +-NDXL   -Polygons
   |         |    |    +-NDXT   -Triangles
   |         |    |    +-STRP   -Triangle strips
   |         |    +-ENVL        -Envelope references
   |         |    +-CLTH        -Cloth (special geometry)
   |         |         +-CTEX   -Texture name
   |         |         +-CPOS   -Cloth Verticies
   |         |         +-CUV0   -Cloth UV map
   |         |         +-FIDX   -Cloth envelope indexes
   |         |         +-FWGT   -Cloth Weighting
   |         |         +-CMSH   -Triangles
   |         |         +-SPRS   -Stretch Constraints
   |         |         +-CPRS   -Cross Constraints
   |         |         +-BPRS   -Bend  Constraints
   |         |         +-COLL   -Collision data
   |         +-SWCI             -Collision data
   +-SKL2                       - CRC's of bones and ?
   +-BLN2                       - CRC's of bones
   +-ANM2                       -Animation data
   |    +-CYCL                  - ?
   |    +-KFR3                  - Keyframes
   +-CL1L                       - ?(Always at eof)
[/spoiler]

.msh BONE HIERARCHY (MODL chunks)
[spoiler]
DummyRoot
   +-MESH_body
   |    +-bone_root
   |         +-root_a_spine
   |         |    +-bone_a_spine
   |         |         +-bone_b_spine
   |         |              +-bone_ribcage
   |         |                   +-eff_ribcage
   |         |                        +-root_l_clavicle
   |         |                        |    +-bone_l_clavicle
   |         |                        |        +-eff_l_clavicle
   |         |                        |            +-root_l_upperarm
   |         |                        |                +-bone_l_upperarm
   |         |                        |                    +-bone_l_forearm
   |         |                        |                        +-eff_l_forearm
   |         |                        |                            +-root_l_hand
   |         |                        |                                +-bone_l_hand
   |         |                        |                                    +-eff_l_hand
   |         |                        |                                    +-MESH_l_hand
   |         |                        +-root_r_clavicle
   |         |                        |    +-bone_r_clavicle
   |         |                        |        +-eff_r_clavicle
   |         |                        |            +-root_r_upperarm
   |         |                        |                +-bone_r_upperarm
   |         |                        |                    +-bone_r_forearm
   |         |                        |                        +-eff_r_forearm
   |         |                        |                            +-root_r_hand
   |         |                        |                                +-bone_r_hand
   |         |                        |                                    +-eff_r_hand
   |         |                        |                                    +-MESH_r_hand
   |         |                        +-root_neck
   |         |                             +-bone_neck
   |         |                                 +-bone_head
   |         |                                     +-eff_head
   |         +-bone_pelvis
   |              +-root_r_thigh
   |              |   +-bone_r_thigh
   |              |       +-bone_r_calf
   |              |           +-eff_r_calf
   |              |               +-root_r_foot
   |              |                   +-bone_r_foot
   |              |                       +-bone_r_toe
   |              |                           +-eff_r_toe
   |              +-root_l_thigh
   |                  +-bone_l_thigh
   |                      +-bone_l_calf
   |                          +-eff_l_calf
   |                              +-root_l_foot
   |                                  +-bone_l_foot
   |                                      +-bone_l_toe
   |                                         +-eff_l_toe
   +-sv_ShadowVolume_mesh
   +-MESH_head
   +-MESH_backpack
   +-MESH_jetpack
   +-MESH_belt
   +-MESH_cape

   * this is just how the bones are parented. Enveloping and weighting determine
     how it moves with the skeleton.
   * the items that start with MESH_ are pretty much options. Their NAME is only
     important for parenting.
   * To make a model override_texture compatible, it's 'body' MODL chunk's name
     should be 'override_texture'. (Don't forget to change the name in it's
     children's PRNT chunk.)
   * p_* MODLs are deliberatly ommited as I don't know if they need to strictly
     follow the heirarchy or not
   * The order of the MESH_* chunks is just an example. There are models with
     all the geometry after all the bones, or some with the sv_ near the
     DummyRoot. As long as the PRNT and ENVL entries point to the correct
     models, then the msh should be valid and pass through ModelMunge just fine.

     
[/spoiler]

.msh TAG OFFSETS AND DESCRIPTIONS
[spoiler](in hierarchal order)
(items in brackets [] are still being investigated)
(? in the length fields indicate a variable length, typically defined by the preceding field)
HEDR
   offset   length   type      contents
        0        4   char(4)   HEDR
        4        4   long      bytes to end of file
   * the size entry will be the filesize - 8 bytes.

SHVO (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   SHVO
        4        4   long      byte length of section from next byte
        8        4   byte(4)   ? typicaly 1
   * could be a long integer, or a series of bytes like ATRB
   * needs more study

MSH2 (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   MSH2
        4        4   long      bytes from next byte until last byte of last MODL chunk

SINF (child of MSH2)
   offset   length   type      contents
        0        4   char(4)   SINF
        4        4   long      byte length of section from next byte

NAME (child of SINF)
   offset   length   type      contents
        0        4   char(4)   NAME
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

[FRAM] (child of SINF)
   offset   length   type      contents
        0        4   char(4)   FRAM
        4        4   long      byte length of section from next byte
        8        4   long      start of frame range
       12        4   long      end of frame range
       16        4   float     fps
   * needs more study
   * most player msh's with a KFR3 chunk only have 2 frames in the KFR3. Haven't verified this in animation MSHs yet

BBOX (child of SINF)
   offset   length   type      contents
        0        4   char(4)   BBOX
        4        4   long      byte length of section from next byte
        8       16   float(4)  Quaternion Rotation ( qx , qy , qz , qw )
       24       12   float(3)  Center ( x , y , z )
       36       12   float(3)  ( Width/2 , Height/2 , Depth/2 )
       48        4   float     Bounding Sphere Radius

CAMR (child of MSH2)
   offset   length   type      contents
        0        4   char(4)   CAMR
        4        4   long      byte length of section from next byte

NAME (child of CAMR)
   offset   length   type      contents
        0        4   char(4)   NAME
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

[DATA] (child of CAMR)
   offset   length   type      contents
        0        4   char(4)   DATA
        4        4   long      byte length of section from next byte
        8       12   float(3)  position ( x? , y? , z? )
       20       12   float(3)  direction ( x? , y? , z? )
       32       16   float(4)  ( ? , ? , ? , ?) (a quat, perhaps?)
   * needs more study

[ANIM] (child of CAMR)
   offset   length   type      contents
        0        4   char(4)   ANIM
        4        4   long      byte length of section from next byte
        8        ?   ?         ?
   * needs more study

[LGTI] (child of CAMR)
   offset   length   type      contents
        0        4   char(4)   LGTI
        4        4   long      byte length of section from next byte
   * needs more study

NAME (child of LGTI)
   offset   length   type      contents
        0        4   char(4)   NAME
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

[DATA] (child of LGTI)
   offset   length   type      contents
        0        4   char(4)   DATA
        4        4   long      byte length of section from next byte
        8        4   float     ?
       12        4   float     ?
       16        4   float     ?
       20        4   float     ?
       24        4   float     ?
       28        4   float     ?
       32        4   float     ?
       36        4   float     ?
   * floats work for them so far, but may be incorrect
   * needs more study

MATL (child of MSH2)
   offset   length   type      contents
        0        4   char(4)   MATL
        4        4   long      byte length of section from next byte (Including sub section sizes)
        8        4   long      number of MATD sections to follow
   * MATI references to MATD's start at 0

MATD (child of MATL)
   offset   length   type      contents
        0        4   char(4)   MATD
        4        4   long      byte length of section from next byte

NAME (child of MATD)
   offset   length   type      contents
        0        4   char(4)   NAME
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

DATA (child of MATD)
   offset   length   type      contents
        0        4   char(4)   DATA
        4        4   long      byte length of section from next byte
        8       16   float(4)  Diffuse Color ( red? , green? , blue? , alpha?)
       24       16   float(4)  Ambient Color ( red? , green? , blue? , alpha?)
       40       16   float(4)  Specular Color ( red? , green? , blue? , alpha?)
       56        4   float     Specular Intensity
   * needs more study
   * Haven't tried to interpret the floats into proper RGBa values

[ATRB] (child of MATD)
   offset   length   type      contents
        0        4   char(4)   ATRB
        4        4   long      byte length of section from next byte
        8        1   byte      addative flag values
        9        1   byte      render type number
       10        1   byte      data0 0 - 255
       11        1   byte      data1 0 - 255
   * Inside Edit Flags (FAQ) on GT
   * I will reflect the settings here when I start bump-mapping my Tuskens.

TX0D (TX1D, TX2D, ect. ) (child of MATD)
   offset   length   type      contents
        0        4   char(4)   TX0D
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long
   *some of the attributes require extra TX?D entries

MODL (child of MSH2)
   offset   length   type      contents
        0        4   char(4)   MODL
        4        4   long      byte length of section from next byte (Including sub section sizes)

[MTYP] (child of MODL)
   offset   length   type      contents
        0        4   char(4)   MTYP (model type)
        4        4   long      byte length of section from next byte
        8        4   long      0=null      1=skin    2= ?
                               3=envelope  4=static  6=shadow
   * offset 8 info from the Riley pages. The absense of 2 makes me believe there is more to this.
   * I havent figured out which one, but there is an exporter that spells this incorrectly as MYTP.
   * needs more study

MNDX (child of MODL)
   offset   length   type      contents
        0        4   char(4)   MNDX (model index #)
        4        4   long      byte length of section from next byte
        8        4   long      model index #
   * These are reffrenced by the ENVL chunks.

NAME (child of MODL)
   offset   length   type      contents
        0        4   char(4)   NAME
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

PRNT (child of MODL)
   offset   length   type      contents
        0        4   char(4)   PRNT
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes
   *it will always be a multiple of 4 bytes long

[FLGS] (child of MODL)
   offset   length   type      contents
        0        4   char(4)   FLGS
        4        4   long      byte length of section from next byte
        8        4   long      00 00 00 00 = visible
                               01 00 00 00 = hidden
   * could be a long integer, or a series of bytes like ATRB
   * needs more study

[TRAN] (child of MODL)
   offset   length   type      contents
        0        4   char(4)   TRAN
        4        4   long      byte length of section from next byte
        8       12   float(3)  Scale ( x , y , z )
       20       16   float(4)  Quaternion rotation  ( qx , qy , qz , qw )
       36       12   float(3)  Translation  ( x , y , z )
   * needs more study
   * these are important for keeping the bones pointed in the right direction.

GEOM (child of MODL)
   offset   length   type      contents
        0        4   char(4)   GEOM
        4        4   long      byte length of section from next byte (Including sub section sizes)

BBOX (child of GEOM)
   offset   length   type      contents
        0        4   char(4)   BBOX
        4        4   long      byte length of section from next byte
        8       16   float(4)  Quaternion Rotation ( qx , qy , qz , qw )
       24       12   float(3)  Center ( x , y , z )
       36       12   float(3)  ( Width/2 , Height/2 , Depth/2 )
       48        4   float     Bounding Sphere Radius

SEGM (child of GEOM)
   offset   length   type      contents
        0        4   char(4)   SEGM
        4        4   long      byte length of section from next byte (Including sub section sizes)

[SHDW] (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   SHDW
        4        4   long      byte length of section from next byte (Including sub section sizes)
   *all the verticies are listed first
        8        4   long      number of verticies
                12   float(3)  vertex(X, Y, Z)
   *then all the edges
                 4   long      number of edges
                 2   short     Vertex index of this edge entry. Refers to the vertex list above.
                 2   short     edge 1 (refers to another edge in this list)
                 2   short     edge 2 (refers to another edge in this list) **
                 2   short     end of edge. (65535) or (0xFFFF)
   * needs more study
   ** oddly, the vertex in the edge this refers to is always the same as the vertex in the edge that edge 1 refers to.

MATI (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   MATI
        4        4   long      byte length of section from next byte
        8        4   long      MATD reference.
   * The MATD's are indexed from 0

POSL (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   POSL
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12       12   float(3)  ( x , y , z )
   * the entry at offset 12 repeats, index( offset 8 ) times.

WGHT (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   WGHT
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 32 byte entries to follow
       12       32   (long, float)(4) (bone reference, Weight in percent)
   * the entries from offset 12 to 38 repeat, index( offset 8 ) times.
   * you can have multiple weights, they just have to add up to 100% (1.0) (XSI docs)
   * The bone is called by ENVL index.
     For example: if the first bone in ENVL is bone_neck (MNDX 34) then the WGHT reff will be 0 since it is the first bone in the ENVL.

NRML (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   NRML
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12       12   float(3)  3 floats describing Vertex normals
   * the entry at offset 12 repeats, index( offset 8 ) times.

[CLRL] (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   CLRL
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        4   short(4)  ( red , blue , green, alpha )
   * needs more study

[CLRB] (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   CLRB
        4        4   long      byte length of section from next byte
        8        4   short(4)  ( red , blue , green, alpha )
   * Got it's structure, now what is it?
   * needs more study

UV0L (UV1L, UV2L, ect.) (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   UV0L
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 8 byte entries to follow
       12        8   float(2)  ( tx , ty )
   * the entries from offset 12 and 16 repeat, index( offset 8 ) times.
   * to see where each UV is on a texture, multiply each coordinate by the size
     of the texture.
     For example:
         if texture size = 512 x 512 and tx=0.564125 , ty=0.059709
         the points would be:
         x = tx * 512 = 0.564125 * 512 = 288.832
         y = ty * 512 = 0.059709 * 512 =  30.571008
         

[NDXL] (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   NDXL
        4        4   long      byte length of section from next byte
        8        4   long      an index. Number of polygons
       12        2   short     an index. Number of corners
       14        2   short     point ref (from POSL)
   * the entries at offset 14 repeats, index( offset 12 ) times.
   * the entries from offset 12 to (end of it's sequence) repeat, index( offset 8 ) times.
   * some software uses this info, but it will munge and play without it.
   * needs more study

[NDXT] (child of SEGM)(depriciated)
   offset   length   type      contents
        0        4   char(4)   NDXT
        4        4   long      byte length of section from next byte
        8        4   long      an index. Number of triangles
       12        2   short     point ref (from POSL)
       14        2   short     point ref (from POSL)
       16        2   short     point ref (from POSL)
   * the entries from offset 12 to 14 repeat, index( offset 8 ) times.
   * some software uses this info, but it will munge and play without it.
     (I think 3d Converter uses it to determine polys instead of the STRP.)
   * I don't know if they go clockwise or counter-clockwise.
   * needs more study

[STRP] (child of SEGM)
   offset   length   type      contents
        0        4   char(4)   STRP
        4        4   long      byte length of section from next byte
        8        4   long      an index. not certain about what it's indexing
       12        2   short     POSL vertex reffrence
   * the entry (offset 12) repeat, index( offset 8 ) times.
   * This tag lists triangle strips.
     The tringles are defined by refs to vertecies in the POSL tag.
     The strips are seperated into groups of triangle strips.
     The start of a strip is indicated by 2 entries with a high bit set.
     Basicly the vertex ref has 32768 added to it. Subtracting 32768 gives the vertex index.
     They should be listed in clockwise, counter-clockwise, clockwise order, I haven't confirmed this.
     They should be listed in   counter-clockwise,   clockwise,   counter-clockwise
     order, I haven't confirmed this.
   * needs more study

ENVL (child of GEOM)
   offset   length   type      contents
        0        4   char(4)   ENVL
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 4 byte entries to follow
       12        4   long      bone MNDX reference
   * the entry offset 12 repeats, index( offset 8 ) times.

CLTH (child of GEOM)
   offset   length   type      contents
        0        4   char(4)   CLTH
        4        4   long      byte length of section from next byte

CTEX (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   CTEX
        4        4   long      byte length of section from next byte
        8        ?   ascii     string with the end padded with 00 bytes

[CPOS] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   CPOS
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12       12   float(3)  ( x , y , z )
   * the entry at offset 12 repeats, index( offset 8 ) times.
   *same as POSL
   
[CUV0] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   CUV0
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 8 byte entries to follow
       12        8   float(2)  ( tx , ty )
   *same as UV0L

[FIDX] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   FIDX
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 4 byte entries to follow
       12        4   long      CPOS vertex indexes
   * haven't looked into this yet

[FWGT] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   FWGT
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        4   ascii     bone names
   *assuming these are the names of the bones that the CPOS vertexes refered to in FIDX, are weighted to.

[CMSH] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   CMSH
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12       12   long(3)   CPOS vertex refferences defining a counter-clockwise triangle

[SPRS] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   SPRS Stretch Constraint
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        4   short(2)  points sharing an edge
   *ANDEWEGET's GT post

[CPRS] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   CPRS Cross Constraint
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        4   short(2)  points sharing a quad
   *ANDEWEGET's GT post

[BPRS] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   BPRS Bend Constraint
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        4   short(2)  Two border-points sharing a "straight" edge over the complete cloth.
   *ANDEWEGET's GT post

[COLL] (child of CLTH)
   offset   length   type      contents
        0        4   char(4)   COLL
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12        ?   ascii     Collision object name
       ??        ?   ascii     Object this collision moves with(parent)
       ??        4   long      possible FIDX refference
       ??        4   float     for type sphere   = radius
                               for type cylynder = radius
                               for type cube     = size x/2
       ??        4   float     for type sphere   = n/a
                               for type cylynder = height
                               for type cube     = size y/2
       ??        4   float     for type sphere   = n/a
                               for type cylynder = n/a
                               for type cube     = size z/2
   *seems to work like SWCI, but for cloth
   
[SWCI] (child of MODL)
   offset   length   type      contents
        0        4   char(4)   SWCI
        4        4   long      byte length of section from next byte
        8        4   long      collision primitive type
                               0 = sphere
                               2 = cylynder
                               4 = cube
       12        4   float     for type sphere   = radius
                               for type cylynder = radius
                               for type cube     = size x (might be scaled)
       16        4   float     for type sphere   = n/a
                               for type cylynder = height
                               for type cube     = size y (might be scaled)
       20        4   float     for type sphere   = n/a
                               for type cylynder = n/a
                               for type cube     = size z (might be scaled)
   * needs more study

all of the following always appear after the last MODL chunk and their size is not included in the MSH2 value.

[SKL2] (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   SKL2
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 20 byte entries to follow
       12        4   byte(4)   CRC used to refer to bone_ entries
       16        4   long      type
       20        4   float     Constrain
       24        4   float     bone length 1
       28        4   float     bone length 2
   * the entries from offset 12 to 28 repeat, index( offset 8 ) times.
   * needs more study

[BLN2] (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   BLN2
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of 8 byte entries to follow
       12        4   byte(4)   CRC used to refer to bone_ entries
       16        4   float?    blend factor

ANM2 (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   ANM2
        4        4   long      byte length of section from next byte (Including sub section sizes)

[CYCL] (child of ANM2)
   offset   length   type      contents
        0        4   char(4)   CYCL
        4        4   long      byte length of section from next byte
        8        4   long      an index - number of entries to follow
       12       64   char(64)  animation name
       76        4   float     frame rate
       80        4   long      play Style
       84        4   long      first Frame
       88        4   long      last Frame
   * needs more study
   ** each entry is typically 80 bytes. I'm guessing they left a long space to accomodate animation names?

[KFR3] (child of ANM2)
   offset   length   type      contents
        0        4   char(4)   KFR3
        4        4   long      byte length of section from next byte
        8        4   long      an index? - number of x byte entries to follow
       12        4   byte(4)   CRC used to refer to bone_ entries
       16        4   long      keyframe type
       20        4   long      translation count
       24        4   long      rotation count
   * all the translation entries will be listed first
       28        4   long      frame position translation index (starts at 0)
       xx        4   float     translation x
       xx        4   float     translation y
       xx        4   float     translation z
   * then all the rotation entries
       xx        4   long      frame joint rotation index (starts at 0)
       xx        4   float     quaternion qx
       xx        4   float     quaternion qy
       xx        4   float     quaternion qz
       xx        4   float     quaternion qw
   * needs more study
   * In animation msh's, this is the biggest tag,having several translation and rotation entries.

[CL1L] (child of HEDR)
   offset   length   type      contents
        0        4   char(4)   CL1L
        4        4   ?         00 00 00 00
   * I wonder if this could mean anything other than EOF

   ** the Quaternions are in the order qx,qy,qz,qw
      qw is the scalar
      qx, qy, qz are the ... vector? (I don't know how to name it. read up on quats and you will discover that everyone has a different name for them. It's no wonder we don't have a single, unified field theory. We can't even agree on how to count to 'turn left'.)

   ** ALL the CLTH tag info is directly from Ande's work. I have no way to test is as I don't have BF2.
      It's solid though, and should be easy to validate.
     
[/spoiler]

I believe the above is pretty complete for the purposes of recognizing and translating the msh data. As I run across errors, I will correct them. The code I am building is drawing directly from the info in this document.
I am now moving on to explore the next level of abstraction the data represents. Envelopes, smoothing groups, IK chains and such.

The attatched tools will br removed when I make suitable replacements for them.
They are all being re-written from the ground up to include everything I have learned in the last several months.
I haven't decided if they will be several small tools, or a single tool with several options.
I do know that none will have a GUI. All input and output will take place through the console or via txt files.

I don't think there will be much more that I can do with the raw format, utillity-wise. But I am looking into various ascii formats. Perhaps I can takea swing at, say, a msh to obj converter that doesn't loose half the msh data (like the entire skeleton.)

-next update : re-tooling the tools. (testing)

The model chunk should be made up of sub sections just like the lvl. (and .msh's coincidentaly)

A simular script targeted to busting the .model up (into smaller chunks) would allow one to compare them to the sections of a .msh.

The .option settings could help illuminate what data is kept, what is discarded, and how things are treated on their way to their post munged state.

-edit- (afterthought)

As a test, create a test lvl with only one model in it, then try to find , extract, and rebuild it, using these scripts.

ugh.

After a couple of days burried in 32 bit singles and longints, I'm pretty sure I have discovered why there isn't a full on lvl de-compiler.

It isn't that it is impossible. It's the time and sheer abstract nature of the data (and the headaches and nose-bleed from information overload.)

A real programer could get the models out, but I'm just a hack/scripter, learning as I go.

As for being able to use ps2 models on PC BF1, you might have to add or edit some things, but I'm sure the renderer for the ps2 expects the same geometry format. (It's still Zero, after all.) The texture will probably be a different format, the special flags (transperancy, glossyness,ect..) for materials and such, might be set diferent(more conservative for the limitations of the platform. )

All that can be overcome, IF someone could figure out how to extract it to be worked on.

Played the first one and loved it.

Weren't they supposed to be the sequal to to the Dark Forces series?

Thanks for the links.
I had the last 2 (somewhere) but the first is new to me.

It loads sptest with a custom resolution?

(been avoiding sptest actually, I have a junction between the addon output folder and BF1's addon folder, that alows me to munge and go, straight to the end platform.)

-edit-
Groovy. I'm at 1280 x 768. Already fixed it in bfbuilder, but not for BF. This will come in handy.

Banging out the tag list for the file by hand gave me a headache. so I turned to the header file of the lvl extract.exe and used his defines as a starting point.

Most all of his tags are valid, but there are some that turn up invalid sizes (several gigabytes.. might be movie refs, but in a side lvl?)

The partialy validated list follows.

ucfb   - the begining of the file
lvl_   - main sections. everything else is contained in one of these.
BODY   -
body   -
coll   - the 1billion + size refs, I bet I'm reading them wrong.
Coll   -
entc   -
expc   -
gmod   -
INFO   -
modl   -
NAME   -
ordc   -
prim   -
skel   -
zaa_   -
zaf_   -


lot of emptyness in that list, but the lvl_ file size refs (+ 8 for the ucfb and it's 4 byte value) mirror the file size exactly, so I'm on the right track.

As for the case, I'm willing to bet the uppercase ones are for something else, but haven't validated that yet.

The project I am in the middle of is exactly the same work, but with MSH files (I want so desperatly to swap the head of a tusken but can't track it down.) So I'll be moving back and forth from them as I develop better binary/hex/zipitydooda crunching functions.

hex editor - XVI32 (It has that data inspector and a groovy little script engine. good for cleaning out mangled data)

Text editor - AEdiX suite v3.0.5 (comes with a hex editor, but it is not very robust)(also has a script engine and text hilighting, but I just use it like notepad.) Old and not supported anymore I think.

Scripting Language - AutoIT and I use SciTE to edit my scripts. Simple Basic structure. Perfect for folks like me that never took the time to learn about object oriented programming. (I hate any kind of programming that forces handles on you.) There is a big problem with AutoIT though. It sets off virus scanners. Never had a problem, but still, it sets them off. If I could find a language as easy as basic, and free, I would replace it. (FreeBasic has a crazy addon dll system for user created modules, where autoit just works out of the box)

Links to their sites:

Kiry's Tech (AEdiX suite v3.0.5)
http://www.kirys.it/downloads.html

AutoIT (main download includes a slimmed down SciTE editor that works with lua as well.)
http://www.autoitscript.com/site/autoit/downloads/

XVI32
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

All of the above are freeware, but they are also easily worth 100 times what I paid for my first copy of BF1. I can't count the hours I've spent in each.

re: the imp pistol.
I got the list down to 3000 and falling for the PS2 lvl. turns out the tags are there, just lower case. It might be as easy as finding the pieces and appending them together in the right order.

Perhaps they used lower res models, droped the shadow volume, and uther special "feature" geometry.
The PS2 version is really lw res compared to PC. I still am amazed by the ZeroEngine and my vid card bites.

158 references to imp_weap_inf_pistol in the PS2 IMP.lvl
133 references to imp_weap_inf_pistol in the PC IMP.lvl
that seems large, but after isolating the string-like structures, there are losts of them.
some are _ord refs and some are animation refs.

found the hp_fire for imp_weap_inf_pistol, so I must be close to it's modl.
But I don't recognize the tags in here. there are no CL1L, SEGM, or GEOM typ references, so it would take some time to parse it all out.
There are tags though. modl instead of MODL, but the size refs are still there and seem to work the same.(I love the data inspector in XVI32)

It appears that the models are split up into several different pieces. (perhaps to optimize load times?)
I made a list of alpha numeric strings for each(141000 for both, but most are data and garbage) and will comb through it to see if I can narrow it down to a reasonable list of tags.

With a list of tags I can chop the lvl up into chunks and those chunks can be further scrutinized to glean how the lvl is constructed. (and also how to put the stuff back in it's pre-lvl'ed state)

ETA on the tag list- tomorrow.... definatly not anytime today.
ETA on Scrutiny- well... yeah, thats the catch, isn't it. Later. More later than is ok, but sooner than never.

Pure reversing with a good data inspector, a scripting tool and a text editor that doesn't mess with nulls or whitespace. I feel like I'm 12, poking around on my old Vic-20 again.