Dead or Alive series formats and tools

[mariokart64n]

so what do you feel the numbers represent?


..anyways I compiled more bone positions, and I'm going to try and mimic the ground hog file.
since the ground hog is the only character model that doesn't deform in game. according to b0ny it has its own skeleton in the cat.

my goal is to put the skeleton back into say kasumi, and see if she deforms... more and more I'm starting to believe that maybe the skeletons really are hardcoded into the EXE :\

Fabricated Bone Positions (output from 3dsmax)

Code: Select all

KASUMI
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.180000,0.004900]
$Bone:Neck @ [0.000000,0.467499,-0.025100]
$Bone:UpperArm (Left) @ [0.120600,0.401001,-0.018640]
$Bone:ForeArm (Left) @ [0.360302,0.401001,-0.018640]
$Bone:Hand (Left) @ [0.599998,0.400990,-0.018604]
$Bone:UpperArm (Right) @ [-0.120600,0.401001,-0.018640]
$Bone:ForeArm (Right) @ [-0.360298,0.401001,-0.018640]
$Bone:Hand (Right) @ [-0.599998,0.400990,-0.018604]
$Bone:Thigh (Left) @ [0.076100,-0.020500,-0.025700]
$Bone:LowerLeg (Left) @ [0.076100,-0.423801,-0.025700]
$Bone:Foot (Left) @ [0.076100,-0.843697,-0.025700]
$Bone:Thigh (Right) @ [-0.076100,-0.020500,-0.025700]
$Bone:LowerLeg (Right) @ [-0.076100,-0.423801,-0.025700]
$Bone:Foot (Right) @ [-0.076100,-0.843697,-0.025700]


AYANE
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.180000,0.004900]
$Bone:Neck @ [0.000000,0.467499,-0.025100]
$Bone:UpperArm (Left) @ [0.120600,0.400999,-0.018640]
$Bone:ForeArm (Left) @ [0.360300,0.400999,-0.018640]
$Bone:Hand (Left) @ [0.600000,0.400989,-0.018604]
$Bone:UpperArm (Right) @ [-0.120600,0.400999,-0.018640]
$Bone:ForeArm (Right) @ [-0.360300,0.400999,-0.018640]
$Bone:Hand (Right) @ [-0.600000,0.400989,-0.018604]
$Bone:Thigh (Right) @ [-0.076100,-0.020500,-0.025700]
$Bone:LowerLeg (Right) @ [-0.076100,-0.423800,-0.025700]
$Bone:Foot (Right) @ [-0.076100,-0.843700,-0.025700]
$Bone:Thigh (Left) @ [0.076100,-0.020500,-0.025700]
$Bone:LowerLeg (Left) @ [0.076100,-0.423800,-0.025700]
$Bone:Foot (Left) @ [0.076100,-0.843700,-0.025700]

HITOMI
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.184998,0.005200]
$Bone:Neck @ [0.000000,0.486464,-0.021042]
$Bone:UpperArm (Left) @ [0.124200,0.405900,-0.019200]
$Bone:ForeArm (Left) @ [0.371182,0.405900,-0.019162]
$Bone:Hand (Left) @ [0.618182,0.405874,-0.019162]
$Bone:UpperArm (Right) @ [-0.124200,0.405900,-0.019200]
$Bone:ForeArm (Right) @ [-0.371183,0.405900,-0.019163]
$Bone:Hand (Right) @ [-0.618181,0.405874,-0.019163]
$Bone:Thigh (Right) @ [-0.078400,-0.028300,-0.026400]
$Bone:LowerLeg (Right) @ [-0.078402,-0.428300,-0.026400]
$Bone:Foot (Right) @ [-0.078400,-0.844700,-0.026400]
$Bone:Thigh (Left) @ [0.078400,-0.028300,-0.026400]
$Bone:LowerLeg (Left) @ [0.078398,-0.428300,-0.026400]
$Bone:Foot (Left) @ [0.078400,-0.844700,-0.026400]

TINA
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.200001,-0.010500]
$Bone:Neck @ [0.000000,0.476915,-0.041050]
$Bone:UpperArm (Right) @ [-0.130000,0.425441,-0.039300]
$Bone:ForeArm (Right) @ [-0.384000,0.425441,-0.039300]
$Bone:Hand (Right) @ [-0.626900,0.425439,-0.039300]
$Bone:UpperArm (Left) @ [0.130000,0.425441,-0.039300]
$Bone:ForeArm (Left) @ [0.384000,0.425441,-0.039300]
$Bone:Hand (Left) @ [0.626900,0.425439,-0.039300]
$Bone:Thigh (Left) @ [0.073200,-0.015500,-0.024700]
$Bone:LowerLeg (Left) @ [0.073201,-0.401500,-0.024700]
$Bone:Foot (Left) @ [0.073200,-0.844500,-0.024700]
$Bone:Thigh (Right) @ [-0.073200,-0.015500,-0.024700]
$Bone:LowerLeg (Right) @ [-0.073199,-0.401500,-0.024700]
$Bone:Foot (Right) @ [-0.073200,-0.844500,-0.024700]

