Page 4 of 22 FirstFirst 1234567814 ... LastLast
Results 91 to 120 of 652

Thread: A start on the .MESH file format

  1. #91

    Default Re: A start on the .MESH file format

    Hi @KE

    Yes the smd format is fairly simple but for now the weighted vertices won't load into Milkshape, but it look's like smd wil be the first cab off the rank for imported formats, Mete Ciragan, Milkshape's owner, programmer, etc had this to say about the changes to 1.7.11 :-

    I will update the SMD, PSK and maybe Max Payne2 support. Others like MD3, MD2 are updated automatically. But I start with SMD and look how far I come. Of course with time every format that can support weighted vertices will be updated.
    I got the weighted vertices into MS3D by using the binary format rather than the ascii format. This supports the recording of vertex weights. If you're using the binary spec be aware that the byte storing the weight is in the range 0-100 rather than 0 -255 as per the spec. The spec and SDK will be updated with 1.7.11. Mete confirmed the weight storage was the case but didn't mention if the ascii format will be updated.

    Good luck with the looking at meshes , it may sound strange but let me know as soon as possible if you find any that can't be converted .

    Edit: Just had a thought on .smd, yes you will lose groups and names if you export a whole figure but why not look at using it to export single groups? The Mesh file is neatly put together so that all vertices and triangles used for any group are in sequential order. So if you wanted to look at any particular group the vertex numbers would range from the Lowest - number of vertices in all preceding groups, to the Highest - highest vertex listed in the triangles of the current group - ( I just read that and I'm not sure if that explains it well enough ). I'll write out some pseudo code if you need any clarification.

    Sorry for boring anybody else out there.

    Cheers

    GrumpyOldMan
    Last edited by GrumpyOldMan; 03-03-2007 at 06:01.

  2. #92
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @GOM
    Ahhh, now I understand your comment a few posts back
    about changing 0.677... to 67. Have you seen anything
    on Mete's forums about a release date for 1.7.11?
    I posted about his working on 1.7.11 and then going on to working
    on 2.0 again but I don't know what 2.0 is supposed to add.
    (I'm ashamed to admit I still haven't registered my copy.
    I'll rectify this gross injustice to Mete this weekend. )

  3. #93
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    Not boring me.
    I was wondering how much the 3dsmax modders
    are tied to things like that. If they really wanted grouping
    for changing helmuts etc. would they find it hard if that
    information got lost. I was probably down on the fbx
    format because I made a binary to ASCII converter and
    an ASCII to binary converter using their SDK and lost the
    bone info. But it did tell me I was converting a 1.6.0 file
    to a 1.6.1 format when I went from binary to ASCII in the
    first place. (Milkshape uses the 1.6.0 format.) Wasn't eager
    to try the experiment again with an older format because
    the first SDK chewed up over a GIG of harddrive space.
    (I've got plenty of space, just didn't know if this was
    going anywhere.)

    Strategy for meshes: CA probably did a very thorough
    job on western units. (Marketing, no offense Caliban.)
    I'll try to work on eastern European units and Byzantines
    as well as Middle East units. lod0 through lod4 as a check
    here and there but otherwise lod0 on a selection of units.
    Last edited by KnightErrant; 03-03-2007 at 06:40.

  4. #94

    Default Re: A start on the .MESH file format

    Hi @KE

    I posted about his working on 1.7.11 and then going on to working
    on 2.0 again but I don't know what 2.0 is supposed to add.
    As fasr as I can see from the forums, there doesn't seem to be much going on with 2.0. He has stated that he is working on it and the only clue I've found is this:-

    Q. Will you be able to model soley in the 3D view if you want to?

    Yes, you can maximize one of the viewports and do anything from any projection. That's the goal.
    Whoa-oa, a gig for an SDK, it would have to be a really good SDK .

    Thanks for looking at the converted meshes, as well as any that don't convert, I'd really appreciate you looking at patterns of groups, ie does it matter if groups are mixed up - Attachments within body group clusters, group sequences out of order, etc.

    Cheers

    GrumpyOldMan

  5. #95
    Marcus Arbaces Alexandros Member Arbaces's Avatar
    Join Date
    Sep 2005
    Location
    Călăraşi, România.
    Posts
    122

    Default Re: A start on the .MESH file format

    Oh! This is what I wanted to see...! Magnificent work GrumpyOldMan, wheter it will be in Milkshape or Max, we'll handle it.

    My regards,

    Arbaces.

  6. #96
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @GOM
    Started on this a little late day. I've converted and opened in
    Milkshape the following:

    Mounts:

    Code:
    \unit_models\mounts\barded_horse\barded_horse_lod0
    \unit_models\mounts\barded_horse\barded_horse_lod1
    \unit_models\mounts\barded_horse\barded_horse_lod2
    
    \unit_models\mounts\barded_horse\mount_barded_horse_lod0
    \unit_models\mounts\barded_horse\mount_barded_horse_lod1
    \unit_models\mounts\barded_horse\mount_barded_horse_lod2
    
    \unit_models\mounts\camel\camel_lod0
    \unit_models\mounts\camel\camel_lod1
    \unit_models\mounts\camel\camel_lod2
    \unit_models\mounts\camel\camel_lod3
    
    \unit_models\mounts\camel\mount_camel_lod0
    \unit_models\mounts\camel\mount_camel_lod1
    \unit_models\mounts\camel\mount_camel_lod2
    \unit_models\mounts\camel\mount_camel_lod3
    
    \unit_models\mounts\elephant\elephant_cannon_lod0
    \unit_models\mounts\elephant\elephant_lod0
    \unit_models\mounts\elephant\elephant_rocket_lod0
    \unit_models\mounts\elephant\mount_elephant_lod0
    \unit_models\mounts\elephant\mount_elephant_rocket_lod0
    
    \unit_models\mounts\european_armoured_horse\european_armored_horse_lod0
    \unit_models\mounts\european_armoured_horse\mount_armored_horse_lod0
    
    \unit_models\mounts\heavy_horse\heavy_horse_lod0
    \unit_models\mounts\heavy_horse\mount_heavy_horse_lod0
    
    \unit_models\mounts\mailed_horse\mailed_horse_lod0
    \unit_models\mounts\mailed_horse\mount_mailed_horse_lod0
    
    \unit_models\mounts\me_armoured_horse\me_armoured_horse_lod0
    \unit_models\mounts\me_armoured_horse\mount_eastern_armoured_horse_lod0
    
    \unit_models\mounts\medium_horse\medium_horse_lod0
    \unit_models\mounts\medium_horse\mount_fast_pony_lod0
    \unit_models\mounts\medium_horse\mount_pony_lod0
    \unit_models\mounts\medium_horse\mount_pony_lod1
    \unit_models\mounts\medium_horse\mount_pony_lod2
    _units\as_lamellar_heavy :


    Code:
    \unit_models\_units\as_lamellar_heavy\as_lamellar_heavy_archer_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_heavy_basic_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_heavy_guard_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_iron_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_ironarcher_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_leather_lod0
    \unit_models\_units\as_lamellar_heavy\as_lamellar_leatherarcher_lod0
    \unit_models\_units\as_lamellar_heavy\dismounted_heavy_archers_ug1_lod0
    \unit_models\_units\as_lamellar_heavy\dismounted_heavy_archers_ug1_lod1
    \unit_models\_units\as_lamellar_heavy\dismounted_heavy_archers_ug1_lod2
    However on the last few units the converter started refusing to
    do more than one unit, i.e. the load mesh button would depress
    but the file chooser wouldn't come up. I can close it and restart
    and get one more unit but same behavior.

    Taking the wife out for dinner so will do more when I get back.
    I'll try rebooting before I start again to see if that clears it.

    PS: Just noticed this today, when I hit the exit button I get one
    of those Microsoft error messages saying this application is not
    responding do you want to send a report. I always closed it before
    with the X button on the upper right corner and never saw this before.

  7. #97

    Default Re: A start on the .MESH file format

    Hi @KE

    Thanks for this work you're putting in. I must admit I haven't tried it with mounts yet but it's good to see that the conversion works with them too. I see I'll have to extract the skeletons for camels and elephants to go with the horse skeleton I have and add some radio buttons to the converter so that the right skeleton is added to the file.

    Forgive the .exe, it knows not that I play with a new GUI library .

    Try the new exe I've emailed you with the texture splitting and amended UV values and see if that behaves the same. I may have to go in and see if I'm flushing the GUI_events properly.

    NOTE for RTW Modders

    I've had a look and there is a Max to MS3D plugin at http://www.mds.mdh.se/~elt01mcg/files/max2ms3d_v112.zip which exports an imported .CAS as mesh but not the bones. You could use this mesh to tie your vertices to a M2TW skeleton or chop off pieces as groups. I'm planning a facility to import single groups as MS3D.

    Cheers

    GrumpyOldMan

  8. #98
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    Hi GOM,

    Tried rebooting a few times but didn't fix it.
    Got the new .exe and its working fine now.
    I've looked at the weightings following your
    help and I'm seeing it on the arm to torso and
    leg to torso. I'm looking at the groups but I'm
    not sure whether I know what you mean by

    Thanks for looking at the converted meshes, as well as any that don't convert, I'd really appreciate you looking at patterns of groups, ie does it matter if groups are mixed up - Attachments within body group clusters, group sequences out of order, etc.
    Is this the order the groups are listed in Milkshape
    vs their mesh file order? Haven't noticed any problems.

    I'm going to start skipping more to do a wider but less
    detailed survey of the eastern units.

    I''m off to Chattanooga tomorrow for my stepmom's 90th
    birthday so won't be doing much more until tomorrow night.

    Have a good rest of the weekend.

    KE

  9. #99
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    Hi GrumpyOldMan,

    Meh, spoke too soon. The behavior came back after doing
    5 or so meshes. My environment is I had Eudora up for your
    e-mail, Mozilla for the forums, Visual Slickedit where I keep a
    record of each unit I work on, Explorer, and Milkshape (plus
    your executable). See if converting multiple meshes on your
    computer does the same.

    Anyway I finished off these additional.

    Directory \unit_models\_units\as_lamellar\heavy :

    Code:
    \unit_models\_units\as_lamellar_heavy\dismounted_heavy_lancers_lod0
    \unit_models\_units\as_lamellar_heavy\dismounted_light_lancers_lod0
    \unit_models\_units\as_lamellar_heavy\khan's_guard_lod0
    \unit_models\_units\as_lamellar_heavy\mongol_bodyguard_lod0
    \unit_models\_units\as_lamellar_heavy\mongol_heavy_archers_lod0
    \unit_models\_units\as_lamellar_heavy\mongol_heavy_lancers_lod0
    \unit_models\_units\as_lamellar_heavy\mongol_infantry_lod0
    \unit_models\_units\as_lamellar_heavy\mongol_light_lancers_lod0
    \unit_models\_units\as_lamellar_heavy\sabadar_militia_lod0
    Directory \unit_models\_units\as_light :

    Code:
    \unit_models\_units\as_light\as_light_archer_lod0
    \unit_models\_units\as_light\as_light_basic_lod0            % Invalid triangles/groups, killed Milkshape.
    \unit_models\_units\as_light\as_light_cuman_archer_lod0     % Invalid triangles/groups, killed Milkshape.
    \unit_models\_units\as_light\cuman_horse_archers_lod0   
    \unit_models\_units\as_light\dismounted_archers_lod0        % Invalid triangles/groups, killed Milkshape.
    \unit_models\_units\as_light\kazaks_lod0                    % Invalid triangles/groups, killed Milkshape.
    \unit_models\_units\as_light\mongol_ballista_crew_lod0      % Invalid triangles/groups, killed Milkshape.
    Check out the ones I've marked with an error message. They converted
    with no error message but when I tried to open them I got a Milkshape
    message of Invalid triangles/groups, do you want to convert them?
    No I think meant nothing appeared and Yes killed Milkshape. Don't know
    if its a conversion problem or these are just bad meshes to start with.
    Thought I would get further than this but I'm out of steam right now.
    I'll check back tomorrow night.

    KE

  10. #100

    Default Re: A start on the .MESH file format

    Hi @KE

    My pudgy fingers came up with a typo which meant a variable wasn't getting refreshed. I've emailed the new version, I've tested it just now by converting the whole as_light folder in one sitting, seems to be working ok now.

    I've had a look at the mounts and the UV values are different, it seems to me that the mount texture is a third file in the composite texture, and the mount attachments uses the figure attachments texture but uses a different UV value (negative values ). I'll look into it further after I've finished with figures.

    Edit:- Just to keep people interested here's a picture of what we're getting in Milkshape.

    https://i150.photobucket.com/albums/...007/Mongol.jpg

    Cheers

    GrumpyOldMan
    Last edited by GrumpyOldMan; 03-04-2007 at 06:40.

  11. #101

    Default Re: A start on the .MESH file format

    Been trying to follow this as time allows, and it certainly is looking promising!

    Are we looking at switching to Milkshape 3D to model... or will Milkshape be more of a 'conversion tool' for getting models into a .mesh format? Personally, I would prefer Max as the tool ... but I don't know the first thing about scripting and am just glad someone can move this along!

    Realistically, how far are we from being able to export something from MS3D to .mesh? I can see you have made huge strides in getting models out of the mesh format and into a modeller, and I have got renewed enthusiasm for modding MTW2 as a result! As least I know the composition of the models and the poly counts etc. that the stock models have.

    Is there any way you could post a slightly more detailed breakdown of what the models are made up of? We have one from Caliban that I am using as a template... but I don't know if the parts it uses are the common makeup, or if they are widely different. I am also interested in knowing how many weapons/heads etc. is the maximum. For my Warhammer project, I want a reasonable degree of variation in units for Chaos .....

    If you guys are stuck for time... I am happy to help out with testing this thing. Have access to MS 1.7.8 if that will run it. Will gladly pull models out and start listing components and polycounts etc.
    Careless Orc Costs Lives!

  12. #102

    Default Re: A start on the .MESH file format

    Quote Originally Posted by GrumpyOldMan
    The figures in the Aztec bodysuit folder are different in that the initial header is 4 bytes shorter, could be because there is only a body group and no leg group? - Could be a clue to the make up of the initial header. I've put an error trap in the converter to take care of this. Some of the figures in the folders seem to be WIP or base figures.
    Sorry havent done much with this but been having major pc probs. Got a few converted off today with no errors and noticed that some are as you said base figures. Seem to be the models that were exported sans primarys and secondarys and recompiled later via the xmls. Compared a couple for changes in the initial header and noticed a few things. These are the headers from the jannisary_gunner and jannisary_musketeers meshs, models are identical bar the missing primary and secondarys:
    (leaving out the serialization::archive bit)

    Code:
    Musketeer:
    00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 04 00 01 03 01 00 00 
    00 00 00 07 00 01 00 02 00 00 00 00 00 15 00 00 00 00 00 0B 00 01 03 03
    00 00 00 04 00 00 00 
    
    Gunner
    xx xx xx xx 00 00 00 00 00 00 00 01 00 00 00 00 00 04 00 01 03 00 00 00
    00 00 00 07 00 01 00 01 00 00 00 00 00 0E 00 00 00 00 00 0B 00 01 03 02
    00 00 00 04 00 00 00
    I've marked the parts that are different in red, x'x at the start of the gunner code are there to represent the 4 bytes that are missing. I had a look at the guys in the az_body_suit folder and the guys in there missing 4 bytes look like base figures, theres corresponding meshs with weapons and the missing 4 bytes for them all, same goes for generals. It looks like every model thats used ingame has them. Only other bytes that change from file to file are the 15/0E which corresponds with the number of seperate meshs in the file and the 04 at the end, doesnt change between these two but I've noticed some mesh files have an 0C here instead. Other than that the header looks to stay the same between files.

    @Bwian, dunno about limits but the bosnian archer has 45 seperate meshs with 8 head variations

  13. #103

    Default Re: A start on the .MESH file format

    Bit more on the 04/0C value, it seems to relate to the mesh type that follows, all with 0C have an attachment as the first mesh in the file while those with 04 have a body part. Guessing its mesh variation header rather than the actual .mesh file one. Primary weapons have an 0E here, secondarys 10 and shields 07. Guess that makes the rest of the part between mesh variations footer rather than header.

    btw the geometry value for weapons and shields is added to the base model, meaning anyone who feels like tackling the hexediting should be able to make weapon kitbashs without needing an importer/exporter.

  14. #104
    Senior Member Senior Member Caliban's Avatar
    Join Date
    May 2005
    Location
    Brisbane, Australia
    Posts
    66

    Default Re: A start on the .MESH file format

    Quote Originally Posted by GrumpyOldMan
    Thanks for the information. I've noticed that as well as Attachment groups there are Equipment type groups - is there any difference? Also (probably getting ahead of myself) but with the shields some are shown as shieldpassive and some as shieldactive.
    GrumpyOldMan
    I don't think there is a difference for equipment. You can have upto 4 different attachment types.

    For example:

    gunpowder pouch (attachment)
    sword shieth (attachment1)
    jewlery (attachment2)
    quiver (attachment3)

    Each of these attachment types can have multiple variations. There is no limit on variations for any of the meshes. They are simply marked as thier mesh type (attachment, attachment1, head, body etc etc) and then the individual variation meshes are named with a sequential numbering. Head01 head02 head03 head04, pouch01, pouch02, pouch03 etc. The engine then knows to choose one of each variation by its numbering.

    Passive and Active shields are exactly what they state. However, I really don't think it makes too much difference. Passive shields are supposed to be for being attached to the back and active attached to the fore-arm. (if they are around the other way it probably doesn't matter)

    There are no hard limits on variations. You can have 50 variations or more if you really wanted to but you would have a hard time fitting them onto a texture. It's possible to up the texture size to allow for more variations but you will be increasing memory usage a fair whack as you need to do this with normal maps too.

    You can get an .SMD importer/exporter for 3dsmax here: http://www.chaosincarnate.net/cannonfodder/cftools.htm
    Created by Cannon Fodder, this tool allows you to import the .smd mesh and then the .smd skeletal file. It will automatically rig the skeleton upto the imported mesh. It's probably alot more complete than the milkshape importer/exporter. Autodesk also offer 30 day trials on 3dsmax if you need to have a play around with it: http://usa.autodesk.com/adsk/servlet...112&id=5972446

  15. #105

    Default Re: A start on the .MESH file format

    My apols GOM, see you already figured out the byte for the number of meshs in the file and what the byte before the mesh name is for, really should pay more attention The rest of the footer seems to just be a sequence of numbers which increases by meshand is constant between files

    Code:
    04 00 00 00 Body	Body		00 00 00 0A 00 01 00 04 00 00 00 0B 00 03 00 00 00 0B 00 05 00 00 00
    04 00 00 00 Legs	Leg		00 00 00 00 00 0A 00 06 00 00 00 0B 00 05 00 00 00 0B 00 07 00 00 00
    0B 00 00 00 Attach	Cylinder02	01 00 00 00 00 0A 00 08 00 00 00 0B 00 07 00 00 00 0B 00 09 00 00 00
    04 00 00 00 Arms	Arm		00 00 00 00 00 0A 00 0A 00 00 00 0B 00 09 00 00 00 0B 00 0B 00 00 00
    0B 00 00 00 Attach	Cylinder03	01 00 00 00 00 0A 00 0C 00 00 00 0B 00 0B 00 00 00 0B 00 0D 00 00 00
    0B 00 00 00 Attach	Box014		00 00 00 00 00 0A 00 0E 00 00 00 0B 00 0D 00 00 00 0B 00 0F 00 00 00
    0B 00 00 00 Attach	Plane02		01 00 00 00 00 0A 00 10 00 00 00 0B 00 0F 00 00 00 0B 00 11 00 00 00
    0B 00 00 00 Attach 	Plane04		00 00 00 00 00 0A 00 12 00 00 00 0B 00 11 00 00 00 0B 00 13 00 00 00
    06 00 00 00 Helmet	Hat04		00 00 00 00 00 0A 00 14 00 00 00 0B 00 13 00 00 00 0B 00 15 00 00 00
    04 00 00 00 Head	Head1		00 00 00 00 00 0A 00 16 00 00 00 0B 00 15 00 00 00 0B 00 17 00 00 00
    05 00 00 00 Hands	Hand01		00 00 00 00 00 0A 00 18 00 00 00 0B 00 17 00 00 00 0B 00 19 00 00 00
    04 00 00 00 Head	Head02		00 00 00 00 00 0A 00 1A 00 00 00 0B 00 19 00 00 00 0B 00 1B 00 00 00
    04 00 00 00 Head	head03		00 00 00 00 00 0A 00 1C 00 00 00 0B 00 1B 00 00 00 0B 00 1D 00 00 00
    04 00 00 00 Head	Head04		00 00 00 00 00 0A 00 1E 00 00 00 0B 00 1D 00 00 00 0B 00 1F 00 00 00
    10 00 00 00 Secnd	Sec_2		00 00 00 00 00 0A 00 20 00 00 00 0B 00 1F 00 00 00 0B 00 21 00 00 00
    10 00 00 00 Secnd	Sec_6		00 00 00 00 00 0A 00 22 00 00 00 0B 00 21 00 00 00 0B 00 23 00 00 00
    10 00 00 00 Secnd	Sec_7		00 00 00 00 00 0A 00 24 00 00 00 0B 00 23 00 00 00 0B 00 25 00 00 00
    10 00 00 00 Secnd	Sec_8		00 00 00 00 00 0A 00 26 00 00 00 0B 00 25 00 00 00 0B 00 27 00 00 00
    0E 00 00 00 Prmry	Pri_27		00 00 00 00 00 0A 00 28 00 00 00 0B 00 27 00 00 00 0B 00 29 00 00 00
    0E 00 00 00 Prmry	Pri_26		00 00 00 00 00 0A 00 2A 00 00 00 0B 00 29 00 00 00 0B 00 2B 00 00 00
    07 00 00 00 Ramrod	RR_57		00 00 00 00 00 0A 00 2C 00 00 00 0B 00 2B 00 00 00 0B 00 2B 00 00 00
    The only thing that changes is the first byte and It looks like you're right about it being related to attachments, doesnt seem to signify that its compulsoty though as some of the meshs above marked with it dont appear on all soldiers. My guess is that if theres just one type of mesh variant it gets used for all soldiers. The rest bar the first footer is just an increasing sequence and looks to be the same for all .mesh files I've looked at so far.
    Last edited by Casuir; 03-05-2007 at 03:13.

  16. #106
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @GOM
    OK, I've been testing the latest .exe from yesterday.
    Converted over 15 meshes without losing functionality
    of the button. I'll continue spot checking more units
    without closing it out just to verify it further.

  17. #107
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @GOM
    Ok, done with tonight's survey. Did 54 units without closing out
    the executable; no problems encountered. Units examined
    included the ones that caused problems with bad triangles before,
    no problems now (so marked below).


    Directory \unit_models\_units\as_light :
    Code:
    \unit_models\_units\as_light\as_light_basic_lod0            % Bad before, good now.
    \unit_models\_units\as_light\as_light_cuman_archer_lod0     % Bad before, good now.
    \unit_models\_units\as_light\dismounted_archers_lod0        % Bad before, good now.
    \unit_models\_units\as_light\kazaks_lod0                    % Bad before, good now. 
    \unit_models\_units\as_light\mongol_ballista_crew_lod0      % Bad before, good now. 
    \unit_models\_units\as_light\mongol_bombard_crew_lod0      
    \unit_models\_units\as_light\mongol_cannon_crew_lod0      
    \unit_models\_units\as_light\mongol_catapult_crew_lod0      
    \unit_models\_units\as_light\mongol_foot_archers_lod0      
    \unit_models\_units\as_light\mongol_horse_archers_lod0      
    \unit_models\_units\as_light\mongol_monster_bombard_crew_lod0      
    \unit_models\_units\as_light\mongol_trebuchet_crew_lod0

    Directory \unit_models\_units\ee_bekhtera_heavy_lamellar :

    Code:
    \unit_models\_units\ee_bekhtera_heavy_lamellar\berdiche_axemen_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\boyar_sons_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\dismounted_boyar_sons_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\dismounted_dvor_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\dvor_cavalry_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\ee_bekhtera_archer_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\ee_heavy_lamellar_archer_lod0
    \unit_models\_units\ee_bekhtera_heavy_lamellar\tsars_guard_lod0
    Directory \unit_models\_units\ee_peasant_leather :

    Code:
    \unit_models\_units\ee_peasant_leather\alan_light_cavalry_lod0
    \unit_models\_units\ee_peasant_leather\ce_wagon_fort_lod0       (In spite of name, this is a crossbowman.)
    \unit_models\_units\ee_peasant_leather\cossack_cavalry_lod0
    \unit_models\_units\ee_peasant_leather\cossack_musketeers_lod0
    \unit_models\_units\ee_peasant_leather\dismounted_lithuanian_cavalry_lod0
    \unit_models\_units\ee_peasant_leather\ee_basilisk_crew_lod0
    \unit_models\_units\ee_peasant_leather\ee_cavalry_militia_lod0
    \unit_models\_units\ee_peasant_leather\ee_crossbow_militia_lod0
    \unit_models\_units\ee_peasant_leather\ee_leather_cossack_gun_lod0
    \unit_models\_units\ee_peasant_leather\ee_peasants_lod0
    \unit_models\_units\ee_peasant_leather\ee_spearmen_lod0
    \unit_models\_units\ee_peasant_leather\gulay_gorod_lod0
    \unit_models\_units\ee_peasant_leather\slav_mercenaries_lod0
    \unit_models\_units\ee_peasant_leather\woodsmen_lod0
    \unit_models\_units\ee_peasant_leather\woodsmen_lod1
    \unit_models\_units\ee_peasant_leather\woodsmen_lod2
    Directory \unit_models\_units\es_greek_greek_heavy :

    Code:
    \unit_models\_units\es_greek_greek_heavy\byzantine_cavalry_lod0
    \unit_models\_units\es_greek_greek_heavy\byzantine_infantry_lod0
    \unit_models\_units\es_greek_greek_heavy\dismounted_byzantine_lancers_lod0
    \unit_models\_units\es_greek_greek_heavy\es_greek_iron_archer_lod0
    \unit_models\_units\es_greek_greek_heavy\es_greek_leather_lod0
    \unit_models\_units\es_greek_greek_heavy\greek_catapult_crew_lod0
    \unit_models\_units\es_greek_greek_heavy\kataphractoi_lod0
    \unit_models\_units\es_greek_greek_heavy\varangian_guard_lod0
    \unit_models\_units\es_greek_greek_heavy\varangian_guard_lod1
    \unit_models\_units\es_greek_greek_heavy\varangian_guard_lod2
    Directory \unit_models\_units\es_mail :

    Code:
    \unit_models\_units\es_mail\armenian_cavalry_lod0
    \unit_models\_units\es_mail\dismounted_christian_guard_lod0
    \unit_models\_units\es_mail\latinkon_lod0
    \unit_models\_units\es_mail\norman_knights_lod0
    Directory \unit_models\_units\es_peasant_padded :

    Code:
    \unit_models\_units\es_peasant_padded\armenian_archers_lod0
    \unit_models\_units\es_peasant_padded\es_peasant_archer_lod0
    \unit_models\_units\es_peasant_padded\skythikon_lod0
    \unit_models\_units\es_peasant_padded\turkopoles_lod0
    Obviously, the survey gets sparser as the evening wore on.

  18. #108

    Default Re: A start on the .MESH file format

    Hi All

    Lots of great things going on. I've got limited time today and a really big thunderstorm is rolling in as I type. More tomorrow, one snippet of news from the Milkshape forum:-

    Release delayed
    Hi, the new 1.7.11 release is delayed a little. I actually wanted to release it today, but I still have to add the weighted vertices support to the SMD import/export. PSK is already working.

    So maybe on Tuesday ...

    - Mete
    Cheers

    GrumpyOldMan

  19. #109
    Member Member Andromachus Theodoulos's Avatar
    Join Date
    Feb 2005
    Location
    Greenwood the Great
    Posts
    70

    Default Re: A start on the .MESH file format

    @ GOM and KE,

    You guys are doing great work.

    I would really like to help out. By testing betas, investigation and research. I am a complete newb with models and animation, but I do modify fairly intricate parts of the game, primarily textures, text files, and some code that is available for us to get to.

    I work with computers all day and multiple types of software... primarily CADD programs and Databases.

    Let me know if I can help you all in anyway, which maybe I could test stuff for you guys.

    I have MilkShape on my machine. Let me know if I need anything else and what I could do to help out.

    Thanks

    AT

  20. #110
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @All

    Been looking at the header/footers and think I've found a plausible
    breaking scheme. Let me do a normal unit first, this is
    feudal_knights_lod0


    Code:
    22 serialization::archive
       3   4   4   4     8   1   0   0  
    meshtypeint = 256
    Regular mesh, reading 4 bytes
       0   0   0   0  
       0   1   0   0     0   0   0   4     0   1   3   1     0   0   0   0     0   7   0   1     0   2   0   0     0   0   0
    number of bytes from tell()    69
    number of bytes from bytecount 69
    num_groups = 34
      0  0
    
     11  0  1  3
            3  0  0  0    Arms              arms_Lmail_01       210 (tris:)   0  0  0  0
                                                                              0  0  0  0  0 10  0  1  0
                                                                                                   4  0  0  0 11  0  3  0  0  0
    
     11  0  5  0  0  0    Legs              legs_01             244 (tris:)   0  0  0  0  0 10  0  6  0  0  0 11  0  5  0  0  0
     11  0  7  0  0  0    Hands             hands_01            202 (tris:)   0  0  0  0  0 10  0  8  0  0  0 11  0  7  0  0  0
     11  0  9  0  0  0    Legs              legs_02             244 (tris:)   0  0  0  0  0 10  0 10  0  0  0 11  0  9  0  0  0
     11  0 11  0  0  0    Arms              arms_Lmail_02       210 (tris:)   0  0  0  0  0 10  0 12  0  0  0 11  0 11  0  0  0
     11  0 13  0  0  0    Arms              arms_Lmail_03       210 (tris:)   0  0  0  0  0 10  0 14  0  0  0 11  0 13  0  0  0
     11  0 15  0  0  0    Legs              legs_03             244 (tris:)   0  0  0  0  0 10  0 16  0  0  0 11  0 15  0  0  0
     11  0 17  0  0  0    Legs              legs_04             244 (tris:)   0  0  0  0  0 10  0 18  0  0  0 11  0 17  0  0  0
     11  0 19  0  0  0    Arms              arms_Lmail_04       210 (tris:)   0  0  0  0  0 10  0 20  0  0  0 11  0 19  0  0  0
     11  0 21  0  0  0    Body              H_mail_body_01      270 (tris:)   0  0  0  0  0 10  0 22  0  0  0 11  0 21  0  0  0
     11  0 23  0  0  0    Head              Barrel_Helmet_03    192 (tris:)   0  0  0  0  0 10  0 24  0  0  0 11  0 23  0  0  0
     11  0 25  0  0  0    Head              Barrel_Helmet_01    176 (tris:)   0  0  0  0  0 10  0 26  0  0  0 11  0 25  0  0  0
     11  0 27  0  0  0    Body              H_mail_body_02      270 (tris:)   0  0  0  0  0 10  0 28  0  0  0 11  0 27  0  0  0
     11  0 29  0  0  0    Body              H_mail_body_03      270 (tris:)   0  0  0  0  0 10  0 30  0  0  0 11  0 29  0  0  0
     11  0 31  0  0  0    Head              Barrel_Helmet_02    186 (tris:)   0  0  0  0  0 10  0 32  0  0  0 11  0 31  0  0  0
     11  0 33  0  0  0    Arms              arms_Hmail_01       210 (tris:)   0  0  0  0  0 10  0 34  0  0  0 11  0 33  0  0  0
     11  0 35  0  0  0    Attachments3      teeth                24 (tris:)   0  0  0  0  0 10  0 36  0  0  0 11  0 35  0  0  0
     11  0 37  0  0  0    primaryactive0    light lance_0        78 (tris:)   0  0  0  0  0 10  0 38  0  0  0 11  0 37  0  0  0
     11  0 39  0  0  0    secondaryactive0  sword secondary_25   64 (tris:)   0  0  0  0  0 10  0 40  0  0  0 11  0 39  0  0  0
     11  0 41  0  0  0    secondaryactive0  sword secondary_26   64 (tris:)   0  0  0  0  0 10  0 42  0  0  0 11  0 41  0  0  0
     11  0 43  0  0  0    secondaryactive0  sword secondary_27   64 (tris:)   0  0  0  0  0 10  0 44  0  0  0 11  0 43  0  0  0
     11  0 45  0  0  0    secondaryactive1  sword secondary_31  108 (tris:)   0  0  0  0  0 10  0 46  0  0  0 11  0 45  0  0  0
     11  0 47  0  0  0    secondaryactive1  sword secondary_32  108 (tris:)   0  0  0  0  0 10  0 48  0  0  0 11  0 47  0  0  0
     11  0 49  0  0  0    secondaryactive1  sword secondary_33  108 (tris:)   0  0  0  0  0 10  0 50  0  0  0 11  0 49  0  0  0
     11  0 51  0  0  0    shield0           heater pattern_79    70 (tris:)   0  0  0  0  0 10  0 52  0  0  0 11  0 51  0  0  0
     11  0 53  0  0  0    shield0           heater pattern_80    70 (tris:)   0  0  0  0  0 10  0 54  0  0  0 11  0 53  0  0  0
     11  0 55  0  0  0    shield0           heater pattern_81    70 (tris:)   0  0  0  0  0 10  0 56  0  0  0 11  0 55  0  0  0
     11  0 57  0  0  0    shield0           heater pattern_82    70 (tris:)   0  0  0  0  0 10  0 58  0  0  0 11  0 57  0  0  0
     11  0 59  0  0  0    shield0           heater pattern_83    70 (tris:)   0  0  0  0  0 10  0 60  0  0  0 11  0 59  0  0  0
     11  0 61  0  0  0    shield0           heater pattern_84    70 (tris:)   0  0  0  0  0 10  0 62  0  0  0 11  0 61  0  0  0
     11  0 63  0  0  0    shield0           heater pattern_85    70 (tris:)   0  0  0  0  0 10  0 64  0  0  0 11  0 63  0  0  0
     11  0 65  0  0  0    shield0           heater pattern_86    70 (tris:)   0  0  0  0  0 10  0 66  0  0  0 11  0 65  0  0  0
     11  0 67  0  0  0    shield0           heater pattern_87    70 (tris:)   0  0  0  0  0 10  0 68  0  0  0 11  0 67  0  0  0
     11  0 69  0  0  0    shield0           heater pattern_88    70 (tris:)   0  0  0  0  0 10  0 70  0  0  0 11  0 69  0  0  0
    
      6  0  1  0 71  0  0  0  7  0  2  0  0  0 142 17  0  0  0  0  2  0  0  0  0  0
    
     18  0  1  0
           72  0  0  0  4  0  0  0  0  0    4494  (uv coords: float pairs)    0  0  0  0 17  0  1  0
                                                                                               73  0  0  0 18  0 72  0  0  0
    
     18  0 74  0  0  0  1  0  0  0          4494  (vert. wts: float pairs)    0  0  0  0 17  0 75  0  0  0 18  0 74  0  0  0  0  0  1  0  0  0  0  0
    
     23  0  1  0
           76  0  0  0  0  0  0  0  0  0    4494  (vert. vecs: float triple)  0  0  0  0 22  0  1  0
                                                                                               77  0  0  0 23  0 76  0  0  0  0  0  4  0  0  0  0  0
    
     28  0  1  0
           78  0  0  0  2  0  0  0  0  0    4494  (vert. bones: byte quads)   0  0  0  0 27  0  1  0
                                                                                               79  0  0  0 28  0 78  0  0  0
    
     28  0 80  0  0  0  3  0  0  0          4494  (mystery strm: byte quads)  0  0  0  0 27  0 81  0  0  0 28  0 80  0  0  0
     28  0 82  0  0  0 10  0  0  0          4494  (mystery strm: byte quads)  0  0  0  0 27  0 83  0  0  0 28  0 82  0  0  0
     28  0 84  0  0  0 11  0  0  0          4494  (mystery strm: byte quads)  0  0  0  0 27  0 85  0  0  0 28  0 84  0  0  0
      0  0  0  0  0  0  0  0  0  0
    Bounding sphere data: 4 floats
    0.00446363957599 0.432539612055 0.793390989304 1.68704903126
       0   0   0   0  
    Processing bone strings, number = 26
    11 bone_pelvis 0
    11 bone_rthigh 1
    14 bone_rlowerleg 2
    10 bone_rfoot 3
    8 bone_abs 4
    10 bone_torso 5
    9 bone_head 6
    8 bone_jaw 7
    12 bone_eyebrow 8
    14 bone_rclavical 9
    14 bone_rupperarm 10
    11 bone_relbow 11
    10 bone_rhand 12
    14 bone_lclavical 13
    14 bone_lupperarm 14
    11 bone_lelbow 15
    10 bone_lhand 16
    11 bone_lthigh 17
    14 bone_llowerleg 18
    10 bone_lfoot 19
    13 bone_weapon01 20
    11 bone_weapon 20
    13 bone_weapon02 21
    13 bone_weapon03 22
    13 bone_shield01 22
    11 bone_shield 22
       3   0   1   0    86   0   0   0     4   0   1   0     0   0   0   0     1   0   0   0     0   0  39   0     1   4  87   0     0   0
    number of chars 13
    characterlod0
      17   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     4   0   0   0     1   0   0   0     3   0   0   0  
      18 192  63   0     4   0   0   0   255 255 255 255   255 255 255 255   255 255 255 255   255 255 255 255     9   0   0   0  
       0   0   0  64     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     8   0   0   0     2   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0  
     128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
     128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0  
       0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0  
       0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0  38   0     1   0  88   0  
       0   0  39   0    87   0   0   0  
    0.00446363957599 0.432539612055 0.793390989304 1.68704903126
    Bytecount is now 230546
    Ignore the green highlighted stuff for the moment. It looks like you can
    make up some "rules":

    11 0 is the code for short triples (triangle data)
    18 0 is the code for float pairs (uv coords and vertex weights)
    23 0 is the code for float triples (vertex vectors and variant mystery streams, seen below in an aztec variant)
    28 0 is the code for byte quads (regular mystery data and vertex bone assignments)

    whenever you see these codes in the data header, they are repeated
    along with a "one less" code in the footer. I.e. an 11 code section
    has a 10 and 11 in its footer. This was pretty much my rationale
    for breaking them up this way, that is, grouping what seemed to be
    related data. The header and footers have running counts
    which we've seen before.

    There's also this "rule": After a two-byte code, if you get two more
    bytes that start with a 1 (these are the red highlighted parts above)
    like a 1 3 for the triangles or 1 0 in the vertex part, then you get
    an extra two bytes in the footer with 1 0. In the case of the very
    first triangle group you also get an extra 0 0 0 0 block as well.

    Edit: always forget something in long posts, in the vertex parts when
    you have a 1 0 following the code, you also get two extra zero bytes, 0 0,
    in the header.

    Let's repeat for the aztec variant:


    Code:
    22 serialization::archive
       3   4   4   4     8   1   0   0  
    meshtypeint = 0
    Variant mesh, NOT reading 4 bytes
       0   1   0   0     0   0   0   4     0   1   3   0     0   0   0   0     0   7   0   1     0   1   0   0     0   0   0
    number of bytes from tell()    65
    number of bytes from bytecount 65
    num_groups = 15
      0  0
    
     11  0  1  3
            2  0  0  0    Body              aztec               876 (tris:)   0  0  0  0
                                                                              0  0  0  0  0 10  0  1  0
                                                                                                   3  0  0  0 11  0  2  0  0  0
    
     11  0  4  0  0  0    Attachments       lip                   2 (tris:)   1  0  0  0  0 10  0  5  0  0  0 11  0  4  0  0  0
     11  0  6  0  0  0    Attachments       nose                  2 (tris:)   1  0  0  0  0 10  0  7  0  0  0 11  0  6  0  0  0
     11  0  8  0  0  0    Hands             Hands               190 (tris:)   0  0  0  0  0 10  0  9  0  0  0 11  0  8  0  0  0
     11  0 10  0  0  0    Helmet            Hat                 116 (tris:)   0  0  0  0  0 10  0 11  0  0  0 11  0 10  0  0  0
     11  0 12  0  0  0    Attachments       Ear Things           40 (tris:)   1  0  0  0  0 10  0 13  0  0  0 11  0 12  0  0  0
     11  0 14  0  0  0    Head              Head                396 (tris:)   0  0  0  0  0 10  0 15  0  0  0 11  0 14  0  0  0
     11  0 16  0  0  0    Head              Head01              372 (tris:)   0  0  0  0  0 10  0 17  0  0  0 11  0 16  0  0  0
     11  0 18  0  0  0    Head              Head02              400 (tris:)   0  0  0  0  0 10  0 19  0  0  0 11  0 18  0  0  0
     11  0 20  0  0  0    Head              Head03              404 (tris:)   0  0  0  0  0 10  0 21  0  0  0 11  0 20  0  0  0
     11  0 22  0  0  0    Head              Head04              404 (tris:)   0  0  0  0  0 10  0 23  0  0  0 11  0 22  0  0  0
     11  0 24  0  0  0    Helmet            Head Dress           24 (tris:)   1  0  0  0  0 10  0 25  0  0  0 11  0 24  0  0  0
     11  0 26  0  0  0    Body              aztec01             876 (tris:)   0  0  0  0  0 10  0 27  0  0  0 11  0 26  0  0  0
     11  0 28  0  0  0    Body              aztec02             876 (tris:)   0  0  0  0  0 10  0 29  0  0  0 11  0 28  0  0  0
     11  0 30  0  0  0    Body              aztec03             876 (tris:)   0  0  0  0  0 10  0 31  0  0  0 11  0 30  0  0  0
    
      6  0  1  0 32  0  0  0  7  0  1  0  0  0 224 16  0  0  0  0  2  0  0  0  0  0
    
     18  0  1  0
           33  0  0  0  4  0  0  0  0  0    4320  (uv coords: float pairs)    0  0  0  0 17  0  1  0
                                                                                               34  0  0  0 18  0 33  0  0  0
    
     18  0 35  0  0  0  1  0  0  0          4320  (vert. wts: float pairs)    0  0  0  0 17  0 36  0  0  0 18  0 35  0  0  0  0  0  4  0  0  0  0  0
    
     23  0  1  0
           37  0  0  0  0  0  0  0  0  0    4320  (vert. vecs: float triple)  0  0  0  0 22  0  1  0
                                                                                               38  0  0  0 23  0 37  0  0  0
    
     23  0 39  0  0  0  3  0  0  0          4320  (var myst: float triples)   0  0  0  0 22  0 40  0  0  0 23  0 39  0  0  0
     23  0 41  0  0  0 10  0  0  0          4320  (var myst: float triples)   0  0  0  0 22  0 42  0  0  0 23  0 41  0  0  0
     23  0 43  0  0  0 11  0  0  0          4320  (var myst: float triples)   0  0  0  0 22  0 44  0  0  0 23  0 43  0  0  0
    
       0   0   1   0     0   0   0   0  
    
     28  0  1  0
           45  0  0  0  2  0  0  0  0  0    4320  (vert. bones: byte quads)   0  0  0  0 27  0  1  0
                                                                                               46  0  0  0 28  0 45  0  0  0
    
       0   0   0   0     0   0   0   0     0   0
    -0.000567032024264 0.0598796904087 0.0334888845682 1.06927001476
       0   0   0   0  
    Processing bone strings, number = 20
    8 bone_abs 0
    12 bone_eyebrow 1
    9 bone_head 2
    8 bone_jaw 3
    14 bone_Lclavical 4
    11 bone_Lelbow 5
    10 bone_Lfoot 6
    10 bone_Lhand 7
    14 bone_Llowerleg 8
    11 bone_LThigh 9
    14 bone_Lupperarm 10
    11 bone_pelvis 11
    14 bone_Rclavical 12
    11 bone_Relbow 13
    10 bone_Rfoot 14
    10 bone_Rhand 15
    14 bone_Rlowerleg 16
    11 bone_RThigh 17
    14 bone_Rupperarm 18
    10 bone_torso 19
       3   0   1   0    47   0   0   0     4   0   0   0     0   0   0   0     1   0   0   0     0   0  39   0     1   4  48   0     0   0
    number of chars 13
    characterlod0
      17   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     4   0   0   0     1   0   0   0     3   0   0   0  
      18 192  63   0     4   0   0   0   255 255 255 255   255 255 255 255   255 255 255 255   255 255 255 255     9   0   0   0  
       0   0   0  64     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     8   0   0   0     2   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0  
     128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
     128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0  
       0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0  
       0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0   0   0     0   0   0   0  
       0   0   0   0   128  63   0   0     0   0   0   0     0   0   2   0     0   0   0   0   128  63   0   0     0   0   0   0  
       0   0   0   0     0   0   0   0     0   0   0   0   128  63   0   0     0   0   0   0     0   0  38   0     1   0  49   0  
       0   0  39   0    48   0   0   0  
    0.0324329286814 0.0481732748449 -0.0606130436063 1.08008432388
    Bytecount is now 330874
    The green highlights differences between the two.
    The big header line at the top has 0 1 3 1 and 0 2 0 0 for the feudal knight
    and has 0 1 3 0 and 0 1 0 0 for the variant. And as noted it has 4 bytes
    less than regular units. The variant's sequence counts are even in the
    headers but are odd for regular units.

    After the triangle data the regular unit has a sequence 7 0 2 0 but the
    variant has 7 0 1 0.

    The vertex weights lines are very similar but feudal knights has the
    final sequence 0 0 1 0 0 0 0 0 0 while the variant
    has 0 0 4 0 0 0 0 0.

    The oddest difference is on the vertex vectors line. The regular feudal
    knight unit has the extra bytes 0 0 4 0 0 0 0 0 on this line and the
    variant doesn't, yet the "codes" for both are identical. I was hoping
    to discover local rules for codes controlling what get printed in the footers
    but this case seems to rely on a global knowledge that this is a variant
    type.

    Note that not only does the variant have the mystery blocks before
    the bones assignments, the streams aren't byte quad streams as
    they are for regular units but float triples and the codes for the
    mystery blocks change to reflect that.

    Edit: the variant has attachments that have a 1 0 0 0 0 in the footer
    (this has been noted in other's posts). However what determines
    an attachment? The variant has lips, nose, and ear things as group
    names and Attachments as group type as well as head dress of type
    helmut that has the 1 0 0 0 0 but the feudal knight has teeth
    of type Attachments3 and this just has all zeros 0 0 0 0 0. What's
    the difference?

    Anyway, that's all I've got for now.
    Last edited by KnightErrant; 03-06-2007 at 22:25.

  21. #111
    Shaidar Haran Senior Member SAM Site Champion Myrddraal's Avatar
    Join Date
    Feb 2004
    Location
    UK
    Posts
    5,752

    Default Re: A start on the .MESH file format

    You're not boring anyone, I'm reading (and not understanding) every word avidly. Well done guys.

  22. #112
    Masticator of Oreos Member Foz's Avatar
    Join Date
    Dec 2006
    Posts
    968

    Default Re: A start on the .MESH file format

    Quote Originally Posted by Myrddraal
    You're not boring anyone, I'm reading (and not understanding) every word avidly. Well done guys.
    That's a perfect description of it.


    See my Sig+ below! (Don't see it? Get info here)

  23. #113

    Default Re: A start on the .MESH file format

    Hi Everybody

    Cleaned up after the storm and rain and ready to get back into it. I'm really impressed with the work @KE and @Cas have been putting into the headers and footers, I was going to suggest we take a look at them but you've already started .

    One thing I did spot in the Aztec figure was the screwed up skeleton:-

    Processing bone strings, number = 20
    8 bone_abs 0
    12 bone_eyebrow 1
    9 bone_head 2
    8 bone_jaw 3
    14 bone_Lclavical 4
    11 bone_Lelbow 5
    10 bone_Lfoot 6
    10 bone_Lhand 7
    14 bone_Llowerleg 8
    11 bone_LThigh 9
    14 bone_Lupperarm 10
    11 bone_pelvis 11
    14 bone_Rclavical 12
    11 bone_Relbow 13
    10 bone_Rfoot 14
    10 bone_Rhand 15
    14 bone_Rlowerleg 16
    11 bone_RThigh 17
    14 bone_Rupperarm 18
    10 bone_torso 19
    Not quite as neat and hierarchical as the '4' regular figures and the weapon/shield bones are missing. I've printed out the excellent stuff you've done and will now sit down and come up with a pattern for extracting stuff stored in the Milkshape file and storing it in a Mesh file. Incidentally, just because the files are stored in a MS3D file format, doesn't mean you have to use Milkshape. The format is becoming available in a number of software products, I'm currently having a look at FragMotion as an alternative modeller and animation creater. MS3D also opens up in LithUnwrapper and Ultimate Unwrap for skinning (and conversion) purposes.

    Right, I'll sit down now and come up with some rules and pseudo code for the header/footers. As you guys look through the files could you just take notice of the bounding sphere values and see if they follow any sort of pattern ie dependent on foot vs mounted, or sword vs lance, etc. That may be handy to come up with some default values.

    Everybody else that's offered to help, there'll be a place for anybody willing to risk a ctd in the name of progress , if you can make the necessary changes to get a new figure into M2TW that would be a great help too.

    Cheers

    GrumpyOldMan

  24. #114
    The Philosopher Duke Member Suraknar's Avatar
    Join Date
    Dec 2002
    Location
    Navigating the realm of Ideas
    Posts
    707

    Default Re: A start on the .MESH file format

    Hrm...

    I kind of understand now why the Data\Text\export_units.txt is not a .txt file this time around...methinks we were not expected to be making new models.

    But, I have to say many of you seem to be doing very great progress here :)
    Duke Surak'nar
    "Η ΤΑΝ Η ΕΠΙ ΤΑΣ"
    From: Residing:
    Traveled to: Over 70 Countries, most recent: and

    ~ Ask not what modding can do for you, rather ask what you can do for modding ~
    ~ Everyone dies, not everyone really fights ~

  25. #115
    The Philosopher Duke Member Suraknar's Avatar
    Join Date
    Dec 2002
    Location
    Navigating the realm of Ideas
    Posts
    707

    Default Re: A start on the .MESH file format

    Alrighty,

    After a bit of reasearch, I came up with this:

    http://www.radgametools.com/granny/download.html

    You can freely Download the Granny Viewer, which comes with 2 sample .gr2 files, which may help you ellucidate some things if you can analyse them.

    It seems like Radgametools however holds the licences (and they seem a greedy bunch too), many other games have this issue, and I got this from moding forums of AOEIII.

    Correct me if I am wrong but from what I understand what your trying to do here is break the .mesh format not the gr2 format, and then if you can do that it could be reversible providing us with a way to do some modeling.

    I will be looking for alternatives such as using .xml templates to probably be able to mix and match models (Body of A with head of B) from existing stock models (should not be against any licensing doing that).

    I wish success to you :)
    Duke Surak'nar
    "Η ΤΑΝ Η ΕΠΙ ΤΑΣ"
    From: Residing:
    Traveled to: Over 70 Countries, most recent: and

    ~ Ask not what modding can do for you, rather ask what you can do for modding ~
    ~ Everyone dies, not everyone really fights ~

  26. #116
    Member Member KnightErrant's Avatar
    Join Date
    Jan 2007
    Location
    Huntsville, Alabama USA
    Posts
    458

    Default Re: A start on the .MESH file format

    @Suraknar
    Yes, what GrumpyOldMan, Casuir, and myself have been calling
    header/footer lines are probably granny strings. So we're essentially
    trying to reverse engineer the granny strings and understand their
    syntax to make a back and forth converter that makes no use of
    any proprietary software. This would then be legal and freely
    distributable.

  27. #117
    blaaaaaaaaaarg! Senior Member Lusted's Avatar
    Join Date
    Feb 2005
    Posts
    1,773

    Default Re: A start on the .MESH file format

    I kind of understand now why the Data\Text\export_units.txt is not a .txt file this time around...methinks we were not expected to be making new models.
    You could say the same for all the fiels which are now .string.bins, and which alpaca has made a converter for.

  28. #118
    Harbinger of... saliva Member alpaca's Avatar
    Join Date
    Aug 2003
    Location
    Germany
    Posts
    2,767

    Default Re: A start on the .MESH file format

    Quote Originally Posted by Lusted
    You could say the same for all the fiels which are now .string.bins, and which alpaca has made a converter for.
    Nah they were just converted into a format that could be read more quickly by the machine.
    The game was probably developed without thinking of modding to any large extent (except for some individuals, such as Caliban and Palamedes) and therefore the designers and programmers just used what yielded the best results in the shortest time possible.

    Now it seems that we won't get any more official tools any time soon (maybe Caliban can explain why?) I'm glad to see that you guys are making quite a good deal of progress on this, and even more, provide us with a possible free way of editing models
    I wish I had more time on my hands so I could work a bit on this, too. Anyways, after you cracked this customer, you should also have a look at the settlement packages (it seems there's some cool stuff in there and it's a lot more flexible than RTW)
    Last edited by alpaca; 03-07-2007 at 17:20.

  29. #119

    Default Re: A start on the .MESH file format

    Question here on weapon bones, a weapon skeleton(s) is specified in the unit xml which is used to compile the finished .mesh so I'm guessing this bone data is pulled from there?
    Code:
    	<Skeletons>
    		<Skeleton>
    			<Mount>Horse</Mount>
    			<Primary>MTW2_HR_Spear</Primary>
    			<Secondary>MTW2_HR_Non_Shield</Secondary>
    			<PrimaryAttachment>MTW2_HR_spear_Primary</PrimaryAttachment>
    			<SecondaryAttachment>MTW2_Sword_Primary</SecondaryAttachment>
    		</Skeleton>
    There looks to be a number of different primary/secondary skeletons in the idx, would these affect things or are they just neccessary due to the way ca compiled the models? Also could animated weapons be possible?

    Re bounding spheres, theres only 4 values here so its xyz and a radius aye? From what I've seen the radius for dismounted is usually around 1.0-3 and mounted lancers 2.0-1, mounted archers and such are usually the same as infantry so I'm guessing the mounts are handled separately and weapons affect the size.

    Quote Originally Posted by Suraknar
    I will be looking for alternatives such as using .xml templates to probably be able to mix and match models (Body of A with head of B) from existing stock models (should not be against any licensing doing that).
    This wont be possible with an xml file afaik, the data is mixed up to much for it to be possible without extracting the parts from the .mesh and writing a completely new file. Changing primary/secondarys is possible with a bit of hex editing but unless you had some way of automatically re-writing the triangle values it could take you some time.

  30. #120
    Senior Member Senior Member Caliban's Avatar
    Join Date
    May 2005
    Location
    Brisbane, Australia
    Posts
    66

    Default Re: A start on the .MESH file format

    I think maybe the knifeman has an animated weapon but I'm told animating the weapon bone can cause some freaky results.

    The skeletons below simply tell the game what animation set to use for this unit. The example below means that his primary attack is a Spear animation set and his secondary is non_shield.
    You can look up these animation sets by searching for MTW2_HR_Spear in data\descr_skeleton.txt All unit skeleton types are listed in here.
    For example if you wanted him to play sword animations for his secondary, you would replace MTW2_HR_Non_Shield with -> MTW2_HR_Sword
    If you wanted his primary to be mace animations you would replace MTW2_HR_Spear with -> MTW2_HR_Mace

    Hope this helps :)

    <Skeletons>
    <Skeleton>
    <Mount>Horse</Mount>
    <Primary>MTW2_HR_Spear</Primary>
    <Secondary>MTW2_HR_Non_Shield</Secondary>
    <PrimaryAttachment>MTW2_HR_spear_Primary</PrimaryAttachment>
    <SecondaryAttachment>MTW2_Sword_Primary</SecondaryAttachment>
    </Skeleton>

Page 4 of 22 FirstFirst 1234567814 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Single Sign On provided by vBSSO