Dead or Alive series formats and tools

[finale00]

What about the 110 110 20 20 thing?
It looks like no matter how I parse it, I'm going to end up with two of the same indices in a single triangle.

So in the attached image of an xpr file

After reading the header, I run into 0x80 00 00 00, read in the dataSize, I should skip that many bytes and continue reading ID's until I reach EOF, and then go back to all of the offsets I stored and parse them?

[mariokart64n]

parse until the ID is -1
guessing the IDs off the top of my head...

00000080 = Binary Entry
00010004 = texture dimension
00010080 = texture offset/size?
00010083 = vertex offset

I said before parsing the XPR is pointless, because the 0000008 ID is always at the same area of the XPR header. and the MDL follows directly after.

however more correctly, you parse the IDs, throughout the XPR.

you guys were treating the XPR as the model, but its just a generic texture container created by Microsoft.
so your MDL bloc is just a user entered bloc in the XPR

doesn't matter aslong as you can get to the MDL bloc really. but I thought I would clear up what was going on with the IDS

chunk based formats always got
BlocID
DataBuffer
EndOfFile


next, if you read in a duplicated face, you need to break the strip. read 3 more and continue again reading one at a time.

blender should have a tristrip function of some sort? otherwise theres another user here who makes importers. you could refer to his code to get a better idea


EDIT

Hmmmm...

Center and radius of *what* though?

I think every material I've looked at (though admittedly, that's not a whole lot) has all 0x00 for the line marked "emissive". What exactly is emissive anyway? Does it make sense for it to be 0 most of the time?

(For that matter, I'm not too sure about diffuse, ambient, or specular either...)

-FM77's lack of new coding projects caused by a sudden need to play Metroid Prime. Su!!

Center+radius maybe using in optimize speed of calculation.
for example: calculate z-order during rendering or collision during fighting.

if you imagine material block as sub-mesh that contain material property, it seem that all's well.
typedef struct _submesh {
...
center,radius
d3dmaterial
numTextures
...
Tex[]
subset
}
it also is imagination, might be wrong.
below is some information about MS Direct3d Material.
typedef struct _D3DMATERIAL8 {
D3DCOLORVALUE Diffuse;
D3DCOLORVALUE Ambient;
D3DCOLORVALUE Specular;
D3DCOLORVALUE Emissive;
float Power;
} D3DMATERIAL8;
specular and emissive property of a material are both determine how a material reflects light.
-specular property: Determines how a point of light on a *shiny* object corresponds to the reflected light source.
-emissive property: Determines whether a material *emits* light.
-Power: Floating-point value specifying the sharpness of specular highlights. To turn off specular highlights for a material, set this member to 0.0; setting the specular color components to 0 is not enough.

[gjinka]

So some files are encrypted huh? And I was thinking AFSExplorer extracted corrupted files. Any ideas of the encryption? We know each file starts with an "XPR" so that could be a hint. Not an ordinary XOR though.
The xprbreaker source uses mixed C/assembly code. It's too complicated for me.

Trianglestrips (tristrips) work like this: firstly two vertices are created, the 3rd forms a triangle with the previous two. But unlike ordinary triangles, you dont need to read 3 more to create another triangle again. Each new vertex will create a new triangle with the previous two.
Look at this image, each number is a vertex index: http://arcsynthesis.org/gltut/Positioni ... eStrip.svg

But that is (was) just a rendering optimization for DirectX, I don't thing 3d modellers support that and it doesn't make much sense either. I have no idea how to recreate a trianglestrip in a future exporter though. The order of the exported vertices matters. There might be some complex algorithm.
I don't know, Blender might have a helper function to load trianglestrips, but it will probably create ordinary triangles in the end.

OK, I think things are starting to make sense.
1) read the header.
2) loop the chunks, which will tell you where to read vertex buffers and texture buffers (2nd part of the file)
3) read the MDL, which contains the OBJ, which contains the materials.
4) read vertex buffers and texture buffers (2nd part of the file)

Guess I'll just write a script and see how it goes.

Some infos are still missing though: the different vertex types. I could use the sourcecode of doaxexporter to add the info to the spreadsheet and later we can post it in the wiki.

There are more that is mentioned in the spreadhseet though:

Code: Select all

typedef struct {  // D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX1
	FLOAT	vx, vy, vz;
	FLOAT	nx, ny, nz;
	FLOAT	u, v;
} ST_VERTEXFORMAT0_0;