HELENA
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.200001,-0.010500]
$Bone:Neck @ [0.000000,0.476900,-0.041000]
$Bone:UpperArm (Right) @ [-0.130000,0.425400,-0.039300]
$Bone:ForeArm (Right) @ [-0.378400,0.425400,-0.039300]
$Bone:Hand (Right) @ [-0.626800,0.425400,-0.039300]
$Bone:UpperArm (Left) @ [0.130000,0.425400,-0.039300]
$Bone:ForeArm (Left) @ [0.378400,0.425400,-0.039300]
$Bone:Hand (Left) @ [0.626800,0.425400,-0.039300]
$Bone:Thigh (Right) @ [-0.073200,-0.015500,-0.024700]
$Bone:LowerLeg (Right) @ [-0.073200,-0.401500,-0.024700]
$Bone:Foot (Right) @ [-0.073200,-0.844500,-0.024700]
$Bone:Thigh (Left) @ [0.073200,-0.015500,-0.024700]
$Bone:LowerLeg (Left) @ [0.073201,-0.401500,-0.024700]
$Bone:Foot (Left) @ [0.073200,-0.844500,-0.024700]

LEIFANG
$Bone:Pelvis (Root) @ [0.000000,0.000000,0.000000]
$Bone:Torso @ [0.000000,0.195900,-0.010000]
$Bone:Neck @ [0.000000,0.478400,-0.020000]
$Bone:UpperArm (Left) @ [0.117200,0.420900,-0.034900]
$Bone:ForeArm (Left) @ [0.332800,0.420900,-0.034900]
$Bone:Hand (Left) @ [0.548399,0.420898,-0.034900]
$Bone:UpperArm (Right) @ [-0.117200,0.420900,-0.034900]
$Bone:ForeArm (Right) @ [-0.332800,0.420900,-0.034900]
$Bone:Hand (Right) @ [-0.548399,0.420898,-0.034900]
$Bone:Thigh (Left) @ [0.071200,-0.009800,-0.024000]
$Bone:LowerLeg (Left) @ [0.071200,-0.424800,-0.024000]
$Bone:Foot (Left) @ [0.071200,-0.839800,-0.024000]
$Bone:Thigh (Right) @ [-0.071200,-0.009800,-0.024000]
$Bone:LowerLeg (Right) @ [-0.071200,-0.424797,-0.024000]
$Bone:Foot (Right) @ [-0.071200,-0.839800,-0.024000]

[ganjul]

I might have missed somethings, but in your image if you really used the 3 float values from xpr to position the meshes, then:
The head is at almost (0,0,0). Usually the feet are at (0,0,0) and more rarely the middle of the body. So it's possible that the positions are not absolute, but relative. That is relative to the parent bone or mesh. The parenting info might be in the exe (the compiled game code).
For the note, the topmost (parent of all) bone is usually in the middle of the body. So it's positions are absolute (not relative to any other bone).

I'm really not sure what you are doing right now, so you might not need to know all this.

[mariokart64n]

no the positions in the image are multiplied by the 4th float. I took [X,Y,Z]*W to get the X,Y,Z of each position.
of course anything multiplied by zero equals zero, thus why the head is in the center. because the 4th float must not be a multiplier as I preivously thought

here is an image without using the 4th float as a multiplier. however I used a multiplier of 10 to better show the object spacing



interestingly the only objects in the center are the objects which I noted before. when I overwrote the offsets in the CAT header, all the vertex weighted objects disappeared, with the exception of the thighs. which is what can be notably seen in the positions here.. there must be some form of hierarchy, which works relative to that.

