MechAssault 2: Lone Wolf for Xbox, Material & Geometry Format (.mgf)
This format has been broken down to enable mesh & texture extraction. I have compiled available resources & tutorials into one download. Noesis, Hex2Obj, QuickBMS not included.
Mech Wolf (1.0): http://www.mediafire.com/file/0765kr4zj ... f_V1.0.zip
Many, many, many, many Thanks to AceWell, akderebur & shakotay2 for their help in breaking down this format.
Original Post
I'm hoping with the near release of BattleTech, perhaps someone has a place in their heart for MechWarrior models or something. Or at least could for the love of extraction please help?
Shakotay, AceWell, chrrox, anyone? I've been trying for years to get help on this without success. As always, I'm willing to write whatever script need be to translate stuff to a more useable format, but I'm not skilled enough to know how to break everything down without at least being pointed in the correct direction. I'm willing to compensate, games, gift card, etc if there's anyway that knowledge can lead to Blender scripts, a Noesis plugin or even access through Hex2Obj.
Here's a script I wrote to provide the initial offset values and locations of some datablocks, but that is still a far cry from sufficient.
https://www.mediafire.com/file/x0tu8bl2 ... a_V0.5.zip
File Samples: https://www.mediafire.com/file/zc2m2cd2 ... _Files.zip
I figure there is one of two ways to possibly tackle this. The traditional method of reversing it. Here's the documentation on the MGF Format
https://www.mediafire.com/file/n9js8khw ... ources.zip
As best I can tell stuff is stored in a tree format. I've worked with trees & iterables, but not from a hex stand point, so I would still need help with the pattern before creating something recursive to parse it.
The other method might be to make use of the parsers that were already made. I don't work with C, so I don't know the first thing about identifying what's needed for compiling purposes. But if someone thinks that is possible, there is a capability of converting to Radiance, also something that I don't know anything about, but perhaps that would negate the manual processes if capable of converting to something more easily imported.
https://www.mediafire.com/file/n16kouor ... gflib2.zip
Thank you so much to anyone in advance, who can help. I've really been wanting some of MechAssault 2's characters for some art projects, that I've never been able to realize due to missing the models from it.
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
[Xbox][MGF] MechAssault 2 / Material & Geometry Format
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
[Xbox][MGF] MechAssault 2 / Material & Geometry Format
Last edited by Protocol X27 on Sat Apr 21, 2018 4:58 pm, edited 2 times in total.
-
- double-veteran
- Posts: 640
- Joined: Fri Jul 08, 2011 10:36 am
- Has thanked: 65 times
- Been thanked: 898 times
Re: [MGF] Material & Geometry Format
I can give some examples in hex2obj. Here are two meshes I got from "00000614_3dlobby.mgf".
I actually don't know what kind of 3d models to expect from these files but the meshes appear to somewhat sensible. So I think I got them right.
I used "idxbin" and "vertbin" keywords to locate the index and vertex data quickly. You can probably locate them fine with your data block scripts. It seems like vertex data comes before the index data. If you find the indices, the vertex data for them is right above the indices.
Vertex blocks appear to be 20 bytes for all the meshes. Float seems correct for the vertex positions. I haven't checked the uvs.
I don't know if you already knew this stuff, but I hope it helps you with your research. Unfortunately I don't have the time to dig deeper and mechas aren't my cup of tea really Good luck.
I actually don't know what kind of 3d models to expect from these files but the meshes appear to somewhat sensible. So I think I got them right.
I used "idxbin" and "vertbin" keywords to locate the index and vertex data quickly. You can probably locate them fine with your data block scripts. It seems like vertex data comes before the index data. If you find the indices, the vertex data for them is right above the indices.
Vertex blocks appear to be 20 bytes for all the meshes. Float seems correct for the vertex positions. I haven't checked the uvs.
I don't know if you already knew this stuff, but I hope it helps you with your research. Unfortunately I don't have the time to dig deeper and mechas aren't my cup of tea really Good luck.
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
@akderebur !!!!!!
That's friggn' incredible! Thank you! That's essentially half the battle right there, and I wasn't even expecting that so quick. No, it's all new info to me, so I should be able to patch some stuff together so I can process the values like I have done with other scripts. I did a test and changed the UV Pos to 16 and changed Float to HF_UV, it appears to be look like reasonable UV's, so I'm really hoping that's true once I get a chance to export a couple.
If that's your limit, it's already much appreciated. I'm after the human characters anyway, lol. If I may ask one more thing, would you have any tips for me to locate the images? I know their names are squashed together, and it appears that most of them are tifs, but I have not successfully figured out where their data starts or their lengths. If not, I can hopefully find another brain to pique, but this will give me plenty to dissect for the moment. I'll drop ya a PM later to see if there's any boon I can throw your way.
That's friggn' incredible! Thank you! That's essentially half the battle right there, and I wasn't even expecting that so quick. No, it's all new info to me, so I should be able to patch some stuff together so I can process the values like I have done with other scripts. I did a test and changed the UV Pos to 16 and changed Float to HF_UV, it appears to be look like reasonable UV's, so I'm really hoping that's true once I get a chance to export a couple.
If that's your limit, it's already much appreciated. I'm after the human characters anyway, lol. If I may ask one more thing, would you have any tips for me to locate the images? I know their names are squashed together, and it appears that most of them are tifs, but I have not successfully figured out where their data starts or their lengths. If not, I can hopefully find another brain to pique, but this will give me plenty to dissect for the moment. I'll drop ya a PM later to see if there's any boon I can throw your way.
-
- double-veteran
- Posts: 640
- Joined: Fri Jul 08, 2011 10:36 am
- Has thanked: 65 times
- Been thanked: 898 times
Re: [MGF] Material & Geometry Format
I will go to sleep now, but I can give it a try tomorrow. I am still not very good with identifying image data in hex though.
I think AceWell will take a look at the files when he sees this thread He might be able to get those images.
I think AceWell will take a look at the files when he sees this thread He might be able to get those images.
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
Sounds like a plan. I've run out of day time too, but I at least got the script updated the to export a list of vertbin & idxbin locations. It's not the exact positions shown in your examples, but I'll adjust that on the next pass.
http://www.mediafire.com/file/sauvsvlfy ... a_V1.1.zip
Edit:
Ok, not quite done for the night yet, lol. I updated the script again now to put index data first and give the vertex & index counts.
I've also found a few items that have an FVF of 24, no biggie there. BUT it looks like some of the character models are different. In the 3D lobby file the characters are toward the end of the list and range in 1000-2000+ Verts. Looks like some low poly models use FVF 36, but may not have UV's. Looks like higher poly character parts use FVF 56....
>> Bingo!! This is part of one of the pilots I was looking for.
Edit 2: Just some notes if of interest. It looks like there is an 'MGI' before a lot of the 'PIC' blocks. I think the image length is 0x08 bytes from PIC, and I think the actual data starts 0x72 from PIC (just guesses of course). There are some parameters for height, width, mips, etc before the data starts, so hopefully that can help with constructing the header properly to pair it up with the data. As soon as I get a chance, I'll start updating the script to list PIC locations and stats, until I can jump straight to dumping the full image.
http://www.mediafire.com/file/sauvsvlfy ... a_V1.1.zip
Edit:
Ok, not quite done for the night yet, lol. I updated the script again now to put index data first and give the vertex & index counts.
I've also found a few items that have an FVF of 24, no biggie there. BUT it looks like some of the character models are different. In the 3D lobby file the characters are toward the end of the list and range in 1000-2000+ Verts. Looks like some low poly models use FVF 36, but may not have UV's. Looks like higher poly character parts use FVF 56....
>> Bingo!! This is part of one of the pilots I was looking for.
Edit 2: Just some notes if of interest. It looks like there is an 'MGI' before a lot of the 'PIC' blocks. I think the image length is 0x08 bytes from PIC, and I think the actual data starts 0x72 from PIC (just guesses of course). There are some parameters for height, width, mips, etc before the data starts, so hopefully that can help with constructing the header properly to pair it up with the data. As soon as I get a chance, I'll start updating the script to list PIC locations and stats, until I can jump straight to dumping the full image.
- shakotay2
- MEGAVETERAN
- Posts: 4284
- Joined: Fri Apr 20, 2012 9:24 am
- Location: Nexus, searching for Jim Kirk
- Has thanked: 1147 times
- Been thanked: 2242 times
Re: [MGF] Material & Geometry Format
about the mgf format: the samples you've provided are binary but the format specs (mgfdoc.pdf) are about ASCII mgf ("human-readable ASCII text"); so is the sample in the mgflib-project, examp1-mgf:
there's xml blocks in the binary mgf files but they are different from the above:
Code: Select all
# The following vertices go with the outer casing
v vc1+ =
p 24 3.0625 -1.75
n 0 0 -2
v vc2+ =
...
Code: Select all
<xmlres>
<material_specular_mask version="1" name="sky_planet mat" diffuse="255, 255, 255" selfillum="55, 55, 55" shininess="4.00000000" shin_strength="0.20000000" spec_color="237, 167, 57" opacity="1.00000000" two_sided="false" shading="gouraud" blending="normal" specular_bloom="0.20000000">
...
Tuts: a) Bigchillghost, viewtopic.php?f=29&t=17889
b) Extracting simple models: http://forum.xentax.com/viewtopic.php?f=29&t=10894
"Quoting the whole thing. Would u ever stop this nonsense?"
b) Extracting simple models: http://forum.xentax.com/viewtopic.php?f=29&t=10894
"Quoting the whole thing. Would u ever stop this nonsense?"
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
@shakotay,
If the documentation itself is not that useful, it's okay. When I was struggling to get assistance with this a while back, it was all I could even find on the format. Like with any engine, I would assume that the developer could have re-purposed the container. Day One Studios didn't exactly make all the much anyway, so who knows their logic in choosing a non-standard format. I was just trying to be useful do what I could while arm twisting for support back in the day, lol.
Since the meshes & uv's are proving to be a reality, it would seem that the skeletons may be the useful thing to dissect out of there if it lined up in anyway. But beyond images at this point, please disregard that unless it's for a personal curiosity.
If the documentation itself is not that useful, it's okay. When I was struggling to get assistance with this a while back, it was all I could even find on the format. Like with any engine, I would assume that the developer could have re-purposed the container. Day One Studios didn't exactly make all the much anyway, so who knows their logic in choosing a non-standard format. I was just trying to be useful do what I could while arm twisting for support back in the day, lol.
Since the meshes & uv's are proving to be a reality, it would seem that the skeletons may be the useful thing to dissect out of there if it lined up in anyway. But beyond images at this point, please disregard that unless it's for a personal curiosity.
-
- double-veteran
- Posts: 640
- Joined: Fri Jul 08, 2011 10:36 am
- Has thanked: 65 times
- Been thanked: 898 times
Re: [MGF] Material & Geometry Format
Yea, my bad. I said all meshes have 20 bytes for vertex blocks but clearly I haven't checked enough meshesProtocol X27 wrote:Looks like some low poly models use FVF 36, but may not have UV's. Looks like higher poly character parts use FVF 56....
Anyway I did take a look at the vertex blocks for that pilot you posted and it seems like starting from offset 36 (in 56 bytes vertex block) is related to skinning. First 4 bytes are bone ids, so 1 byte for each bone id. The remaining 16 bytes in the block are 4 floats, and they are the weights.
I tried to mark those sections I mentioned. Decided to show it on the second vertex block since it has 2 bones. Sorry for my bad image editing skills.
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
@akderebur
No worries, I know that info during research is a work in progress and images don't need to be complicated to get the point across. That's how I do those too. Thanks for posting that. I'm lacking in know how to get the skeleton or even how to get one working through Noesis or Blender, so I would need a crash course in the department to put the weight data to use.
Here's a script update. I added an Image Meta exporter including Height, Width, Offsets & Length. I started on a process that can merge the image data with an existing TIFF placeholder since I don't know how to write TIFF headers/footers. It's a sloppy way to do it, and it's not in complete working order yet. I'll need help with remaining image stuff since I don't know how the mips, depth or bits could affect the file size. :-/ As a side note, I added some padding to make the Mesh meta exporter easier to read too.
http://www.mediafire.com/file/qj9styn59 ... a_V1.2.zip
No worries, I know that info during research is a work in progress and images don't need to be complicated to get the point across. That's how I do those too. Thanks for posting that. I'm lacking in know how to get the skeleton or even how to get one working through Noesis or Blender, so I would need a crash course in the department to put the weight data to use.
Here's a script update. I added an Image Meta exporter including Height, Width, Offsets & Length. I started on a process that can merge the image data with an existing TIFF placeholder since I don't know how to write TIFF headers/footers. It's a sloppy way to do it, and it's not in complete working order yet. I'll need help with remaining image stuff since I don't know how the mips, depth or bits could affect the file size. :-/ As a side note, I added some padding to make the Mesh meta exporter easier to read too.
http://www.mediafire.com/file/qj9styn59 ... a_V1.2.zip
-
- VIP member
- Posts: 1330
- Joined: Wed Nov 05, 2008 12:16 pm
- Has thanked: 2710 times
- Been thanked: 884 times
Re: [MGF] Material & Geometry Format
here is bms script to extract the files with names from your mgf samples
Code: Select all
# script for QuickBMS http://aluigi.altervista.org/quickbms.html
idstring "mgf "
get FOLDER basename
get UNK long
get ZERO long
get TABLE1_ENTRIES long
get TABLE1_SIZE long
get TABLE1_OFFSET long
get TABLE2_ENTRIES long
get TABLE2_SIZE long
get TABLE2_OFFSET long
get STR_TABLE_SIZE long
get STR_TABLE_OFFSET long
goto 0x14 0 seek_cur
for i = 1 to TABLE1_ENTRIES
get UNK2 long
get UNK3 longlong
get SIZE[i] long
get SIZE2 long
get UNK4 long
get OFFSET[i] long
get UNK5 long
next i
for i = 1 to TABLE1_ENTRIES
get CHECK long
if CHECK == 0
get UNK6 long
get UNK7 long
get UNK8 long
get STR_OFFSET long
xmath NAME_OFFSET "STR_TABLE_OFFSET + STR_OFFSET"
get UNK9 long
savepos TMP
goto NAME_OFFSET
get NAME string
string NAME p "%s\%s" FOLDER NAME
log NAME OFFSET[i] SIZE[i]
goto TMP
else //skipping unique folders
goto 0x14 0 seek_cur
math i - 1
endif
next i
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
@AceWell !!! Incredible, that's killer! That's going to help pare down all the extra meshes that I'm looking for.
Works like a champ. I did try opening the tif files after using the script, and it looks like their custom meta information is still packaged with it so Photoshop/GIMP won't recognize them. Any ideas how I could translate 'em properly?
Works like a champ. I did try opening the tif files after using the script, and it looks like their custom meta information is still packaged with it so Photoshop/GIMP won't recognize them. Any ideas how I could translate 'em properly?
-
- VIP member
- Posts: 1330
- Joined: Wed Nov 05, 2008 12:16 pm
- Has thanked: 2710 times
- Been thanked: 884 times
Re: [MGF] Material & Geometry Format
yep that is the next step, had to sort the files first, and also never trust extensions,
the "tif" files have the best header i think i've seen though, tells you everything.
the "tif" files have the best header i think i've seen though, tells you everything.
-
- ultra-veteran
- Posts: 341
- Joined: Wed Dec 14, 2011 5:46 pm
- Has thanked: 141 times
- Been thanked: 128 times
Re: [MGF] Material & Geometry Format
Awesome, didn't know you already had a plan. If so, I'll patiently await your intel.
That sounds like good advice, I guess it's something learned along that way that I hadn't encountered enough yet. I agree that it is nice to have those values available. So with tinkering trying to better understand the format, I can't make sense of the sizes in comparison to the dimensions. I was testing a 512 x 512 image and the size provided seemed smaller than if it were the normal RGBA quantity of bytes for an image of the same size. Even without bytes for alpha channel, I couldn't make it line up, so I'm sure there's more to it than my limited knowledge.
That sounds like good advice, I guess it's something learned along that way that I hadn't encountered enough yet. I agree that it is nice to have those values available. So with tinkering trying to better understand the format, I can't make sense of the sizes in comparison to the dimensions. I was testing a 512 x 512 image and the size provided seemed smaller than if it were the normal RGBA quantity of bytes for an image of the same size. Even without bytes for alpha channel, I couldn't make it line up, so I'm sure there's more to it than my limited knowledge.
- shakotay2
- MEGAVETERAN
- Posts: 4284
- Joined: Fri Apr 20, 2012 9:24 am
- Location: Nexus, searching for Jim Kirk
- Has thanked: 1147 times
- Been thanked: 2242 times
Re: [MGF] Material & Geometry Format
I've made some research concerning the submesh alignment of Natalia.
In the xml file Nat_PilotHairDown_Cinema.MGMODEL there's positions of head and root (assumed: transform4)
layer15
<bone name="bone_head" transform1="0.00000298 -1.00000024 0.00003227 0.00000000" transform2="-1.00000000 -0.00000313 0.00000075 0.00000000" transform3="-0.00000073 -0.00003230 -1.00000012 0.00000000" transform4="-0.08515804 0.07527932 0.04588023 1.00000000"/>
<bone name="bone_root" transform1="1.00000000 0.00000000 0.00000000 0.00000000" transform2="0.00000000 1.00000000 0.00000000 0.00000000" transform3="0.00000000 0.00000000 1.00000000 0.00000000" transform4="-0.07527588 0.56100762 -0.09257832 1.00000000"/>
The idea is to build the difference for the vertical axis for example then move the head in blender vertically 'til the same difference is met.
Sadly it didn't work as expected: the difference of the transforms is 0.561 -0.0753 = 0.4857 while in blender it's 0.454 (see picture, 0.28176 + 0.17216 = 0.45392).
Maybe bone_root position is different from the body position?
Maybe some other layer lines to be used or this line
<node_skinned version="1" name="nat_pilot_body" position="0.00001215, 0.20967650, 0.05826531" rot_axis="-1.00000000, 0.00000000, 0.00000000" rot_angle="0.00000000" scale="1.00000000, 1.00000000, 1.00000000" turned_on="true" collidable="true" bounds_cover_children="false" max_normal_mapped_lights="255">
but I couldn't find a suiting line with _head" position="
btw: using WordUV instead of HF_UV gives better results
In the xml file Nat_PilotHairDown_Cinema.MGMODEL there's positions of head and root (assumed: transform4)
layer15
<bone name="bone_head" transform1="0.00000298 -1.00000024 0.00003227 0.00000000" transform2="-1.00000000 -0.00000313 0.00000075 0.00000000" transform3="-0.00000073 -0.00003230 -1.00000012 0.00000000" transform4="-0.08515804 0.07527932 0.04588023 1.00000000"/>
<bone name="bone_root" transform1="1.00000000 0.00000000 0.00000000 0.00000000" transform2="0.00000000 1.00000000 0.00000000 0.00000000" transform3="0.00000000 0.00000000 1.00000000 0.00000000" transform4="-0.07527588 0.56100762 -0.09257832 1.00000000"/>
The idea is to build the difference for the vertical axis for example then move the head in blender vertically 'til the same difference is met.
Sadly it didn't work as expected: the difference of the transforms is 0.561 -0.0753 = 0.4857 while in blender it's 0.454 (see picture, 0.28176 + 0.17216 = 0.45392).
Maybe bone_root position is different from the body position?
Maybe some other layer lines to be used or this line
<node_skinned version="1" name="nat_pilot_body" position="0.00001215, 0.20967650, 0.05826531" rot_axis="-1.00000000, 0.00000000, 0.00000000" rot_angle="0.00000000" scale="1.00000000, 1.00000000, 1.00000000" turned_on="true" collidable="true" bounds_cover_children="false" max_normal_mapped_lights="255">
but I couldn't find a suiting line with _head" position="
btw: using WordUV instead of HF_UV gives better results
You do not have the required permissions to view the files attached to this post.
Tuts: a) Bigchillghost, viewtopic.php?f=29&t=17889
b) Extracting simple models: http://forum.xentax.com/viewtopic.php?f=29&t=10894
"Quoting the whole thing. Would u ever stop this nonsense?"
b) Extracting simple models: http://forum.xentax.com/viewtopic.php?f=29&t=10894
"Quoting the whole thing. Would u ever stop this nonsense?"
-
- VIP member
- Posts: 1330
- Joined: Wed Nov 05, 2008 12:16 pm
- Has thanked: 2710 times
- Been thanked: 884 times
Re: [MGF] Material & Geometry Format
here is first draft of Noesis python script to open the tif texture samples
it opens about 90 percent of the samples, there is still a couple
swizzled formats that i have not worked out yet but they are usually
effect or UI textures, the main ones you need should be handled.
i will update the script when i figure the rest out.
supports dxt1, dxt3, dxt5, morton swizzled rgba8888it opens about 90 percent of the samples, there is still a couple
swizzled formats that i have not worked out yet but they are usually
effect or UI textures, the main ones you need should be handled.
i will update the script when i figure the rest out.
You do not have the required permissions to view the files attached to this post.