typedef struct {  // D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX1
	FLOAT	vx, vy, vz;
	DWORD	dwDiffuse;
	FLOAT	u, v;
} ST_VERTEXFORMAT0_1;

typedef struct {  // D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_TEX2
	FLOAT	vx, vy, vz;
	FLOAT	nx, ny, nz;
	FLOAT	u0, v0;
	FLOAT	u1, v1;
} ST_VERTEXFORMAT0_2;

typedef struct {  // D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_TEX2
	FLOAT	vx, vy, vz;
	DWORD	dwDiffuse;
	FLOAT	u0, v0;
	FLOAT	u1, v1;
} ST_VERTEXFORMAT0_3;

typedef struct {  // D3DFVF_XYZB1 | D3DFVF_NORMAL | D3DFVF_TEX1
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	nx, ny, nz;
	FLOAT	u, v;
} ST_VERTEXFORMAT1_0;

typedef struct {  // D3DFVF_XYZB2  | D3DFVF_NORMAL | D3DFVF_TEX1 
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	fWeight1;
	FLOAT	nx, ny, nz;
	FLOAT	u, v;
} ST_VERTEXFORMAT2_0;

typedef struct {  // D3DFVF_XYZB3 | D3DFVF_NORMAL | D3DFVF_TEX1
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	fWeight1;
	FLOAT	fWeight2;
	FLOAT	nx, ny, nz;
	FLOAT	u, v;
} ST_VERTEXFORMAT3_0;

typedef struct {  // D3DFVF_XYZB1 | D3DFVF_NORMAL | D3DFVF_TEX2
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	nx, ny, nz;
	FLOAT	u0, v0;
	FLOAT	u1, v1;
} ST_VERTEXFORMAT1_2;

typedef struct {  // D3DFVF_XYZB2 | D3DFVF_NORMAL | D3DFVF_TEX2
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	fWeight1;
	FLOAT	nx, ny, nz;
	FLOAT	u0, v0;
	FLOAT	u1, v1;
} ST_VERTEXFORMAT2_2;

typedef struct {  // D3DFVF_XYZB3 | D3DFVF_NORMAL | D3DFVF_TEX2
	FLOAT	vx, vy, vz;
	FLOAT	fWeight0;
	FLOAT	fWeight1;
	FLOAT	fWeight2;
	FLOAT	nx, ny, nz;
	FLOAT	u0, v0;
	FLOAT	u1, v1;
} ST_VERTEXFORMAT3_2;


typedef struct {
	FLOAT	r;
	FLOAT	g;
	FLOAT	b;
	FLOAT	a;
} ST_RGBA_COLOR;

And some of them are the same lenght, so I dunno.

EDIT: OK, I don't think I got it.
This part of the spreadsheet:


I wrote the code for reading it.
here is a pseudocode version:

Code: Select all

Header_string

XPR_size

Part2_offset

loop:
    
    MainId
    SubId
    
    if mainId == 0xFFFF: stop loop
    
    if MainId == 0:
        (resData chunk)
        
        if SubId == 0x8000:
            (memRead)
            
            size
            read size * bytes
        
    if MainId == 1:
        (resEntries chunk)
        
        if SubId == 0x01: unknown

        if SubId == 0x02: unknown

        if SubId == 0x03: unknown
        
        if SubId == 0x04:
            (TexEntry chunk)
            
            tex_offset
            known
            tex_details
            padding
        
        if SubId == 0x80:
            (vertBuff)
            
            vert_offset
            padding
        
        if subId == 0x83:
            (TexBuffer)
            
            tex_offset
            padding

other stuff like MDL

is it right?

Not all XPRs seem to be like this.

[mariokart64n]

sorry I broke the ID into two SHORTs or WORDS, instead of just labeling it as a DWORD


in the image the ID as a DWORD is 00 00 00 08

I described it as
mainID = 0
subID = 8

something stupid like that... hm thats pretty cryptic lol

anyway when you get to ID 00 00 00 08, the next DWORD is a size. thats the size of the user binary.
just log the address of your cursor and the size, then jump past the binary using the size as the offset.
then you continue your loop

and it'll begin with a new ID

here's an example for what you'll likely see
01 00 80 00 00 00 00 00 00 00 00 00
01 00 80 00 00 6B 00 00 00 00 00 00
01 00 80 00 00 C4 01 00 00 00 00 00
01 00 80 00 40 E2 01 00 00 00 00 00
01 00 80 00 80 00 02 00 00 00 00 00
01 00 80 00 C0 4B 02 00 00 00 00 00