again here are the exact positions supplied by the XPR file. in the form of x,y,z,w
[0.000000,0.045885,-0.009516,0.157314] Pelvis (Root)
[0.000000,0.024232,0.018681,0.126946] Torso
[0.000000,0.016209,0.009813,0.0647278] Neck
[0.126262,0.006701,-0.000748,0.110517] UpperArm (Left
[0.118408,0.001096,-0.000909,0.115959] ForeArm (Left)
[0.084971,-0.003975,0.005570,0.0872708] Hand (Left)
[-0.126262,0.006701,-0.000748,0.110517] UpperArm (Right)
[-0.118408,0.001096,-0.000909,0.115959] ForeArm (Right)
[-0.084971,-0.003975,0.005570,0.0872708] Hand (Right)
[0.004714,-0.122153,0.023785,0.239093] Thigh (Left)
[0.007086,-0.235268,-0.027545,0.185274] LowerLeg (Left)
[0.003823,-0.045763,0.058856,0.134510] Foot (Left)
[-0.004716,-0.122153,0.023785,0.239093] Thigh (Right)
[-0.007086,-0.235268,-0.027160,0.185419] LowerLeg (Right)
[-0.003823,-0.045763,0.058856,0.134510] Foot (Right)


I think with this aside I'll continue research on the CAT format. once I figure that cat file out, I can attempt to write new geometry to the game

[ganjul]

no the positions in the image are multiplied by the 4th float.

huh?

I believe it is a vector of some sort, that is used to manipulate the 1st three floats

you can see here the result of that;

I think you'll agree that you didn't explain very well what you were doing here. You should try to explain exactly what you are trying to do, if you want to share your ideas and get feedback.

On a side note, the lowpoly meshes from the left of your new image are probably used for fake reflections. At least I can say they are not used for collisions. "Hit boxes" don't look anything like that. It could also be used for "level of detail", but fighting games rarely use those. http://jsomers.com/vipm_demo/4cows.gif

[mariokart64n]

I had an unknown amount of variables in a 128bit binary space. I had to explore every possible idea...

I've seen a few games where they stored 16bit floats instead of 32bit floats.
but used a 32bit float divisor or multiplier on their 16bitfloats to regain accuracy.

I just thought a simular thing may have happened, since I wasn't 100% sure that what I was looking at was
indeed 32bit encoded floats.

heres it is a bit more clearly laid out
say I got like these four variables, with whatever values. I essentially want to supply a X,Y,Z to my object as a new position
but I have 4 variables, so I tried to remove the 4th variable by the following method

Equation: (pos = [x,y,z])
X = X*W
Y = Y*W
Z = Z*W


also maybe I'm being stupid, but your replies always sound belittling. like pointing out what a lowpoly model does.. and how the "compiled game code" is the EXE, and over and over about how terrible I am at explaining programming matters <_< !! grr

cut me some slack I don't have a degree in programming or anything. But I know 3D models, Hex, and stuff .. like a bit of scripting.

anyways, tonight I looked more at the CAT file. so here are specs so far, the ideas are based off b0ny's notes. through various testing I'm pretty sure his notes are accurate..
BYTE = 1 Byte Unsigned Integer
SHORT = 2 Byte Unsigned Integer
LONG = 4 Byte Unsigned Integer

If I recall a WORD is a 2byte unsigned int, and Dword is signed.. in any case I always use unsigned ints. but unless noted assume everything is unsigned

CAT FORMAT
============================
-Header-
[LONG] FileID 0x20
[LONG] Offset to Bloc1 (Node Hierarchies)
[LONG] Offset to Bloc2 (Physics)
[LONG] Offset to Bloc3 (Morph Targets)
[LONG] Offset to Bloc4 (?? Joints)
=============================
=============================
-Bloc1-
[LONG] ChunkID
[LONG] Offset to Chunk
..Loop until the ChunkID==0xFF
what each chunk ID does is documented by b0ny
If the offset is 0xFFFFFFFF or -1 ignore chunk entry
I'll update the spec for each chunk once I've figured out how to read them. there are 12?
============================
-Bloc1: ChunkID 0x01-
[BYTE] Flag, 0x00 = Don't Render | 0x01 = Render
[BYTE] Node Index to attach Object to
[BYTE] Object Index to Use
you'll need this to apply the Mesh Objects to the correct position on the skeleton[/i][/color]
=============================
=============================
-Bloc2-
[LONG] ChunkID
[LONG] Offset to Chunk
..Loop until the ChunkID==0xFF
I Don't think any of these IDs were documented.. but they involve the Physics somehow
=============================
=============================
-Bloc3-
Morph Targets, Not Documented
=============================
=============================
-Bloc4-
[LONG] Offset to Vertex Buffer
Loop until offset is 0
=============================
-Bloc4: Vertex Buffer Header-
[LONG] Offset to an Undocumented Bloc lol
[LONG] Offset to Vertex Buffer
[LONG] Unknown ??
The First offset jumps to a small section after the buffer, not yet investigated
=============================
-Bloc4: Vertex Buffer-
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
after the transform, vertices are defined. however there is no count or terminator byte.
=============================
-Bloc4: Vertex Buffer Vertex Definition-
[FLOAT32] Position X
[FLOAT32] Position Y
[FLOAT32] Position Z
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
[FLOAT32] Unknown ??
I just calculated the loop count of the buffer based on the offset given in the vbuf header.
I just divided the size of the buffer by the size of a vertex definition or stride to get count
=============================




EDIT1
According to b0ny's notes chunkID 0x08 is a custom skeleton.

however I copied the skeleton from the cinema kasumi (hks00) and pasted it into (kas00) and got this


I was confused, thought maybe the skeletons were different so poked the values in the RAM.
seems some bones just don't read the positions

heres what I got, anything thats labeled not used?
means that when I entered a value, there was no effect. as if the game does not read these positions...

below are the documented data fields and there cause&effect
[X,Y,Z,NULL]

Float32[4] = Torso
Float32[4] = Neck
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Left Thigh
Float32[4] = Left Lowerleg
Float32[4] = Left Upperarm
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Right Thigh
Float32[4] = Right Lowerleg
Float32[4] = Right Upperarm
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Left Eye
Float32[4] = Not Used?
Float32[4] = Not Used?
Float32[4] = Right Eye
Float32[4] = Not Used?
Float32[4] = Not Used?

[ganjul]

I'm sorry if I sounded like a think highly of myself. I never wanted you to feel belittled, I just meant you know alot, but don't share your knowledge very well and if you did more people could help.
I share my knowledge in game programming because I think it might help you to understand what some things in the file could be for. And till now all my guesses haven't been right, so I'm not too great at this. Not everyone knows the general uses of lowpoly models or how collision solids are stored in files, so i thought I would be helpful in explaining why certain things are in the file.

and over and over about how terrible I am at explaining programming matters

You're not. It was a joke, like I said and I said it once. What I'm saying now is your descriptions are a bit confusing, missing some important points which you add later. This makes me test stuff which is not needed anymore. So I'm just asking you to try word it a bit "better", so me and others could help more. You can either accept it as constructive criticism, or ignore my suggestions or requests.

I don't have a degree in programming or anything.

me too

EDIT: OK, I reread the DOAX doc you uploaded and I think I understand it now.
I wrote this Python parser. But it still doesn't look right right and I stil don't get what to do with the vertexbuffer and all the vertex/face indexes and offsets.

Code: Select all

# -*- coding: utf-8 -*-
import struct
class globals:
	pass

# little endian

filename = 'vhe01.xpr'
file = open(filename, 'rb')

# 1. header
header = file.read(4)
print 'header:',header
# 2. file size,    does not always match the actual xpr file size
filesize = struct.unpack('<i', file.read(4))[0]
print 'filesize:',filesize
# 3. header size,    multiple of 4, includes padding
headersize = struct.unpack('<i', file.read(4))[0]
print 'headersize:',headersize

models = []
textures = []
vertexbuffers = []

def readModel():
	
	def readOBJ():
		print '\nOBJ chunk:'
		# dword magic;
		objmagic = struct.unpack('<i', file.read(4))[0]
		# dword vertex_type;
		vertextype = struct.unpack('<i', file.read(4))[0]
		# dword num0;
		num0 = struct.unpack('<i', file.read(4))[0]
		# dword numfaces;
		numoffaces = struct.unpack('<i', file.read(4))[0]
		# float x,y,z,w; // 16 bytes
		x,y,z,w = struct.unpack('<4f', file.read(16))
		# vertexinfo vi[4]; //32 * 4 = 128 bytes
		vertexinfo = []
		for i in xrange(4):
			# dword numverts;
			numofverts = struct.unpack('<i', file.read(4))[0]
			# dword vertex_offset;
			vertexoffset = struct.unpack('<i', file.read(4))[0]
			# dword numfaces;
			numoffaces = struct.unpack('<i', file.read(4))[0]
			# dword index_offset;
			indexoffset = struct.unpack('<i', file.read(4))[0]
			# dword num0;
			num0 = struct.unpack('<i', file.read(4))[0]
			# dword num1;
			num1 = struct.unpack('<i', file.read(4))[0]
			# dword num2;
			num2 = struct.unpack('<i', file.read(4))[0]
			# dword num3;
			num3 = struct.unpack('<i', file.read(4))[0]
			
			vertexinfo.append([numofverts, vertexoffset, numoffaces, indexoffset, [num0,num1,num2,num3]])
		
		print 'objmagic:',objmagic,'\n','vertextype:',vertextype,'\n','num0:',num0,'\n','numoffaces:',numoffaces,'\n','indexoffset:',indexoffset,'\n','num0,num1,num2,num3:',num0,num1,num2,num3
		return [objmagic, vertextype, num0, numoffaces, [x,y,z,w], vertexinfo]
	
	def readMaterial():
		print '\nMaterial chunk:'
		materialtypes = {0x80000000 : 'standard',
			0x80000001 : '256bit'}
		
		# dword header;
		type = struct.unpack('<i', file.read(4))[0]
		# dword size;
		size = struct.unpack('<i', file.read(4))[0]
		# dword pad02;
		file.read(4)
		# dword number;
		number = struct.unpack('<i', file.read(4))[0]
		# float mat_color0[4]; // diffuse color ?
		d1,d2,d3,d4 = struct.unpack('<4f', file.read(4*4))
		# float mat_color1[4];
		file.read(16)
		# float mat_color2[4];
		file.read(16)
		# float mat_color3[4];
		file.read(16)
		# float mat_color5[4];
		file.read(16)
		
		# float power; // specular power ??
		power = struct.unpack('<f', file.read(4))[0]
		# dword pad25; // 1
		file.read(4)
		# dword pad26; // 1
		file.read(4)
		# dword ffff; // 0xfffffffff
		file.read(4)
		# dword tex_no; // texture used by this material
		textureindex = struct.unpack('<i', file.read(4))[0]
		# dword pad29;
		file.read(4)
		# dword transparency; // this is the dxt1 transparency flag
		alphaflag = struct.unpack('<i', file.read(4))[0]
		# dword pad31;
		file.read(4)
		# dword pad32;
		file.read(4)
		# dword indexoffset; // index buffer - offset
		indexoffset = struct.unpack('<i', file.read(4))[0]
		# dword indexsize; // index buffer - num
		indexsize = struct.unpack('<i', file.read(4))[0]
		# dword pad35;
		file.read(4)
		
		print 'type:',type,'\n','size:',size,'\n','number:',number,'\n','diffuse?:',[d1,d2,d3,d4],'\n','power:',power,'\n','textureindex:',textureindex,'\n','alphaflag:',alphaflag,'\n','indexoffset:',indexoffset,'\n','indexsize:',indexsize
		return [type, size, number, [d1,d2,d3,d4], power, textureindex, alphaflag, indexoffset, indexsize]
	
	print '\nModel chunk:'
	# size of chunk
	chunksize = struct.unpack('<i', file.read(4))[0]
	# model magic
	modelmagic = struct.unpack('<i', file.read(4))[0]
	# number of objects in the model
	numofobjects = struct.unpack('<i', file.read(4))[0]
	# number of textures in the model
	numoftextures = struct.unpack('<i', file.read(4))[0]
	# padding nulls
	file.read(4)
	# unknown, $ of vertex buffers ?
	file.read(4)
	# for each object: object offset from beginning of file
	objoffsets = []
	for i in xrange(numofobjects):
		objoffset = struct.unpack('<i', file.read(4))[0]
		objoffsets.append(objoffset)
	
	models.append([chunksize, modelmagic, numofobjects, numoftextures, objoffsets])
	print 'chunksize:',chunksize,'\n','modelmagic:',modelmagic,'\n','numofobjects:',numofobjects,'\n','numoftextures:',numoftextures,'\n','objoffsets:',objoffsets
	
	# go to object offsets and read them
	objs = []
	for i in objoffsets:
		currentpos = file.tell()
		file.seek(i)
		
		obj = readOBJ()
		objs.append(obj)
		
		readMaterial()
		
		file.seek(currentpos)
		
	return models

def readTexture():
	pass

def readVertexbuffer():
	pass

# After the xpr header, there can be the 3 types of “files”
# First there is a magic number
# 0x80000000 for a model
# 0x00040001 for a texture
# 0x00800001 for a vertex buffer

files = {0x80000000: readModel,
	0x00040001: readTexture,
	0x00800001: readVertexbuffer}

while True:
	chunktype = struct.unpack('<I', file.read(4))[0]
	chunk = files[chunktype]()
	file.seek(chunk[0][0])

Until there is a better doc, I give up now.

[mariokart64n]

each object gives you the vertex buffer offset and the index buffer offset, along with counts.
then at the end of every material section there are 3 counts.. you need the 1st and 2nd to start and end an element
the 1st count is the index to start at(from your index buffer), and the 2nd is the amount of indices to read <_< ?? I think

without this, your imported meshes may have some badly drawn polygons

but if this is confusing at first, break it down to an easier operation;
instead of reading all the material stuff, just try importing the whole obj without separating the elements

just jump to the vertex offset, and read those in(the more the better) then read your entire facebuffer and attempt to draw it into your scene

remember that some objects that have vertex weights have a larger vertex definition or stride size.


Also here's an update on what I did today;

Compared the CAT of a basic model vs a player model.. and found that fundamentally a CAT file really only needs two sections
here's the CAT header once again
[LONG] HeaderID 0x20
[LONG] Offset1, Object Positioning
[LONG] Offset2, Morphs
[LONG] Offset3, Physics
[LONG] Offset4, Joints

the two important parts are;
A.) Offset1, which tells the game which objects from the XPR to assign to the skeleton.
B.) Offset4, which controls the positioning and function of the joining mesh pieces
as for now, we'll assume the skeleton is indeed hardcoded or otherwise not obtainable without disassembly of the EXE
hopefully someone with a knowledge of disassembly can lend us a hand, but until then I'm trying to construct my own fictional skeleton

