Jump to content

Vice City PS2 dff format


The Hero

Recommended Posts

Hi,

I wonder if any of you guys tried to decrypt the ps2 dff format of vice city. Maybe you could post what you've discovered so I can continue that work.

After being able to understand (thanks to steve-m) the sa ps2 dff format (even wrote a simple converter dff->obj) I'm now trying to research the vc ps2 dff format, which seems to be more complex and difficult.

Now, what I've discovered so far is, that the native data section begins with a 4 byte constant that always is 4 (like sa).

Then follow some unknown bytes and then comes (probably) the vertex data.

Then (I think) come the uv coords and the vertex colors and finally some zeros.

This pattern can be repeated n times. Maybe interrupt of vertex strip (like 0x0080 flag after vertex positions in sa dffs).

 

Vertex colors can easily be recognized since the last (of 4) bytes is always 0xFF.

I also came across a list with 4 byte values that have 0x3F in the end. I thought that may be the uv coords, but I'm not sure.

 

So, maybe someone has discovered similar things and could post it here.

Any help will be appreciated.

Link to comment
Share on other sites

OK, this is what I could find out today:

 

 

dword 04 00 00 00

--split start--

dword splitsize (splitsize+current position+4 = nextsplit)

 

--splitpart start--

32 bytes unknown (maybe only 12 bytes, the other 20 bytes belong to the section above)

Edit: Not necessarily 32 bytes.

dword 00 80 XX 68 XX = Vertexcount

Now follow XX vertices with 3 floats each (xyz).

Edit: If Vertexcount is odd -> 8 bytes padding.

 

12 bytes unkown

dword 01 80 XX 64 XX = Vertexcount

