XeNTaX

Hi there, just joined after finding the unpacker for this game on Zenhax: http://zenhax.com/viewtopic.php?t=2625

Saw that the engine was the same base as god of war and there was some discussion of that games 3d format here so used that as a starting point. Have some idea how to break up the data now but thought someone here might see something obvious i'm missing. Doesn't seem like hex2obj would like this format as I think the faces must be inferred through tri-strips.

This is where i'm at so far:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6D 6F 64 65 6C 00 00 00 "model" header

A0 00 00 00 byte size of mesh data (excludes next four bytes)
20 67 23 00 x,y,z offset?

00 00 00 00 6B BF 67 43 - 16 bytes of stuff
00 00 00 00 87 14 6D 43

A3 0E 1C 0C 07 00 09 00 VIF codes (used to create faces recursively from vertices, 07's next to 69 = vertex count. 5th byte seems to equal vertex count if only one submesh)
01 00 00 CD 00 00 00 00
00 80 02 69 07 00 1C 0C
08 00 CD CD 00 00 00 00
02 80 07 69 .................

...............00 7D 00 7D Vertices
00 00 00 83 00 7D 00 00
00 7D 43 5C 00 00 00 83
43 5C 00 00 00 7D 43 5C
00 00 00 83 00 00 00 00
00 7D 00 00 00 00 00 00

01 80 07 6A 00 00 80 00 Normal - 7 x 3(3x1 byte) with zero padding keeping 8 byte alignment, ps2 is 64bit
00 80 01 00 81 00 00 81
00 00 80 00 00 81 01 00
81 00 00 00 00 00 00 00

00 80 07 65 3E 00 00 00 UV - 7 x 4(2x2 byte)
33 03 00 00 3E 00 8C 04
33 03 8C 04 3E 00 8C 04
33 03 EB 00 3E 00 EB 00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Guessed the normals and UV would be the same as God Of War - FurryFan found the same two 4 byte tags there, vertices seem to have '69' instead of '6D' in tag, maybe devs were feeling naughty.
viewtopic.php?f=16&p=68272#p68272

Any help would be appreciated.

I'd guess for quads but autocreation of face indices might be the wrong idea: In fact there's a good chance that they use byte indices (0..255) since the model might be split up into 105 submeshes (but not sure).

Hmm, vertices in your example look ok, kind of building shaped. Can see what looks like storeys in the fake FI's picture, will have to try your settings and play around with faces a bit.

Maybe it will be easier if I can find a recognisable building and snapshot it in pcsx2 for comparison.

EDIT:The object you used there Shakotay started with a 'lineseg' header viewing in a hex editor, could that mean it's not meant to have faces somehow? seems those use float whereas objects starting with the 'model' header use shorts for vertices.

Here's a screen of one model I grabbed with fake indices, need to clean up some extra triangles but I think you can see a shop front in there. Had a look at the texture format too, should help to test if the mesh results match up. The format starts with the 'header image16' and seems to come after the mesh (not always alternating, sometimes two meshes before two textures, maybe for the two stories of buildings).

Unsurprisingly it's 16 bit per pixel, 128 square (Texmod gave me the res). Transparency is used in the game so I guess 5 bit per colour with 1 bit alpha makes sense.

The second two lines here seem to match the layout of the 'model' sections (2 bytes with 2 byte zero padding) so maybe some kind of header which applies to both assets.

Sample:
69 6D 61 67 65 31 36 00------------------------------------------ 'image16'
00 01 00 00 -------------------------------------------------------- Part of header? seems to be fixed value
5F 12 00 00 -------------------------------------------------------- 2 bytes, second is always 12 so maybe just a single byte variable
50 50 7B 7B 7B 7B 7B 7B 7B 7B 7B 7B 50 7F 4F 7F ------------- pixel block
6D 6D 6D 6D 15 15 15 96 EF 15 EF EF 15 15 96 EF
6D 6D 15 6D 6D 6D 6D 6D 6D 6D 15 15 6D 6D 6D 15
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 15
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D
CA 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D 15 96
6D 6D 6D 5A 6D 16 6D 6D 6D 5A 6D 16 6D 6D 95 6D
9E 9E 9E 95 9E 3B 3B 08 9F 19 95 95 9E 9E 9E 95
9E 9E 95 95 95 08 08 19 08 93 19 95 95 95 95 9E
9E 9E 95 95 95 3B 3B 3B 95 95 95 96 96 96 9E 96

Just realised the pixel block seems to only have enough data for one row or column of 16 bit pixels, guess that must mean some kind of compression. the texmod output does seem to have some artefacts like a jpeg

Hi



I made several Getaway 3d model rip projects, most are not done.
I can give you some insight in the format.


For the textures:

The image16 struct consists of:

unint64 Header; // image16.
uint32 always_256;
uint32 Gim_ID;
char data[256];


The Gim_ID is the most important one.The gim textures are located in the pak file.


GIM Texture

uint32 GIM_HEADER;
uint32 SIZE;
uint32 UNPACKED_SIZE;
uint32 NULL;
uint32 GIM_HEADER_2;
uint32 Ccccc;
uint32 UNK;
uint32 TEXTURE_ID;


They are your usual swizzled ps2 textures, however I tried to get a texture out of them using "Console Texture Explorer".I have come close, but no sigar.

I will give more info later on the polystrips and the 256 data in the image16.

TheGift wrote:GIM Texture

Noesis has native support for *.gim textures

Cheers Gift, nice to see some other people still interested in this game haha.

Ah, makes sense that the 'image16' is just a GIM reference, realised there were other sizes of texture when i used texmod again.

Again may be able to crack the format if I can find a way to link the texmod output to a particular GIM.

Ace I couldn't get Noesis to open the GIM, seems to be modified from the common psp format (starts with a GIM header rather than MIG), the actual important data might be similar to some other GIM though.

DentistGuba wrote:Ace I couldn't get Noesis to open the GIM, seems to be modified from the common psp format (starts with a GIM header rather than MIG), the actual important data might be similar to some other GIM though.

can you upload some not working gim samples for examination please?

I hope someone can crack the gim format, ps2 swizzling is a nightmare for me .In the attachment are gim textures from The Getaway:Blackmonday

Just as I suspected, you're looking at VIF code:
Note that the VIF codes start at offset 0x20 after 'model' header, and is 16-byte aligned.
Apologies if I don't have more data to provide, my VIF parser is horribly buggy/unfinished at the moment and was written for another game. I had to hack together code and turn off a lot of checks in order to even get this output. Also note that the "ADDR" and "NUM" stuff is part of the official spec for VIF tags used by the PS2, so it's very very low-level stuff I suppose. A lot of it is independent to each game how its processed and used, etc.

Hopefully this is useful to someone out there!

Thanks CarLuver, with this stuff it helps a lot to 'know what you don't know' haha.

Updated my original post with a VIF section, think I got it right.

Think I may have found the building I was testing with hex2obj, grabbed the texture too which seemed to fit with flatten mapping (haven't made a script yet to test uv's)
Looks a lot flatter in game so possibly meshes are normalised to use all the limited precision of short vertex coordinates (at least in the 'depth' axis).

Just tried a manual cleanup of the straight tri-strip model I ripped before (from 00002b1e.por in the extracted blocks at offset 32020).

30 out of 48 were 'real' faces (axis aligned edges).

the scrap faces were:
3,4,
7,8,
11,12,
15,16,
19,20,
23,24,
27,28,
31,32,
35,36,

Here's how it looks in vertex tri-strips (blue=filling vertex buffer, red=skip face):
1,2,
3,4,
5,6,
7,8,
9,10,
11,12,
13,14,
15,16,
17,18,
19,20,
21,22,
23,24,
25,26,
27,28,
29,30,
31,32,
33,34,
35,36,
37,38,
39,40,41,42,43,44,45,46,47,48,49,50

So kind of quad based but why discarded quad padding rather than just skipping a single triangle to start the next strip. The front face of the building does form a nice neat tri-strip so maybe the dev's tools could only strip co-planar faces.

Not exactly efficient memory use, using the weld modifier in 3ds max (well gmax, I don't exactly have 2 grand to spare each year for the same program) got this model down to 20 verts - under half the original mesh. Could there be some runtime reason for this storage?

dunno which face indices you used in the end but seems you're on a good way: (as a deja vue only: https://forum.xentax.com/viewtopic.php? ... ds#p103400)

edit: upps, well, see I'm growing too old, you've posted that picture already...