so offset 1 and 4 play a major role in assigning all the mesh parts to the skeleton.. thus why its so important. everything else doesn't matter and is otherwise optional to the game engine.

I attempted to use the information supplied in offset1 and 4 today.. offset1 is really simple, heres the format;
jump to "Offset1"
read the offset table, until the ChunkID==1
[LONG] Offset
[LONG] ChunkID

we're only concerned with chunkID 0x01. the rest also relate to positioning, but are not essential to the model.

jump to the offset from chunkID 0x01 and loop until the flag=0
[BYTE] Flag, 0x00 disable, 0x01 = render
[BYTE] Bone Index, bone that object will attach to
[BYTE] Object Index, which object to use

assuming you have a skeleton (I've created my own fake skeleton)
all the static objects will position correctly to your skeleton...

however you'll notice alot of mesh objects are missing. which are all the vertex weighed objects. which I'll now refer to as the joint objects (an example of joint objects can be seen here in red)

now heres the tricky part! O_o

to position these correctly you have to read the data from Offset4. But its like nothing I've ever seen before..
unlike Offset1, where you get a list of indices to your skeleton. Offset4 is a vertex buffer followed by a table of strange counts

I'm not sure yet how to evaulate the table after the vertex buffer, since the counts exceed the vertex buffer entirely.. I'm curious, perhasp those counts are indexing the object?
then theres the mater of the vertex definitons.. it appears they supply 8 float32's it looks like the resupplied the vertex normals again ??
And it doesnt stop there the vertex buffer seems to contain sub buffers.. as the imported vertex cloud contains other shapes besides the one for that particular object.



in this image there are a few things happening
1.) the orange wires are the objects assigned to the skeleton after I read in offset1 and offset4
2.) the yellow wire is an object that is not placed correctly(the red arrow shows that it needs to move over), as well you can see a few other not aligned properly.
3.) the blue dots(circled in red) are from the vertex buffer for that yellow wire object
Notice that some of the blue dots(circled in pink) are off in the middle of nowhere. and also notice that 2 dots are always at the center opening of the objects I want to align

