FF 13 3D models ripping possible ...

[orbbu]

Wow, amasing job, too bad I don't (and will never) have a debug console T.T

Any chance you could share some completed models ? In priority : Lightning, for example -.-

That's really a shame I have bought the game at full price and can't even extract the models myself... btw, I'm curious about something : the movies are also encrypted (there is a folder "movie" of about 31 GB), are you able to watch the files on your PC with your debug console ?

[chrrox]

[orbbu]

That's really mean to tease us like that *cry*

Just kidding, great job ! As always

Just wandering, how many polys in this character ? I saw in Ninja gaiden 2 almost 80.000 polygones in the main characters... the current gen consoles are really monsters -.-

[orbbu]

Did you test your tools on the X360 version (the PAL version is available...) ? Can you please share them ?

[orbbu]

Here's a sample from the X360 version, 2 files, that seems to be the 3d model + textures of one character.

Can you please share the structure informations you managed to guess for these 2 file types ? I could use that to code my own converters.

Thanks in advance

Sample : http://www.sendspace.com/file/cq8dff

[Novax]

Couldn't you also use this method to dump PS2 game models and the such or not?

[orbbu]

@novax:

I don't know, this script is specific to the new White Engine by Square Enix, and I think that the only game released that use this engine is FF13... (I'm pretty sure Versus 13 will use it too)

[kekko]

Any hope of getting some info on the file format?

[kekko]

I've made some progress

as you can see I'm experiencing some troubles with the tristrip. does anyone know how to get a triangle list out of them?

>>link<<
If you have some ideas on how to fix it, please let me know.

[jouzumania]

really nice. there is progress! and i am addicted to it! please let us know when you made new steps

[revelation]

The data in Final Fantasy 13 is not in tri-strip form, they are indexed triangle lists.

[kekko]

yep you're right, that was just a bug in the exporter
thanks

[kekko]

ok it seems it's working fine

uv coords, normals, bones/skinning and texture files left to do.
of course any help will be appreciated.

[revelation]

Code: Select all

struct CHILD_HEADER
{
	// 0x00
	uint32 dataTag           <format = hex>;
	uint32 unknown0x04;
	uint32 dataSize          <format = hex>;
	uint32 nextOffset        <format = hex>;
};

struct MESH_STMS_DECL
{
	uint16 stream;
	uint16 offset;
	uint32 type;
	uint32 count;
	uint16 usage;
	uint16 index;
};

struct WRB_MDLC_MDL_MESH_STMS
{
	// 0x00
	struct CHILD_HEADER header;
	
	// 0x10
	uint32 declCount;
	uint32 dataCount;
	uint32 dataSize   <format = hex>;
	uint32 unknown0x1C;
	
	SetBackColor(cLtGreen);
	struct MESH_STMS_DECL dataDeclarations[declCount];
	
	SetBackColor(cLtBlue);
	struct
	{
		uint8 dataBytes[dataSize];
	} data[dataCount];
};

Hope it helps.

Don't mind the structure names. They are overly descriptive since i was naming them as i was deciphering the data in the file. But that should help you with the structure of the STMS section. i still have the textures to do myself as well, as soon as time permits.

Code: Select all

	int iDeclEntry = 0;
	for (iDeclEntry = 0; iDeclEntry < declCount; ++iDeclEntry)
	{
		switch (vertexDecl[iDeclEntry].usage)
		{
		case 0:
			iVertex = iDeclEntry;
			break;
		case 2:
			iNormal = iDeclEntry;
			break;
		case 8:
			iTexture = iDeclEntry;
			break;
		case 0xF:
			iIndices = iDeclEntry;
			break;
		case 0xE:
			iWeights = iDeclEntry;
			break;
		}
	}

[MrAdults]

Texture chunk headers (the trb files are all laid out as generic resource lists and include original file names and extensions of each resource, so you should probably iterate them correctly to get to the appropriate resource types):

Code: Select all

typedef struct txbHdr_s
{
	BYTE			id[8];
	int				unknownA;
	int				unknownB;
	int				texSize; //seems like original size, does not include padding
	int				unknownC[7];
	int				unknownD;
	int				unknownE[3];
} txbHdr_t;
typedef struct gtexHdr_s
{
	BYTE			id[4];
	WORD			unknownA;
	BYTE			imgFmt;
	BYTE			numMips;
	WORD			unknownC;
	WORD			width;
	WORD			height;
	WORD			unknownD;
	int				unknownE;
	int				unknownF;
} gtexHdr_t;

For 360 files, members of gtex are all big endian, while txb members are little endian. Following the gtex header are offsets into the image bundle for each texture and the total size of the texture + mips (including padding), also in big endian. An offset exists for each mip level, although strangely the offsets are all the same instead of pointing to each mip as you would expect.

I'm currently writing a dxt data untiler that will work universally across block sizes and image resolutions. However, I cannot believe no one has done this yet, since linking to 360 XDK libs is obviously not reasonable for most apps.

Has anyone already done this? If so, I'd really appreciate you sharing your code, ideally before I finish mine. This is a pain in the ass and I do not want to re-invent the wheel if I don't have to.

Edit: Oh well, already finished the untiler. Also noticed unknownB was the image format, so far have only seen values of 3 and 24.