where 01 00 80 00 is the ID, and the next two DWORDs are apart of that ID's structure

my document is messed up there, I divided them into WORDS(2bytes) because I was going to expand this to ninja gaiden aswell.. and I wanted to make the read fucntions flexible and expandable.
but to make things easier, read your IDs as DWORDs

heres an example of a texture entry
01 00 04 00 00 07 09 00 00 00 00 00 29 0F 81 08 00 00 00 00
01 00 04 00 00 07 0A 00 00 00 00 00 29 0F 81 08 00 00 00 00
01 00 04 00 00 07 0B 00 00 00 00 00 29 0F 81 07 00 00 00 00
01 00 04 00 00 87 0B 00 00 00 00 00 29 0F 81 07 00 00 00 00
01 00 04 00 00 07 0C 00 00 00 00 00 29 0F 81 08 00 00 00 00

I haven't extracted textures yet, but I read in the dimension sizes

you see that 81 08 ... thats the dimension

you'll need to shift bits of byte 81 so it becomes 08 then make it an exponent of 2.
example: 0x02^0x08 = 256pixels


EDIT
I donno if you've exported geometry before?

but unless you want an unoptimized output, then you have to compare every vertex, vertex normal, texture channel, vertex colour, tangent, weights... its really annoying
I'm going to use this document to write my own stripper
http://www.codercorner.com/Strips.htm

in summary this is all you need to know
1) choose a starting face for a strip
2) choose a direction (i.e. an edge) in which you’ll walk along the strip
3) actually extend the strip in the chosen direction until you reach a triangle with no forwards connections
4) go to 1) until all faces have been visited

I was lucky before, in most games they use a mix of triangle list and triangle strip. so you can usually use triangle list. however DOA is different, I haven't seen a draw type flag.. so I'll be forced to writeup my own stripper this time around.


EDIT2
I'm going to try and write a XPR expander, which will split the components of the XPR into seperate files.
then try to rebuild it, and see if it still works. if so then i'll try increasing the size of some model parts.

if its still good then I plan to write out new geometry, and start exploring new mesh importing

[gjinka]

Yeah that doc could use some work. Hes a troll now.

Tristrips dont look incredibly difficult to generate. But altough each triangle has 3 edges, each one of them can have infinite amount of "neigbouring" edges. Should you just choose the one with the lowest angle?

So it seems the MDL block can also be before the chunks.

BTW, why arent you modding DOA4 instead?

[mariokart64n]

Yeah that doc could use some work. Hes a troll now.

Tristrips dont look incredibly difficult to generate. But altough each triangle has 3 edges, each one of them can have infinite amount of "neigbouring" edges. Should you just choose the one with the lowest angle?

So it seems the MDL block can also be before the chunks.

BTW, why arent you modding DOA4 instead?

I'm a troll now? care to elaborate on that? I'm trying to help here.

I'm working on fully cracking DOAU in honor of ninjahacker.
Besides I've already did texture mods for both DOA4 and DOAX2 back in 2006 when they were released.
I was the first person to crack the xbox360 texture tiling swizzling algo.
viewtopic.php?f=18&t=2205

Later I'll do the same work on DOA4, but right now I'm committing myself to this. is that ok?

[gjinka]

Eh? I meant the doc is trolling me, lame joke, nvm.

It is still confusing though. Why should I skip it? Its a MDL entry.

Or maybe I don't get what you mean by this?

just log the address of your cursor and the size, then jump past the binary using the size as the offset.
then you continue your loop

Why should I remember (log) the position and size? Am I going return here and read the MDL block? Will this work on all files?
I don't see why we shouldn't treat the "MDL block" as an ordinary chunk in the loop then.

[b0ny]

i finally found something i where searching for a long time. i repost an updated part of my "quick guide".

Code: Select all