I'm messing around with that table after the vertex buffer, but with no luck and I can think of no way to complete the positioning of the joint objects


EDIT1
...starting to find some patterns from the offset4 sub tables

looks like an ID is given, then a series of offsets are given until -1 is met. The ID is closed when the next offset returns -1

01 00 00 00
A0 12 00 00 A0 02 00 00 FF FF FF FF
60 0D 00 00 80 02 00 00 FF FF FF FF
FF FF FF FF

02 00 00 00
20 0F 00 00 20 04 00 00 FF FF FF FF
20 10 00 00 A0 01 00 00 FF FF FF FF
A0 0F 00 00 00 01 00 00 FF FF FF FF
00 0F 00 00 60 01 00 00 FF FF FF FF
FF FF FF FF

10 00 00 00
00 06 00 00 FF FF FF FF
C0 05 00 00 FF FF FF FF
80 04 00 00 FF FF FF FF
A0 04 00 00 FF FF FF FF
80 03 00 00 FF FF FF FF
60 05 00 00 FF FF FF FF
20 04 00 00 FF FF FF FF
A0 03 00 00 FF FF FF FF
E0 04 00 00 FF FF FF FF
00 05 00 00 C0 02 00 00 FF FF FF FF
A0 02 00 00 FF FF FF FF
80 02 00 00 FF FF FF FF
40 02 00 00 FF FF FF FF
00 02 00 00 FF FF FF FF
E0 01 00 00 FF FF FF FF
C0 01 00 00 FF FF FF FF
80 01 00 00 FF FF FF FF
40 06 00 00 A0 01 00 00 FF FF FF FF
FF FF FF FF

