Iron Man 3 model files
Posted: Mon Feb 24, 2014 12:58 am
Hello,
I have been researching how to read the model files from the gameloft game Iron Man 3 (in my case for android).
So far I have:
- Extracted the OBB
- Extracted the model (bdae) and texture (pvr) archives
- Converted the textures
- Identified the useful parts of the model files
Other users on this forum; renato (who also frequents http://www.therpf.com/f78/iron-man-3-su ... ea-183397/ as Balmung) and zaramot have made progress on this already.
Here is my problem...
I can generate a mesh with UV coordinates from a single file by manually tweaking a max script to select different areas of the file, but I would like to understand the file structure better in order to be able to navigate to this point based on data in the file, and possibly also get more from it like bones, skinning (for animation) and materials (mainly so I know it inverts the normals for the mirrored half). At the moment only the first 3 floats and the last long are being used from the 52 bytes of each vertex, and I'd like to know what they are (I expect probably normals and stuff, but haven't tested)
As well as knowing the patterns to look for in the hex to do it manually, I have also found the array lengths in the file too, but only relative to the mesh/vertex data, not the start of the file as it moves.
I am attaching an excel spreadsheet with the analysis I have been trying to do on the file.
- Sheet 1 - High Level: this page summarises what sections I (think I) have identified in the file structure, two examples the Mk 2 and Mk 42 (first and last in the game)
- Sheet 2 - Header Analysis (Low Level): this page contains dumps of each armour file's header section. I have identified very little of it, but I have managed to identify patterns and try to break it into sections based on this. The left hand column details the min, median, max and mode values for each long in the file (taking into consideration the gaps I have made to try to mark sections). To the best of my understanding, most of this seems to be junk. The values usually just increase by 4 from an initial starting number marked in red at the top. You will notice on the left there is also a percentage. I find this useful to see where there are file-unique numbers which might be useful. One thing to bear in mind is that I'm mostly taking interest in the DIFFERENCES between the long in the file and the previous long, not the actual value. One last note - Mark 38 (Igor) doesn't seem to match up with any of this. Don't ask me why...
If this header data is indeed junk, at least the last 4 longs in each file are identical, so that lets me jump to the strings, which are easy to navigate through.
I would really appreciate any assistance in decoding these files further from someone with more experience with binary file reverse engineering.
NOTE: The zipped excel sheet has a macro for converting hex to a float I found on the net. Nothing dodgy. I had to remove all the formulas in the second column of each file to reduce the file size to upload, so just copy the formula down for each file to restore it (I don't know why excel can't compress this somehow).
I have been researching how to read the model files from the gameloft game Iron Man 3 (in my case for android).
So far I have:
- Extracted the OBB
- Extracted the model (bdae) and texture (pvr) archives
- Converted the textures
- Identified the useful parts of the model files
Other users on this forum; renato (who also frequents http://www.therpf.com/f78/iron-man-3-su ... ea-183397/ as Balmung) and zaramot have made progress on this already.
Here is my problem...
I can generate a mesh with UV coordinates from a single file by manually tweaking a max script to select different areas of the file, but I would like to understand the file structure better in order to be able to navigate to this point based on data in the file, and possibly also get more from it like bones, skinning (for animation) and materials (mainly so I know it inverts the normals for the mirrored half). At the moment only the first 3 floats and the last long are being used from the 52 bytes of each vertex, and I'd like to know what they are (I expect probably normals and stuff, but haven't tested)
As well as knowing the patterns to look for in the hex to do it manually, I have also found the array lengths in the file too, but only relative to the mesh/vertex data, not the start of the file as it moves.
I am attaching an excel spreadsheet with the analysis I have been trying to do on the file.
- Sheet 1 - High Level: this page summarises what sections I (think I) have identified in the file structure, two examples the Mk 2 and Mk 42 (first and last in the game)
- Sheet 2 - Header Analysis (Low Level): this page contains dumps of each armour file's header section. I have identified very little of it, but I have managed to identify patterns and try to break it into sections based on this. The left hand column details the min, median, max and mode values for each long in the file (taking into consideration the gaps I have made to try to mark sections). To the best of my understanding, most of this seems to be junk. The values usually just increase by 4 from an initial starting number marked in red at the top. You will notice on the left there is also a percentage. I find this useful to see where there are file-unique numbers which might be useful. One thing to bear in mind is that I'm mostly taking interest in the DIFFERENCES between the long in the file and the previous long, not the actual value. One last note - Mark 38 (Igor) doesn't seem to match up with any of this. Don't ask me why...
If this header data is indeed junk, at least the last 4 longs in each file are identical, so that lets me jump to the strings, which are easy to navigate through.
I would really appreciate any assistance in decoding these files further from someone with more experience with binary file reverse engineering.
NOTE: The zipped excel sheet has a macro for converting hex to a float I found on the net. Nothing dodgy. I had to remove all the formulas in the second column of each file to reduce the file size to upload, so just copy the formula down for each file to restore it (I don't know why excel can't compress this somehow).