[PS2] Armored Core 2 through Armored Core: Last Raven

[Greg]

A few moths ago, I took a break from the Front Mission games just to poke around the the PS2 entries of Armored Core and made a surprisingly rapid amount of progress on their model file formats. The last hurdle I've been experiencing for most of this time is face formation- meshes are composed of either a triangle list (for FX spawn points) or multiple triangle strips. The strips are a problem as it's not clear where one should end and another should begin. I've tried looking in the model file for a flag but found nothing that stood out, then shifted to studying the verts and UVs in hopes they they contain some sort of "rhythm" to no real success. using UVs or the distance between points to determine face formation still yields "bad" faces. I've poked around a few PS2 topics here and it sounds like this is the best I can hope for but would like a second opinion before going forward.               

 

File, meshes, and tmr.7z

Edited August 12 by Greg
accidental post

[roocker666]

I made a script for Noesis but it creates a lot of extra faces. This is a very common problem when you try to autogenerate faces in some PS2 modes, I hate that...

[Greg]

Thanks for the reply. I've shifted to studying the extra faces and have noticed the following characteristics so far - impossible UVs, not forming connections at their hypotenuse either in terms of vert or UV coordinates, bridge large gaps, form at the "seams" of connected faces, etc. It may be possible to filter them out with a long enough chain of if-statements though partial filtering I'm currently performing results in an index error when I try to import the model. I'll report back with the results.      

[Greg]

I should probably go over the file formats as I did with the Front Mission games.  

Barring Armored Core: Last Raven, the Armored Core games share a simple, near identical file structure. The model file header is as follows:
01-?? 00 00 00 . . . . FF FF FF FF 00 00 00 00
01-?? 00 00 00 . . . . EE EE EE EE 00 00 00 00

Bytes 4-7 are the model file size. ACN is unique in that it uses both headers and not just the first. Models with the second header are compressed but can be accessed through eeMemory. I don't know the range of the first byte but haven't found any need to narrow it down. I had hoped the first byte denoted the type of model (scenery, weapon, etc) but that isn't the case. 

The mesh headers are as follows:
. 80 00 00 00 40 02-3E 30|31 12 04 00 00 00 00 00 00
. 80 00 00 00 40 02-3E 30|31 12 04 00 00 00|01 00 00 00 . 80 00 00 00 40 02-3E 30|31 12 04 00 00 00|01 00 00 00

The first bye is the number of verts. Every game between AC2 and ACLR uses the second, "double header." Vertices, normals, and UVs are all neatly ordered floats that directly proceed each mesh header.  

As I said before, ACLR's format is different. So much so I held off doing more work on it until I figured out face generation for the previous entries. ACLR, like ACN, is also compressed (I think LZS?) and I believe its model file header is 19 08 00 10 XX XX XX XX . . . . XX 00 XX 00, where the XXs denote random byte values. Verts seem to be either shorts or floats, I didn't figure out the mesh header.     

I found all of this by forming vert clouds out of long, rhythmic stretches of bytes in eeMemory and searching until I found shapes that looked "intentional" in all of that mess before narrowing things down. Once I knew where the verts were, finding the UVs and normals was easy as they were right next to each other. Finally, finding the headers involved investigating where files and vert data seemed to start and end, then seeing if there was a pattern to the bytes that could be found at these points. All techniques either learned on my own or were taught by some of the vets, here.    

The model headers seem to cover the whole gamut of model types in each game, leading to thousands of files. I've attached the scripts I used to extract model files from each games .bin, a script to further screen out duplicate model files, and my unfinished model file converter.   


 

Scripts.7z

Edited August 18 by Greg

[Greg]

I've found the source of those index errors, it's the last face of the seventh mesh. It's complete garbage possessing both "bad" verts and UVs, something I didn't think was possible for the first and last face of a mesh. I doublechecked the bytes in the model file and the coordinates are definitely correct, though I'm confused as to what purpose they serve.  

Mesh 7.7z

[Greg]

I've altered the conversion script and it's now filtering out faces with bad UVs without issue. "Bad" faces generally come in pairs but the first face of the pair doesn't always possess bad UVs, this results in the unintentional deletion of a face that was meant to exist along with the second face. This would make my approach to filtering a waste of time if not for the fact that the bad faces possessing good UVs seem to consistently share an edge with two other faces, something that can likewise be tested for and filtered out. After filtering faces both by their UVs and verts, most of the bad faces should be eliminated.         

New Armored Core Model Converter.7z