[ganjul]

The material struct from the doc:

Code: Select all

typedef struct _materialblock { // 144 bytes
	dword header;
	dword size;
	dword pad02;
	dword number;
	float mat_color0[4]; // diffuse color ?
	float mat_color1[4];
	float mat_color2[4];
	float mat_color3[4];
	float mat_color5[4];
	float power; // specular power ??
	dword pad25; // 1
	dword pad26; // 1
	dword ffff; // 0xfffffffff
	dword tex_no; // texture used by this material
	dword pad29;
	dword transparency; // this is the dxt1 transparency flag
	dword pad31;
	dword pad32;
	dword indexoffset; // index buffer - offset
	dword indexsize; // index buffer - num
	dword pad35;
} materialblock;

I think the 3 float[4]'s after diffuse could be ambient, specular and emissive? Not sure what the 5th one is for.

each object gives you the vertex buffer offset and the index buffer offset, along with counts.

OK, yeah.

then at the end of every material section there are 3 counts..

3? I only see indexoffset and indexsize in the doc. That's probably enough to tell which triangles are affected by which material.
What 3rd value are you talking about?

you need the 1st and 2nd to start and end an element

By 'element' you mean material?

just jump to the vertex offset, and read those in(the more the better) then read your entire facebuffer and attempt to draw it into your scene

