Dead or Alive series formats and tools

mariokart64n · Post by **mariokart64n** » Wed Jan 18, 2012 9:56 pm

are all the mot files the same? swapping them causes the game to crash. and what do you think the BIN files do?

I looked at the mots before and the offsets are all the same.. point to the same location, which lists more offsets.. I couldnt make out any data

also I'm trying to get the faces from DOA3 import properly, do you have any ideas on how to correct the direction problem?

EDIT
here are the 4 vertex types used in DOAU

Vertex #0
LONG: Position X
LONG: Position Y
LONG: Position Z
Weight #1 == 1.0
LONG: Vertex Normal X
LONG: Vertex Normal Y
LONG: Vertex Normal Z
LONG: Texture Coordinate U
LONG: Texture Coordinate V

Vertex #1
LONG: Position X
LONG: Position Y
LONG: Position Z
LONG: Weight #1
(subtract "1" from Weight #1 to get Weight #2)
LONG: Vertex Normal X
LONG: Vertex Normal Y
LONG: Vertex Normal Z
LONG: Texture Coordinate U
LONG: Texture Coordinate V

Vertex #2
LONG: Position X
LONG: Position Y
LONG: Position Z
LONG: Weight #1
LONG: Weight #2
(add Weight#1 & 2 then subtract 1 to get Weight #3)
LONG: Vertex Normal X
LONG: Vertex Normal Y
LONG: Vertex Normal Z
LONG: Texture Coordinate U
LONG: Texture Coordinate V

Vertex #3
LONG: Position X
LONG: Position Y
LONG: Position Z
LONG: Weight #1
LONG: Weight #2
LONG: Weight #3
(add Weight#1, 2, & 3 then subtract 1 to get Weight #4)
LONG: Vertex Normal X
LONG: Vertex Normal Y
LONG: Vertex Normal Z
LONG: Texture Coordinate U
LONG: Texture Coordinate V

image with the weights converted to vertex colours.
I noted before that the CAT file contained weight data for the mesh joints, like neck, shoulder, elbows, wrists etc...
and as you can see below the vertex weights from the XPR don't cover all the objects... which is totally weird
some are duplicated in the CAT even.

why on earth would they store vertex weights separately from the model

b0ny · Post by **b0ny** » Fri Jan 20, 2012 12:51 pm

gjinka wrote:Also, did my Blender code help in any way?

yeah, thank you very much. i'll try, to implement it in the script, later.

mariokart64n wrote:what do you think the BIN files do?

mot files = moves animation
bin files = triggers for moves

mariokart64n wrote: also I'm trying to get the faces from DOA3 import properly, do you have any ideas on how to correct the direction problem?

doa3 models use CCW culling, you should find out how to process it correctly.

mariokart64n wrote: why on earth would they store vertex weights separately from the model

the xpr contains the joints OBJ(textured, with materials and shit...), and the cat file contains all the joints properties of in what way the mesh will bend.

i found this, for dao3 material:
WORD wUnknown0; //
WORD wSomeIDShit; //
DWORD dwSize; // Material size (in dwords) (materials + mesh-subsets)
WORD wMaterialTransparency; // 0-disable; 1-enable;
WORD wUnknown1; //
DWORD dwBackfaceCulling; // 0-disable; 1-enable;
... ...

and this, for daou material:
WORD wMaterialTransparency; //
WORD wSomeIDShit; //
DWORD dwSize; // Material size (in bytes)
DWORD dwUnknown0; //
DWORD dwBackfaceCulling; // 0-disable; 2-"CCW culling"(like in doa3);
... ...

mariokart64n · Post by **mariokart64n** » Fri Jan 20, 2012 10:34 pm

the culling flags just mean that the object is to be double sided or not right?

CCW and CW refer to a triangle's index windings/direction (CounterClockwiseWinding) vs (ClockwiseWinding)
from what I read, I may be able to run a direction detection in this manner

if the length of the first part of the strip is odd, the strip must be reversed
to reverse the strip, write it in reverse order. If the position of the original face in this new reversed strip is odd, you’re done. Else replicate the first index.

does this sound correct? I will try harder tonight to implement this into my script.

Also I am not able fully assemble the model using just the info from block1 of the CAT file.
Are you using an algorithm on the last cat bloc (deformable objects)? the linking list in this section does not correspond to my skeleton correctly
and I am left with objects not placed, like the wrists etc... I could write something to use the vertex data from the deformable object to calculated the offset from the XPR's object.
But that seems to be more of a hack rather then a solution.

EDIT
I forgot, I wanted to post up my DOAU bone hierarchy. I didn't notice that bony posted his? so here's what you need to rebuild the DOAU skeletons he posted

3 -- 01 Chest
1 -- 02 Head
16 -- 03 Hip
8 -- 04 Left Foot
9 -- 05 Left Forearm
5 -- 06 Left Hand
3 -- 07 Left Thigh
7 -- 08 Left Lowerleg
1, -- 09 Left Upperarm
14 -- 10 Right Foot
15 -- 11 Right Forearm
11 -- 12 Right Hand
3 -- 13 Right Thigh
13 -- 14 Right Lowerleg
1 -- 15 Right Upperarm
-1 -- 16 ROOT
16 -- 17 UNKNOWN (Not Used)
2 -- 18 Left Eye
16 -- 19 UNKNOWN (Not Used)
16 -- 20 UNKNOWN (Not Used)
16 -- 21 UNKNOWN (Not Used)
2 -- 22 Right Eye
16 -- 23 UNKNOWN (Not Used)
16 -- 24 UNKNOWN (Not Used)

b0ny · Post by **b0ny** » Sat Jan 21, 2012 8:23 pm

mariokart64n wrote:the culling flags just mean that the object is to be double sided or not right?

CCW and CW refer to a triangle's index windings/direction (CounterClockwiseWinding) vs (ClockwiseWinding)
from what I read, I may be able to run a direction detection in this manner

not really familiar with the terminology... saw this in the "cull mode" section, in the greed explorer viewport settings. also this "culling" flag in doau can take in doau a lot of different values, the only thing i discovered that:
0-use first texture for both sides.
1-CW . the double sided meshes for doa3 models, are swapping the textures between the sides
2-CCW (culling?). with this flag for doa3 models the double sided meshes are rendered correctly.
...-?

how do you read the indices from a doa3 material. do you make faces from all vertex indicies at once(concatenating them this way to one mesh) or are you making faces for each item of "subset" separately? if you read them at once like for doau, the faces can change their normals in some cases.

mariokart64n wrote:...on the last cat bloc (deformable object )...

imao this block is not for just deformable objects(they are using physics block for this), it's for body joints - meshes attached to bones connections, deformable by the bending of connected bones.

mariokart64n wrote: Also I am not able fully assemble the model using just the info from block1 of the CAT file.
Are you using an algorithm on the last cat bloc (deformable objects)? the linking list in this section does not correspond to my skeleton correctly
and I am left with objects not placed, like the wrists etc... I could write something to use the vertex data from the deformable object to calculated the offset from the XPR's object.
But that seems to be more of a hack rather then a solution.

just go for the joints offsets and read from each joint the obj assigned to it and the bone it's attached to: ( wrote:dword offsetOfJointConectionMesh
dword offsetOfThatStrangePatternShit
byte ourOBJ
byte boneWeAreAttachedTo
byte boneWeAreConnectingTo
byte someSortOfWheight?

you need to read ourOBJ and the boneWeAreAttachedTo, ourOBJ use the coordinates of this bone.

have you imported the joints meshes in 3dmax before? if so can you please import in 3dmax the knees for the hik03.cat and tell me what's wrong with them. they have the someSortOfWheight? value bigger than usual "1", and that's crashing the game. if i set this value to 1 the game doesn't crash but the joints in that case are rendered wrong - the mesh doesn't connect to the parent bone

[edit]
i fixed for the doa3 to doau conversion the object transparency, the wrists and the backface textures. now i need to fix the joints weight for some models and to make a converter for the morphing data.
here you can download for testing for doao the Cristie(gokey) and BradWong(suiken) skins and moves for them i converted a while ago, but the moves are unstable and some moves can crash the game, use them only in training mode and use the Backspace key to restore the scene if the characters will freeze. also here are some fixed models i posted before:

http://rghost.ru/36026316

mariokart64n · Post by **mariokart64n** » Sun Jan 22, 2012 2:53 pm

I'm not sure how the deformation data works, there are zones rather then weights. but they can easily be converted to weights anyway.
but there is additional data, a welding list, which I ignore anyway and a buffer of new vertex positions aslwell there are also 2 nodes positions given

below I tried to mimic the pose from a ingame shot. but notice around the neck, its just not right. this leads me to believe the pivoting points of the bend are not the bones??
I also tried this using the 2 nodes given in the deform data... but the deform is very bad

I'm not sure why they specify 2 new bone positions in the deform. then additional vertex positions
for the vertices :\

anyway its nice to know we have succeeded our ninjahacker predecessors, model is assembled and vertex weighted

all that is left is fortifying the import code and focusing on reexport of the data

EDIT
ha, I finally figured out why my script kept crashing on stage files.
each object block had a reserved space, which I couldn't figure out. I think it was called BufferInfoIV in an older doc.

actually its an array of 8 possible Buffer Sets an object can use. each material can then specify which buffer set to read from
No idea why they reserved the space for using buffer sets? I could understand if they were mixing different draw methods like trifan or trilist.
But thats not the case, and it seems there more or less using it to layer their objects instead
like all characters are using the first buffer set. as for the stages the first buffer set entry is blank, all zeros. and commonly you see the stages build off the second buffer set, so layer 2

to refresh your memory a buffer set entry contains 4 dwords
DWORD NumVertices
DWORD VertexBufferOffset
DWORD NumFaces
DWORD FaceBufferOffset

... asides from that radius thing in the materials I feel doau's XPR format is completely cracked!

mbugle · Post by **mbugle** » Wed Jan 25, 2012 1:22 am

Im sorry if this is off current topic/in wrong place/been answered before but im wondering if its possible to move a model from NG to doa3/doax, i can extract models from an afs but have no idea how to inject them back in, any help would be apreciated,

thanks in advance
Mbugle

mariokart64n · Post by **mariokart64n** » Wed Jan 25, 2012 2:22 am

no tools written for that yet.

b0ny · Post by **b0ny** » Thu Jan 26, 2012 2:18 pm

i took a look at the ninja gaiden xpr(stored inside the cmd files). it has a model chunk id(0x00000080), but it has no mdl nor obj magic words, though i can see the "obj materials" hex pattern. the indices are stored outside the model chunk, and every "obj" is signed with a magic word(body, face ...). greed explorer can see the textures inside the ng xpr.

ng mot files also are different from the doau mot files. it has the same size and structure but something is different. maybe it has more than 4 "key-frame types", or maybe the "kinematic structure sequence" is different.

[edit]
doau/doa3 xpr has two data blocks: 1 - mdl block, 2 - vertex+texture block; ng xpr has a(third) separate block for indicies.
i tried to disassemble the "chr_army.xpr", this is what i've got for the ng xpr header + first obj(each value is a DWORD; uncommented values are unknown):

Code: Select all

DWORD	dwMagic;	// XPR0
DWORD	dwXPRSize;	// XPR size
DWORD	dwHeaderSize;	// indicies block offset
0x80000000 mdl chunk
1c ?
3f ?
1f images
3d (indices or buffers)
3d (indices or buffers)
0
b000 // vertex block offset
92000// vertex block size(with paddings)

+++++++++++++++++object start
80000000  objID
118       objSize (without id and size)
1         vertex buffers
1         elements of obj

----vertex buffer start
112
0
0
237
20     ?one vertex size?
1
0
47b    num of indicies
----vb end
=================element of object start
0
0
1   has magic 0x40 bytes
0

2
0
8f6 indicies size
1

1   has material
1
0
1

900
0
0302
0303

1
0
0
0

0
0
0
0

material[0x50 bytes]

----magic 0x40 bytes start
magictype
0
1
0

4
1
2
1

3
1
2
1

80000000
0
0
0
----magic end
=================e of obj end 
+++++++++++++++++object end

#define CHUNK_MODEL	0x80000000
#define CHUNK_TEXTURE	0x00040001 in vertex+texture block
#define CHUNK_VBUFFER	0x00800001 in vertex+texture block
#define CHUNK_INDICIES	0x00010001 in indicies block

i'll try later to make a converter for the model but not for the skin because the skin requires also a cat file which is very complicated to be gathered from the additional ng skin data

mariokart64n · Post by **mariokart64n** » Sat Jan 28, 2012 12:12 am

old doc from ninja hacker
https://docs.google.com/spreadsheet/ccc ... 0RVYS1BbUE

b0ny · Post by **b0ny** » Sat Jan 28, 2012 11:47 am

mariokart64n wrote:old doc from ninja hacker
https://docs.google.com/spreadsheet/ccc ... 0RVYS1BbUE

tnx

mariokart64n
in doao the "kasumi clon" - "hks" model is invisible if i try to use it as a skin for a playable character.
is it also invisible for doau?

i found something interesting about this hks skin!
look carefully at her heels in the demo(here at 2.37-2.38).
hks is kasumis doax model and it's not very carefully converted - they use a foot with toes but don't use the toes.
i found this when i looked in her skeleton(embedded in cat) - she use kasumis skeleton from doax(foot with toes) but with an additional bone.
also she have an 77 for her skeleton type, it's interesting how the game is making this skin visible in the demo. maybe it's possible to convert doax models to doau(and somehow make them visible)

[edit]
i compared the cat files for both models(doau hks00.cat and doax vks00.cat). they only corrected a few values in the physics block and in the morphing header(the boobs jiggling in doau for the doax models is upsidedown), and of course they converted the first block.

mariokart64n · Post by **mariokart64n** » Sat Jan 28, 2012 12:48 pm

yeh i noticed it was the doax model, but the cat always caused a crash trying to tweak the cat.. I'll try again since I understand more with the blocks

b0ny · Post by **b0ny** » Sat Jan 28, 2012 2:05 pm

when i tried to convert a doax model to doau i noticed that there are to few joints, now with hks i found that doau can handle doax joints which are assigned as bones with id "2", but when in doau is only one root bone(pelvis), in doax the bones hierarchy is different.
in doau with "doau skeleton mode"(2) the doax model has some bones not attached to the model and flying somewhere around and the joints are connected to these bones(the same thing as with the doa3 wrists)(you can move these bones by pushing the enemy character with a doax skeleton against a wall toward the "leak").
i think the "doax skeleton mode"(77) should be used to process the doax skeleton correctly but i'm afraid there is no way to make the model visible without editing the executable.

mariokart64n · Post by **mariokart64n** » Sun Jan 29, 2012 9:51 am

yeah I cant get anything to work. I had to remove the physics bloc for the model to load (not crash) then I had to change mode 77 to 02. finally the skeleton that is specified doesnt work, so I removed bloc1's subBloc8 (custom skeleton)

this leaves the model to use a default skeleton from the game (DOAU skeleton)

but the problem is pretty apparent, DOAX has more spine, neck and shoulder bones. DOAU does not. therefore the mesh objects around the torso and shoulder are all bad
http://i43.tinypic.com/2i6cfpy.jpg

the weird part is the mesh vertices pulling away from the character. such would indeicate that vertices are trying to be weighted to something that does not exsist. I'm curious as to how the game determines which bones to weight to. because I have not found that information.

anyway 2 interesting things
a. Different Physics Bloc?
b. weird weights

... and I admit I still haven't completed a model importer yet

this week I have been studying the DOAX2 save format. I don't have anything documented yet because I only know small parts of the file.
but anyway encase your interested, here are some hex changes that will fully unluck VP mode.

DOAX2 - Unlock VP Mode (All Girls)
Tina goto offset: 0x7acc change: byte to 0x1F
Kasumi goto offset: [0x7c04] change: byte to 0x1F
Helena goto offset: [0x7d3c] change: byte to 0x1F
Leifang goto offset: [0x7e74] change: byte to 0x1F
Ayane goto offset: [0x7fac] change: byte to 0x1F
Hitomi goto offset: [0x80e4] change: byte to 0x1F
Lisa goto offset: [0x821c] change: byte to 0x1F
Christie goto offset: [0x8354] change: byte to 0x1F
Kokoro goto offset: [0x848c] change: byte to 0x1F

write 0xFF from 0x99EC - 0x9AEF to unlock all scenes in VP mode

b0ny · Post by **b0ny** » Sun Jan 29, 2012 3:35 pm

mariokart64n wrote:yeah I cant get anything to work. I had to remove the physics bloc for the model to load (not crash) then I had to change mode 77 to 02. finally the skeleton that is specified doesnt work, so I removed bloc1's subBloc8 (custom skeleton)

this leaves the model to use a default skeleton from the game (DOAU skeleton)

but the problem is pretty apparent, DOAX has more spine, neck and shoulder bones. DOAU does not. therefore the mesh objects around the torso and shoulder are all bad
http://i43.tinypic.com/2i6cfpy.jpg

i found that the value 77 just skips the model from rendering

thought i know that the game can handle perfectly(almost) the hks model, as we can see from the doau demo where it appears. did you removed the physics block from hks or from other doax model? you can hex compare the physics block from hks and from vks to find what should be fixed for the physics block in doax models to work in doau, also some fixes should be done for the header of the morphing block.

in this image i just changed the 77 to 2 for the skeleton type, and because the bones hierarchy is different i swapped in the embedded skeleton bones for the head, chest and shoulders with bones from the doau kasumis skeleton.

gjinka2 · Post by **gjinka2** » Mon Jan 30, 2012 8:21 pm

So I made this guide... http://wiki.xentax.com/index.php/Blender_Import_Guide

So b0ny, maybe you shoud switch to Blender 2.6 now.

XeNTaX

XeNTaX

Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools

Re: Dead or Alive series formats and tools