Dead or Alive series formats and tools

[mariokart64n]

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).

yeah when hit 0x00000080 read the next DWORD, that is the size of the binary.
if you want to jump to the end of that binary, offset your cursor from its current position.

Don't offset from the start of the file, because its a size, not a offset. the size is relative to after you read in the binary size.

but even though, you jumped from the start of the file, your cursor was only off like 12bytes?

and you can see now your at the texture tables.. see in the text viewer side theres a repeating pattern.
those are the final entries then the file ends with -1

your correct in that you can treat the MDL as just another chunk. you don't have to follow what i did. I did it this way to conform to NG.
NG does not contain MDL blocks, but does contain the XPR ID 0x00000080

thats why I read them all and log them, because in other games that ID pops up XX amount of times

the XPR is just pointing us to resources, so I read or evaluate the MDL separate from the XPR structure.. but again since your just working within DOA, and the MDL is always at the same location.
it may be easier just to read it as a normal chunk as apart of the header.



EDIT
Can anyone explain the DOA3 Material Block?

I'm going off this information, but I do not understand how to parse the tables at the end of that materials.
in this doc, it explains that there subset headers?

Code: Select all

typedef struct _D3DMATERIAL {
        float Diffuse[4];
        float Ambient[4];
        float Specular[4];
        float Emissive[4];
        float Power;
} D3DMATERIAL;

typedef struct DOA3MATERIALBLOCK {
        dword  dwheader;	
        dword  dwSize;  	//dwSize * 4 == materialblock size
        dword  pad0;  	//usually 00
        dword  pad1;  	//usually 00
        float  x;  
        float  y;  
        float  z;  
        float  radius;  
        dword  renderFg;  	//usually 00,02,04,06
        D3DMATERIAL  material;  //direct3d material
        dword  NumTexInfos;	
} doa3materialblock;

typedef struct DOA3MATTEXINFO {
        dword  tex_num;  //texture index;
        dword  transFg;	//(==01)?[alpha blend (256-bit)]:[]	//check later
        dword  renderFg;	//(RenderFg & 01)?[1-bit alpha test]:[] //check later
        word  typeFg;  //0400h:Texture; 0000h:NonTexture
        word  renderFg2;    	//0100,0000
} doa3MatTexInfo;

typedef struct DOA3SUBSETHEADER {
        dword  NumSubsets;
        dword  vbufno;
} doa3subsetheader;

type struct DOA3MESHSUBSET {
        word  group_num;	//?? 
        word	flag0;  //usually 00
        dword	indexoffset;	//same as doax
        dword	numFace;	//?? to be checked
        word	flag1;  //usually 00
        word	flag2;  //usually 00
} doa3MeshSubset;

MATERIAL BLOCK OVERVIEW:
Material block was separated into two part. the first part (DOA3MATERIALBLOCK) is similar to the source of xpression, except the variable name "mat_color0" and "dwNumSubsets", it had been changed to "x,y,z,radius" and "NumTexInfos" respectively. "x,y,z" are the center of Material block(submesh) but the pivot.
the second part start with 0 to 3 Material Texture Info Records, followed by NumSubsets, vBufNo and lots of mesh subsets.
Number or Material Texture Info Records(NumTexInfos) could be zero or greater than one. it means no or more than one texture associated. And if there are more than 1 material Textrue info record, the last record may not be texture. especially when the tex_num is equal to 0x0888, it maybe procedural texture, environment or auto-reflation...

MESHSUBSET:
i think i have something wrong in mesh subset and wish to correct it later.
there is only one subset in doax. however, there are so many subsets in doa3. it cause slower rendering. another problem is missing face during rendering. however, when add each numFace by 2 it will get better result.

group_num have relative value to numFace. if value of group_num are same, the value of numFace also same in materialblock.
MESHSUBSET DATA:

Code: Select all

                            
--------[group_num][ offset ][numFace ][  pad   ]
00000000 8000 0000 0000 0000 0200 0000 0000 0000 ................
00000010 8000 0000 0400 0000 0200 0000 0000 0000 ................
00000020 A000 0000 0A00 0000 0300 0000 0000 0000 ................
00000030 A000 0000 1100 0000 0300 0000 0000 0000 ................
00000040 C000 0000 1800 0000 0400 0000 0000 0000 ................
00000050 E000 0000 2000 0000 0500 0000 0000 0000 .... ...........
00000060 E000 0000 2900 0000 0500 0000 0000 0000 ....)...........
00000070 0001 0000 3200 0000 0600 0000 0000 0000 ....2...........
00000080 2001 0000 3C00 0000 0700 0000 0000 0000  ...<...........
00000090 6001 0000 4700 0000 0900 0000 0000 0000 `...G...........
000000A0 E001 0000 5400 0000 0D00 0000 0000 0000 ....T...........
000000B0 0002 0000 6500 0000 0E00 0000 0000 0000 ....e...........
000000C0 2002 0000 7700 0000 0F00 0000 0000 0000  ...w...........
000000D0 4002 0000 8A00 0000 1000 0000 0000 0000 @...............
000000E0 6002 0000 9E00 0000 1100 0000 0000 0000 `...............
000000F0 E003 0000 B300 0000 1D00 0000 0000 0000 ................
00000100 8005 0000 D400 0000 2A00 0000 0000 0000 ........*.......
00000110 6006 0000 0201 0000 3100 0000 0000 0000 `.......1.......
00000120 6000 0000 3701 0000 0100 0000 0000 0000 `...7...........
00000130 6000 0000 3C01 0000 0100 0000 0000 0000 `...<...........
00000140 6000 0000 4101 0000 0100 0000 0000 0000 `...A...........
00000150 6000 0000 4601 0000 0100 0000 0000 0000 `...F...........
00000160 6000 0000 4B01 0000 0100 0000 0000 0000 `...K...........
00000170 C001 0000 5001 0000 0C00 0000 0000 0000 ....P...........
00000180 0002 0000 6001 0000 0E00 0000 0000 0000 ....`...........
00000190 0002 0000 7201 0000 0E00 0000 0000 0000 ....r...........
000001A0 8003 0000 8401 0000 1A00 0000 0000 0000 ................
000001B0 8003 0000 A201 0000 1A00 0000 0000 0000 ................
000001C0 C006 0000 C001 0000 3400 0000 0000 0000 ........4.......

[finale00]

OK, gotcha

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

Are you seeking from the current position (after reading the size) or from the start of the file?

[gjinka]

OK, my bad.
The integer in that offset is:

Code: Select all

2C 00 2D 00

Right after it is this:

Code: Select all

01 00 80 00

That's a VertBuff subid, but I don't see a "2C 00 2D 00" mainId in the docs.

Maybe I don't understand mainId/subId too well. There must be a mainId first, right?

[b0ny]

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

viewtopic.php?f=16&t=7229
i just rearranged the information in the OBJ to fit the doa2u format. i didn't rotated anything - when i changed that skeleton type to 1 everything came to normal.

thanks for explaining what the cull mode is. still wondering what is clockwise and counterclockwise, i'm thinking maybe i should rearrange the materials in the OBJ to place the ones from the beginning in the end, and bring those from the end in the beginning...

[mariokart64n]

OK, my bad.
The integer in that offset is:

Code: Select all

2C 00 2D 00

Right after it is this:

Code: Select all

01 00 80 00

That's a VertBuff subid, but I don't see a "2C 00 2D 00" mainId in the docs.

Maybe I don't understand mainId/subId too well. There must be a mainId first, right?

your cursor is off by 4 bytes, you want to be at 01 00 80 00. to make it simple, read the size and +20 to it.

that'll be the offset you want relative to the start of the file, rather then cursor position

[gjinka]

OK, I got it. But I thought it had to be mainid first, before a subid. I thought you had to loop until you have -1 for mainid.
So what am i missing? Why isn't there a mainid in that offset instead? Thanks.

[mariokart64n]

the id is 01 00 04 00 right?

theres 2 IDs there

01 00 = 1
04 00 = 4

main ID is 1, and the sub ID is 4


in the first ID
00 00 00 80

the main ID is 0 and the sub ID is 128

eventually your loop will fall upon the DWORD 0xFFFFFFFF
both your main and sub ID will return -1 signed, or 0xFFFF unsigned.



edit
usually the second id is just a field used to set flags, for whatever it matters the main ID 1 could just mean "Table" and the sub ID could mean "texture"
we'll never really know, but thats how I've broken it down

[gjinka]

Oh sorry, I forgot each was a short, not an int (4 byte)

[gjinka]

OK, this is good If you add few missing infos to your spreadsheet, I can port it to the wiki. I can also add some description to your spreadsheet to make everything clear. it will be few english sentences summarizing how the tables below works. What do you think?

The missing infos are:

1) all the 10 vertex buffer formats (there is only one now).
2) The "ResEntries" with subIds 0x01, 0x02, 0x03. What do they contain? If you don't know, at least how long are they?

Not much left now.

Thanks.

EDIT: BTW, you have posted the ids of the chunks in big endian, while you say the file is little endian. That can cause some confusion in the future.

Also, I'm pretty sure this is right, but just to be extra sure:

http://s17.postimage.org/ly8x0iwfj/phpju_Dvl9.jpg
I think you meant "number of OBJ subBlocks" and "OBJ subBlock offset" right?

[mariokart64n]

the object count is the same as the entry count, may be better just to note that

any unlabelled or undetailed IDs, haven't been encountered yet. so they can be removed.

aswell the spreadsheet exists for others to correct. so make any changes you see fit.

sorry that I get the endian crossed, its easy to forget and write things in left to right order

[gjinka]

any unlabelled or undetailed IDs, haven't been encountered yet. so they can be removed.

OK

How do you know how much materials each OBJ has to loop the subBlock the required amount of time? Or is the material subBlock only one for each OBJ?

Also, there seems to be another subBlock in OBJ block, the "Texture block", acording to one of the docs you posted. Have you figured it out? There doesn't seem to be any texture count variable, so is that "Texture block" one for each OBJ?

[mariokart64n]

I know very little about the material blocks, I was skipping them until recently. but I haven't had any luck deciphering them completely

anyway this pic by keypel explains the block pretty well


I loop until the first dword = 00 00 00 00

normally it is 01 00 00 80 or 00 00 00 80 when a material is present

[gjinka]

OK mariokart. One thing seems odd though. All vertex buffer offsets, vertex counts, index buffer offsets and index buffer counts seem to be 0 in the OBJ subBlock. Are they not used (file "ayaA0.xpr")?

[mariokart64n]

ayaA0 sounds like a DOA3 file name, the material blocks are different from DOAU. I was just asking bony how to parse a doa3 block, he doesnt know?

[finale00]

For AyaA0, it's similar to DOAU except instead of getting numVerts, vertBuff, etc you get 4 integer zeroes followed by vertNum, vertBuff, etc.

Since I wasn't sure whether it was the same game or not I just read an integer, check if it's zero, and then read 3 more zeroes and continue with numVerts, vertBuff ,etc

Though I've noticed that chunkSize = size of data + chunk header, and not really the size of the data that follows. Sometimes.

EDIT: no I'm wrong. That wasn't for AyaA0. It was for one of the stages that I can't find anymore. I actually don't know why I have it in the code now.

But for AyaA0 specifically it's

Code: Select all

char[4] "OBJ "
int32 vertType
int32 ?
float ?
int32 numVerts
int32 vertOfs
int32 numIdx
int32 idxOfs

Anyways here's the model in pieces as mariokart had described some time before.
What do I transform them with?