Now follow UV Coordinates with 2 floats each (UV) (haven't tested it but looks reasonable).

 

12 bytes unknown

dword 02 C0 XX 6E XX = Vertexcount

Now follow Vertex Colors in RGBA (1 bytes each) format (also not 100%, but 99.9%).

 

12 bytes unknown

dword 03 80 XX 6A XX = Vertexcount

Now follow probably Normals but in the files that I used to decrypt the fileformat this section is filled with zeros.

Edit: Probably 3 bytes per Vertex (scaled ?)

 

Then follow some unknown bytes I believe.

--splitpart end--

This splitpart is repeated n times with a different Vertexcount.

-split end--

 

The whole fileformat still needs much research and here is what I couldn't decode so far:

-How does a Split (and Splitpart) end? Looks like as if there is some kind of padding with 0s.

-How do I know how many bytes are there in the beginning (after the splitsize).

-Why are there splitparts?

-Where is indicated where a vertestrip is interrupted? Importing Vertices and connecting them produces too much polygons. SA Vertices have a flag in the end that indicates that.

 

 

Tomorrow I will continue my research smile.gif

Edited by THE HERO
Link to comment
Share on other sites

 

I'd like to refer you to the LCS/VCS modding forum in Misc. Some of my recent discoveries there may or may not help.

 

Alex

 

Link to comment
Share on other sites

Alright that's my progress:

Note: actors have a different format, I'll try to find that out next.

 

04 00 00 00

--split start--

dword splitsize (splitsize+current position+4 = nextsplit)

01 00 00 00

unknown, incremented for each split

00 00 00 00

00 00 00 11

00 00 00 06

--splitpart start--

16 bytes vertexheader: last four bytes: 00 80 XX 68: XX = Vertexcount

Now follow XX vertices with 3 floats each (xyz).

The Coordiantes are 16 byte aligned.

 

16 bytes uvheader: last four bytes: 01 80 XX 64: XX = Vertexcount

Now follow UV Coordinates with 2 floats each (UV) (haven't tested it but looks reasonable).

The UVs are also 16 byte aligned.

 

16 bytes vertexcolorheader: last four bytes: 02 C0 XX 6E: XX = Vertexcount

Now follow Vertex Colors in RGBA (1 bytes each) format.

Also 16 byte aligned.

 

16 bytes normalheader: last four bytes: 03 80 XX 6A: XX = Vertexcount.

Probably 3 bytes per Vertex (scaled ?)

Also 16 byte aligned.

 

A splitpart ends with the following bytes:

XX 00 00 04: XX = Vertexcount (although there is no need for it, maybe used in actors)

00 00 00 15: only if it's the first splitpart in the current split, otherwise 17

00 00 00 11:

00 00 00 06: These two indicate the end of a split, otherwise 00

 

Then follow some unknown bytes, haven't figuered out their use.

--splitpart end--

Then follows the next splitpart until the current split is complete.

-split end--

Note: Subsection headers are always pretty much the same:

unknown, incremented for each header

00 00 00 05 (I think 07 is also possible in some cases)

04 01 00 01

section type (vertex, uv etc.)

 

 

I was able to write a decent converter to obj (although i haven't implemented normals, vertexcolors (not supported by obj) and UV coords) and it works.

it can import about anything apart from actors.

Link to comment
Share on other sites

 

Alright that's my progress:

Note: actors have a different format, I'll try to find that out next.

 

04 00 00 00

--split start--

dword splitsize (splitsize+current position+4 = nextsplit)

01 00 00 00

unknown, incremented for each split

00 00 00 00

00 00 00 11

00 00 00 06

--splitpart start--

16 bytes vertexheader: last four bytes: 00 80 XX 68: XX = Vertexcount

Now follow XX vertices with 3 floats each (xyz).

The Coordiantes are 16 byte aligned.

 

16 bytes uvheader: last four bytes: 01 80 XX 64: XX = Vertexcount

Now follow UV Coordinates with 2 floats each (UV) (haven't tested it but looks reasonable).

The UVs are also 16 byte aligned.

 

16 bytes vertexcolorheader: last four bytes: 02 C0 XX 6E: XX = Vertexcount

Now follow Vertex Colors in RGBA (1 bytes each) format.

Also 16 byte aligned.

 

16 bytes normalheader: last four bytes: 03 80 XX 6A: XX = Vertexcount.

Probably 3 bytes per Vertex (scaled ?)

Also 16 byte aligned.

 

A splitpart ends with the following bytes:

XX 00 00 04: XX = Vertexcount (although there is no need for it, maybe used in actors)

00 00 00 15: only if it's the first splitpart in the current split, otherwise 17

00 00 00 11: 

00 00 00 06: These two indicate the end of a split, otherwise 00

 

Then follow some unknown bytes, haven't figuered out their use.

--splitpart end--

Then follows the next splitpart until the current split is complete.

-split end--

Note: Subsection headers are always pretty much the same:

unknown, incremented for each header

00 00 00 05 (I think 07 is also possible in some cases)

04 01 00 01

section type (vertex, uv etc.)

 

 

I was able to write a decent converter to obj (although i haven't implemented normals, vertexcolors (not supported by obj) and UV coords) and it works.

it can import about anything apart from actors.

 

A comparison with LCS:

 

In LCS:

 

vertex positions: short integer, results in large boxes, must be mutlipled with xyz scale factors from the geometry header and probably also need an additional global scale.

 

UV coords: 1 byte per coordinate, 2 bytes per tvert. Divide by 127 (I think) and flip v-wise

 

vertex colors: 1 short per vertex, R5G5B5A1 format (or was it reverse?)

 

normals: 3 bytes per vertex, 1 byte per coordinate, divide by 127, take care of sign flips.

 

Alex

Link to comment
Share on other sites

So, I am now able to import actors, there's only a slight difference, this is the Native Data Struct:

 

XX is always the Vertex count.

 

 

04 00 00 00

 

---Split Start:

 

splitsize00 00 00 00 if actor, else 01 00 00 00

 

---splitpart start:

Actors use this section:

 

XX 00 00 30unknown dword05 01 00 0104 80 XX 6C00 00 00 1000 00 00 0000 00 00 0000 00 00 004d 00 00 1000 00 00 0000 00 00 0000 00 00 00

 

Else the following is used:

 

unknown word00 00 00 0000 00 00 1100 00 00 06

 

 

Then come the subsections's headers and data (16 byte aligned):

 

unknown dword00 00 00 0504 01 00 01 or 05 01 00 01 if actorsection type (00 80 XX 68: Vertex, 01 80 XX 64: UV, 02 C0 XX 6E: Vertex colors, 03 80 XX 6A: normals)

 

 

Vertices: 3 floats: XYZ

UV: 2 floats: UV (I wasn't able to import them correctly though)

Vertexcolors: 4 bytes: RGBA

Normals: 3 bytes: XYZ (I wasn't able to import them correctly either)

 

A splitpart ends with these bytes:

 

XX00000400 00 00 15 if first splitpart, else 1700 00 00 11 if last splitpart, else 0000 00 00 06 if last splitpart, else 00

 

-- splitpart end

---spit end

Now follow unknown bytes. Haven't figuered out their use.

 

Perhaps somebody can find out about normals and uv data, since I wasn't able to import them correctly using my dff2obj converter.

If someone is willing, I'll provide him with my dff to obj converter so he can modify the code for uv and normals and test it (written in C).

It can convert the whole model correctly (apart from some dffs that seem to have a different face structure) and I haven't included support for materials so you would have to apply a texture manually (or just see if the uv coordinates look reasonable).

Edit: Oh, and I haven't implemented rotation either.

 

Edit2: corrected description, probably still some errors.

Edited by THE HERO
Link to comment
Share on other sites

Has anybody tried to hack Xbox formats?

 

Xbox is awesome,and PS2 is the same as PC.

user posted image

"Stealing, running, fighting, punching, kicking, screaming. This is the way I have chosen to live. I will accept the consequences"

Link to comment
Share on other sites

If you give me some examples, I could try it.

Link to comment
Share on other sites

 

If you give me some examples, I could try it.

you need models? just a sec,I'll try digging that damn topic up...

 

EDIT: Dug it up,all the models and textures are here.

 

Well,here actually

 

OK,and now,after 10 hours of VC stunting practice,I'm off to bed,bye.

Edited by Claude GTA3

user posted image

"Stealing, running, fighting, punching, kicking, screaming. This is the way I have chosen to live. I will accept the consequences"

Link to comment
Share on other sites

Oh, it's not even a standard dff...more like a completly new file format I suppose.

I thought it's only the Geometrysection that's unknown. Well, that would require more time, I maybe try it when I have more time.

Link to comment
Share on other sites

Oh,OK,Cool. May I remind you that if you do this,you will unleash the power of Xbox's HI-POLY GTA'S!!! tounge2.gif

user posted image

"Stealing, running, fighting, punching, kicking, screaming. This is the way I have chosen to live. I will accept the consequences"

Link to comment
Share on other sites

Oh,OK,Cool. May I remind you that if you do this,you will unleash the power of Xbox's HI-POLY GTA'S!!! tounge2.gif

 

I have already looked at 3 xbox dffs and I can tell you this: it's not a different format, it's simply a form of lz compression, that means it backreferences bytes it has already seen in some form, otherwise it's a normal .dff. The tricky part about it is: how does the backreferencing scheme work? If you want to get it decompressed, my advice is to pm aru about it. I think he was the one who decompressed the lcs archives too.

 

As for uvs and normals. An ideal model for figuring out uvs is the money mdl and any kind of door. If you can import these properly, you're halfway through.

 

Alex

 

 

Link to comment
Share on other sites

Oh,OK,Cool. May I remind you that if you do this,you will unleash the power of Xbox's HI-POLY GTA'S!!!  tounge2.gif

 

I have already looked at 3 xbox dffs and I can tell you this: it's not a different format, it's simply a form of lz compression, that means it backreferences bytes it has already seen in some form, otherwise it's a normal .dff. The tricky part about it is: how does the backreferencing scheme work? If you want to get it decompressed, my advice is to pm aru about it. I think he was the one who decompressed the lcs archives too.

 

As for uvs and normals. An ideal model for figuring out uvs is the money mdl and any kind of door. If you can import these properly, you're halfway through.

 

Alex

Thanks for the advuce,and the lecture,but I doubt he'll do it,I mean,why would anyone do anything for an ignorant motherf*cker like me? Unless he does it for the good of the community tounge.gif

 

Also,I dunno jack sh*t about this df decompressing so I couldn't explain anything

user posted image

"Stealing, running, fighting, punching, kicking, screaming. This is the way I have chosen to live. I will accept the consequences"

Link to comment
Share on other sites

Oh,OK,Cool. May I remind you that if you do this,you will unleash the power of Xbox's HI-POLY GTA'S!!!  tounge2.gif

 

I have already looked at 3 xbox dffs and I can tell you this: it's not a different format, it's simply a form of lz compression, that means it backreferences bytes it has already seen in some form, otherwise it's a normal .dff. The tricky part about it is: how does the backreferencing scheme work? If you want to get it decompressed, my advice is to pm aru about it. I think he was the one who decompressed the lcs archives too.

 

As for uvs and normals. An ideal model for figuring out uvs is the money mdl and any kind of door. If you can import these properly, you're halfway through.

 

Alex

Thanks for the advuce,and the lecture,but I doubt he'll do it,I mean,why would anyone do anything for an ignorant motherf*cker like me? Unless he does it for the good of the community tounge.gif

 

Also,I dunno jack sh*t about this df decompressing so I couldn't explain anything

 

Last time I talked to him, he seemed sympathetic to the idea. PM about it and mention the conversation me and him had about the gta3 xbox game. It's probably some kind of lz78 derivative, as there seem to be pointers to some dictionary in the header, unless I am mistaken. But I am a newb at this myself, so don't take my word for it.

 

Alex

 

 

Link to comment
Share on other sites

I PM-ed him,he said he'll try.

user posted image

"Stealing, running, fighting, punching, kicking, screaming. This is the way I have chosen to live. I will accept the consequences"

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 1 User Currently Viewing
    0 members, 0 Anonymous, 1 Guest

×
×
  • Create New...

Important Information

By using GTAForums.com, you agree to our Terms of Use and Privacy Policy.