That's always a good idea.
I don't quite understand what the data in the vertex buffer is though. There are a number of vertex structs in the Viewer's sourcecode,
but I don't know C++, I don't understand which is used in the .cpp file.

That seems to depend on "dword vertex_type" in the "objheader", but I don't get which value corresponds to which struct, or what values there can be.

as for now, we'll assume the skeleton is indeed hardcoded or otherwise not obtainable without disassembly of the EXE
hopefully someone with a knowledge of disassembly can lend us a hand, but until then I'm trying to construct my own fictional skeleton

This is dodgy, but maybe you could ty to use the DOAX2 skeleton positions, maybe they haven;t changed it too much.

here's the CAT header once again
[LONG] HeaderID 0x20
[LONG] Offset1, Object Positioning
[LONG] Offset2, Morphs
[LONG] Offset3, Physics
[LONG] Offset4, Joints

I already feel the physics stuff is going to be a pain.

Everything below is beyond me. Good luck.

[mariokart64n]

ok, in b0ny's notes for the material at the end of the material section he has this

dword indexoffset; // index buffer - offset
dword indexsize; // index buffer - num
dword pad35;

the last dword is not padding, its another count. but since its an unknown constant it might aswell be pad anyway

00 00 00 80 90 00 00 00 00 00 00 00
00 00 00 00 00 00 A0 33 B6 09 47 3E
20 67 37 BD 65 78 17 3E 00 00 80 3F
00 00 80 3F 00 00 80 3F 00 00 80 3F
00 00 80 3F 00 00 80 3F 00 00 80 3F
00 00 80 3F 9A 99 19 3E CD CC CC 3D
CD CC CC 3D 00 00 80 3F 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
00 00 20 41 01 00 00 00 03 00 00 00
26 19 19 FF 11 00 00 00 00 00 00 00
00 00 00 00 00 04 00 00 20 00 00 00
B0 06 00 00 5E 01 00 00 02 00 00 00

next you'll notice he also has

dword indexoffset; // index buffer - offset
dword indexsize; // index buffer - num

if I recall this is again is inaccurate, none of these are an offset or size
there index counts to start and end your face reads
course they can be used to calculate offset and size. just multiply the counts by two, because
we're dealing with shorts, or 2byte integers.
you'll need to add the offset of the index buffer to the start count to get the relative offset in the index buffer

also yes, when I refer to an element I mean the material. elements are used in 3dsmax, they represent a part of a object
but usually with materials your faces or indices are given a face material id.. but in DOA, they treat these more like elements

because we're separating our polygon strips by this method.

And yeah I don't quite understand the vertex definitions supplied in the document.. even the identifier bytes they have recorded??? I donno
I haven't concluded my own research on the rest of the DOA files, just DOA2U

anyway here's the vertex structure
[FLOAT32] X Vertex Position
[FLOAT32] Y Vertex Position
[FLOAT32] Z Vertex Position
[FLOAT32] X Vertex Normal
[FLOAT32] Y Vertex Normal
[FLOAT32] Z Vertex Normal
[FLOAT32] U Texture Coordinate
[FLOAT32] Y Texture Coordinate

when vertex weights are present, the definition grows by 4bytes. in the header you'll know there's a different vertex type when the
values is not 0. I haven't documented, or even read in the extra data yet. it might not even be vertex weights lol

for now if your vertex type is not 0, expand the vertex definition by 4bytes, thats what I've done in my own script

I'll have a look at the physics and see what fun we're in for

[ganjul]

ok, in b0ny's notes

I hope you are talking about the DOAX html doc you posted a link to. The sourcecode of the DOA3 viewer shows that there are some differences in the struct data and struct lenghts which will make the DOAX and DOA3 XPR's incampatible.