[i0]20(constant)
[i1]14(constant)(offset to i5)
[i2]hair and clothes phisics offset (- pdg012)
[i3]magic "apv". boobs and lips(hands?) morphing offset (- pdg2)
[i4]joints offset  (all)
[i5..] array of pairs "offset"-"type"(need to add 0x14 to the "offsets"). types:
-1 = skeleton type. 1-doa3, 2-doau2, 77-hks(she's invisible)
1 = high poly bones[][3] (all) 				 {points after marker}
3 = materialColor[][50]  (- pdg, pdg2, hks)
5 = shadow shapes[][1]   (- hks, lor, mam, pdg012, yti)  {points on marker}
6 = ?? magic"apa"	 (- pdg2)
9 = low poly bones[][3]  (- hks,lor,mam,pdg012,yti,hel09,tin11,wba) {after marker} 

that FFFFFFFF thing in the cat header is just the type -1, and it's attribute(is not an offset) shows the game how to handle the model. i changed the usual "2", used in doau, with "1" for the doa3 cat file, and doa3 models now are shown correctly.

here are two, most wanted by me, models from doa3:

RED - the wrists are trying to connect to a random point in space(in doa3 the wrists are handled separately and i still didn't figured out how to translate this to doau)
GREEN - the textures on two-sided surfaces are swapped(wrong cull mode effect?)

now i finished only the highPoly model, still need to translate the shadow the lowPoly and the effects. many doa3 models do have an encrypted cat header. and the morphing block in the cat file for doa3 is incompatible with doau - need to dig here too...

2mariokart64n
in [greedExplorer -> options -> viewport settings] is a "Cull Mode" section, do you have any idea what is it? When i transform doa3 model to doau, it looks like it's "Cull Mode" becomes wrong. in greed explorer you can set it manually or "From File", but i have no idea where to look in file to change it
and can you please build a skeleton for brad wong from one of his doa3 skins

[andthen619]

The contents of this post was deleted because of possible forum rules violation.

[b0ny]

ok. the converted models now have a shadow and a lowpoly, but i can't check if it's compatible with xbox doa2u, can someone try this brad-wong skin and confirm if it works or not: http://rghost.ru/35783949

[mariokart64n]

backface culling, is when you want to enable a face on both sides of the polygon. I haven't looked at DOA3 yet, but greedxplorer got the face direction wrong. so to hide that FAIL it enabled double face polygons.

culling is also noted in the material block its the very last DWORD, in doa2u its always 0x02 I haven't looked into it.

I knew that the -1 in the cat was an ID, but when I changed the value 0x02 it crashed for me. In the highpoly kasumi (hks00.xpr) the value is set to 0x72
if you use that on another CAT it'll crash... I wonder what that flag actually changes?? maybe its a version flag? DOA3 = 1, DOAU = 2, but why does (hks00.xpr) have a version of 0x72?

works in DOA2U, but needs a skeleton file to prevent the stretching
we can easily replace an entire character in DOAU, like tengu or bass. since the animations from DOA3 are compatible with DOAU2, all we have to do is swap the MOT and BIN.




can you explain more what you did to convert a DoA3 model? I thought the XPR's were different. all you said was you swapped the rotation of the models? is that all




EDIT, here is an old post made years ago. I dug it up to see what the mesh diffuse colour was
here is the hex changes I made on the DOAX xbe


looks like offset 0x0027B3FA I nulled some bytes

and got the below effect

[finale00]

Why should I remember (log) the position and size? Am I going return here and read the MDL block? Will this work on all files?
I don't see why we shouldn't treat the "MDL block" as an ordinary chunk in the loop then.

It shouldn't hurt.
I think how one chooses to parse a file is really up to them.

The XPR format may be a generic archive from microsoft, but even then I would expect all of the data to conform to some standards.

You can choose to grab all of the chunks and save their offsets then come back and parse the actual chunks themselves, or just parse it as you go.

Maybe it'll require some more work to render, maybe not. Depends on what you're using.

[gjinka]

So wait, "00000080" means next up is "user defined chunk (user binary)" where people can put what they want and Tecmo put the MDL block in it?

Sorry if I sound stupid. It's a bit confusing still.

[mariokart64n]

yes thats how I interpreted the XPR

I don't have the xbox dev kit to determine if this is true or not.
but from observing the XPRs from NG and DOA, this would seem the case.


I've had a look at the xbox360 devkit and the XPR bundler is used for making texture packages, but you can also embed your own files. there called USER in the XPR header after compiling one.

the XPR must stand for something like XboxPackagedResource?

[gjinka]

OK, gotcha

But the offset which you say comes after seems to be too large.



Also, did you mean I should store the offset so I can return later to parse the MDL? Question,why not parse (read) it then, instead of storing the offset and returning later?
MDL seems to contain info which you really need.

And can I ask again why you don't treat the MDL chunk like the rest of the chunks? (resData, resEntries, etc).