-
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 :-
Quote:
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 :dizzy2: , it may sound strange but let me know as soon as possible if you find any that can't be converted :laugh4: .
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
-
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.:oops: )
-
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.
-
Re: A start on the .MESH file format
Hi @KE
Quote:
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:-
Quote:
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 :beam: .
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
-
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.
-
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.
-
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 :juggle2: .
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
-
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
Quote:
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.:holiday:
KE
-
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.:dizzy2:
I'll check back tomorrow night.
KE
-
Re: A start on the .MESH file format
Hi @KE
My pudgy fingers came up with a typo :oops: 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
-
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.
-
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
-
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.
-
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
-
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 :embarassed: 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.
-
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.
-
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.~:)
-
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:-
Quote:
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
-
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
-
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.~:)
-
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.
-
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.
-
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 :2thumbsup: .
One thing I did spot in the Aztec figure was the screwed up skeleton:-
Quote:
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 :laugh4: , if you can make the necessary changes to get a new figure into M2TW that would be a great help too.
Cheers
GrumpyOldMan
-
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 :)
-
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 :)
-
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.
-
Re: A start on the .MESH file format
Quote:
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.
-
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 :yes:
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) :whip:
-
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.
-
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 :)
Quote:
<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>