the last dword is not padding, its another count. but since its an unknown constant it might aswell be pad anyway

Off-topic, but me being a noob in hex editing, how did you guess its another count? Did you just decide from the size of the dword?

there index counts to start and your face reads

Sorry, what?

you'll need to add the offset of the index buffer to the start count to get the relative offset in the index buffer

OK

also yes, when I refer to an element I mean the material. elements are used in 3dsmax, they represent a part of a object
but usually with materials your faces or indices are given a face material id.. but in DOA, they treat these more like elements

Never heard of that term. In Blender it's just "material". There are some Blender specific terms too, like "Armature" which means "skeleton". We should ty to use software-independent terms to not confuse each other.

And yeah I don't quite understand the vertex definitions supplied in the document.. even the identifier bytes they have recorded???

There isn't any in the html doc, again are you talking about the DOA3 viewer's sourcecode?

anyway here's the vertex structure
[FLOAT32] X Vertex Position
[FLOAT32] Y Vertex Position
[FLOAT32] Z Vertex Position
[FLOAT32] X Vertex Normal
[FLOAT32] Y Vertex Normal
[FLOAT32] Z Vertex Normal
[FLOAT32] U Texture Coordinate
[FLOAT32] Y Texture Coordinate

when vertex weights are present, the definition grows by 4bytes. in the header you'll know there's a different vertex type when the
values is not 0. I haven't documented, or even read in the extra data yet. it might not even be vertex weights lol

Thanks!
I dont think the extra 4 bytes in the end are enough to store vertex weight, btw. Normally it's a 4 byte float for a single weight and you like usually can have 3-4 bones assigned to each vertex.

for now if your vertex type is not 0, expand the vertex definition by 4bytes, thats what I've done in my own script

OK

I'll have a look at the physics and see what fun we're in for

I think it wouldn't hurt to know if they used an in-house physics engine or something like Havoc, PhysX or Bullet. I don't think they all work the same way.

They probably used sphere constraint for clothing and boobs, like the first one in this image http://www.ode.org/pix/joints.jpg
Or possibly softbodies for clothes instead.

I think for the constraints only angle limits would be required to be stored in the file.

[mariokart64n]

I can't recall which source I was reading off of, there were a few...
But I'm looking at DOAU, which may be simular to DOAX?

anyway I uploaded this, it contains info on the vertex definitions.
(the link is only temp, please save the doc for your own reference)
https://viewer.zoho.com/docs/rbM0B

also that number that was 2, and I said was a count.
isn't a count, its an unknown.
but being an int of 2, it could be a flag or count. it won't be a offset, or a float point value because its just 2.. its too small.
I don't believe its a flag, but its possible. I would lean more to a count, but then again theres no data there to support that theory either
all in all I've mislabeled that int aswell, for now its an unknown int

and to re-illustrated what elements are in 3dsmax.
basically anything that makes up a complete surface is an element
so say you had a Single Object, of three spheres they can all share the same material
but the spheres are in other words 3 sub objects within that object




sorry about the typo above, I meant each material gives you these two counts
1.) Starting Index
2.) Number of Indices to Read

I meant to say these counts just outline the starting index, and ending index...

aswell it is possible to store vertex weights in a 4byte space, true its not conventional.. but neither is 4 bones per weight these days.. gotta think old skool.
I bet these guys only store 2 bones per weight.. the definition could look something like
[BYTE] Bone Index 1
[BYTE] Bone Index 2
[BYTE] Vertex Weight 1
[BYTE] Vertex Weight 2

weights don't have to be super accurate, so its not uncommon to see them stored in a 8bit space

lastly I don't think Havoc, PhysX or Bullet is being used at all here.. for one PhysX and Bullet are fairly recent.. doa;s conception goes back awhile.

But haven't gotten anywhere yet with the physics sections yet.. but its not looking good lol.. they got alot of structures there to decipher

[ganjul]

haven't read your reply yet.

But here are the docs reuploaded:

Doax Xpr File:
http://www.scribd.com/doc/76850656/Doax ... k1d1ey8oii

DOAU Xpr Cat Format
http://www.scribd.com/doc/76850743/DOAU ... 5ytxoo50rm

[mariokart64n]

yup, you got what I got...

I'll trying searching for more specs and maybe left over source code from old tools I've collected over the last few years

EDIT

[ganjul]

Wow I just noticed my viewer didn't render most of the second document. I noticed it when viewing it in Scribd. I'm glad I reuploaded it

[mariokart64n]

source code on a tool called DOAXExporter

the DOAX format is probably the same as the DOA2U format..