[REL] Disney INFINITY Model Extractor

[cra0]

Meh bones are in .oct might reverse next week

Code: Select all

//Disney Infinity Research
// Cra0kalo/Mariokart64n/Luxox_18
//PC Little Endian


struct VBufHeader
{
// NOP
}

//ShaderDump VertexStructure

struct GPU_ASM
{
    vs_3_0
    def c0, 4, 1, 0, 1000
    def c1, 0.00100000005, 0, 0, 0
    dcl_blendindices v0
    dcl_blendweight v1
    dcl_normal v2
    dcl_position v3
    dcl_texcoord1 v4
    dcl_texcoord v5
    dcl_texcoord o0.xyz
    dcl_position o1
    dcl_texcoord1 o2
    dcl_texcoord2 o3.xy
    slt r0, v0, -v0
}

// Buffer
// Size 24
struct VBufStruc
{
float vd x
float vd y
float vd z
hfloat TextureU
hfloat TextureV
uint32 unknownPadding
uint32 VertexColor
}


// Buffer
// Stride 16
struct VBufStruc2
{
hfloat vn_x
hfloat vn_y
hfloat vn_z
hfloat vn_w

hfloat vt_x
hfloat vt_y
hfloat vt_z
hfloat vt_w


}



// Index Buffer
// Size 24
struct IndexBufStruc
{
uint16 face1
uint16 face2
uint16 face3
}

DL
http://cra0kalo.com/public/Disney%20INF ... ractor.zip

[Chipicao]

Nice work!

It seems normals are easy, you probably figured them out already.
After the first VB block described by you there are groups of 16bytes per vertex that contain normals and tangents as half floats (x y z w).

Here's a short maxscript to demonstrate:

Code: Select all

fn readHalf binstr =
(
	ashort = readShort binstr #signed
	nx = (bit.shift (bit.and ashort 0x8000) 16)+(bit.shift (bit.and ashort  0x7fff) 13)+(bit.shift (127 - 15) 23) 
	nx = bit.intAsFloat nx
)

iarr = #()
varr = #()
tarr = #()
narr = #()
farr = #()

IB = getOpenFileName types:"*.ibuf|*.ibuf"
if IB != undefined do
(
	IBsize = getFileSize IB
	
	f = fopen IB "rb"
	do append iarr (readshort f #unsigned) while (ftell f) < IBsize
	fclose f
	
	VB = substituteString IB ".ibuf" ".vbuf"
	if doesFileExist VB do
	(
		f = fopen VB "rb"
		
		for v=1 to (amax iarr) + 1 do
		(
			vx = readfloat f
			vy = readfloat f
			vz = readfloat f
			append varr [vx, -vz, vy]
			
			tx = readHalf f
			ty = readHalf f
			append tarr [tx, 1-ty, 0]
			
			fseek f 8 #seek_cur
		)
		
		for v=1 to (amax iarr) + 1 do
		(
			nx = readHalf f
			ny = readHalf f
			nz = readHalf f
			append narr [nx, -nz, ny]
			
			fseek f 10 #seek_cur
		)
		fclose f
		
		for i=1 to iarr.count/3 do
		(
			i1 = iarr[i*3-2] + 1
			i2 = iarr[i*3-1] + 1
			i3 = iarr[i*3] + 1
			append farr [i1, i2, i3]
		)
		
		max modify mode -- open mod panel for edit_normals to work
		cui.expertModeOn()
		disableSceneRedraw()
		amesh = mesh vertices:varr faces:farr
		meshop.setMapSupport amesh 1 true
		setMesh amesh tverts:tArr
		
		--set smoothing group of all faces to 1 to get one normal per vertex
		for face = 1 to amesh.numfaces do setFaceSmoothGroup amesh face 1
		--set normals via edit normals modifier
		select amesh
		addmodifier amesh (Edit_Normals ()) ui:off
		amesh.Edit_Normals.MakeExplicit selection:#{1..nArr.count}
		EN_convertVS = amesh.Edit_Normals.ConvertVertexSelection
		EN_setNormal = amesh.Edit_Normals.SetNormal
		normID = #{}
		--apply normals
		for v = 1 to nArr.count do
		(
			free normID
			EN_convertVS #{v} &normID
			for id in normID do EN_setNormal id nArr[v]
		)
		collapseStack amesh
		cui.expertModeOff()
		enableSceneRedraw()
	)
)

And the result, in order: without normals (autoshmooth by max), with normals and normals themselves

[cra0]

Nice work!

It seems normals are easy, you probably figured them out already.
After the first VB block described by you there are groups of 16bytes per vertex that contain normals and tangents as half floats (x y z w).

Here's a short maxscript to demonstrate:

Code: Select all

-snip-

And the result, in order: without normals (autoshmooth by max), with normals and normals themselves

Yep I figured that out after scrolling down. It's really werid how they split the structure like that though. After the normal info that stuff might be bone weights and links not sure though I think the bone matrixes are stored in those .oct files I'll have a look today.

If anyone else is curious to take a look here is an example model (.oct/.vbuf/.ibuf/.bent/.mtb)
http://cra0kalo.com/public/research/wr_vanellope.zip

[Chipicao]

No, the part after normals are definitely tangents (or binormals). And if imported as vertices they create a sphere, as expected for normalized vector coords.


I think bone indices and blend weights are in the first vertex block, specifically what you identified as "unknown padding" and "vertex color".
That "padding" looks like 4 uint8 bone indices. They are 0 at the beginning, but they start to have values afterwards.


The next 4bytes are definitely not vertex colors, because they would look like this:

I think they are 4 weights stored as uint8 and need to be converted to floats, probably dividing by 255.

It's really weird how they split the structure like that though.

I've seen it before in a few games, it must be some sort of optimization.
These buffers should be defined in one of the other files, with the exact number of indices, vertices, and also the number of vertex data blocks (there could be more than 2 in other models) and what elements they contain.
Have you figured out any of these, or are you just importing the raw data?

Also I see you assigned head and torso textures. Did you split the mesh manually or did you find information about material IDs?

[cra0]

No, the part after normals are definitely tangents (or binormals). And if imported as vertices they create a sphere, as expected for normalized vector coords.


I think bone indices and blend weights are in the first vertex block, specifically what you identified as "unknown padding" and "vertex color".
That "padding" looks like 4 uint8 bone indices. They are 0 at the beginning, but they start to have values afterwards.


The next 4bytes are definitely not vertex colors, because they would look like this:

I think they are 4 weights stored as uint8 and need to be converted to floats, probably dividing by 255.

It's really weird how they split the structure like that though.

I've seen it before in a few games, it must be some sort of optimization.
These buffers should be defined in one of the other files, with the exact number of indices, vertices, and also the number of vertex data blocks (there could be more than 2 in other models) and what elements they contain.
Have you figured out any of these, or are you just importing the raw data?

Also I see you assigned head and torso textures. Did you split the mesh manually or did you find information about material IDs?

I think i found the vertex count for Bob open the .oct file and go to

0x1D710

0x1D7D4

should be 5558 I applied them manually the .mtb i think has the drawcall/vertex structure for each mesh piece on a different material have to look into it. Need to find that table to figure out the Submeshes

[yocarinha]

test

[Chipicao]

Not to mention some missing limbs
It seems Hellen's files actually contain 3 index buffers and 3 vertex buffers one after another.

IB1: 18777 indices
IB2: 4806 indices
IB3: 2013 indices

VB1: 3784 vertices
VB2: 952 vertices
VB3: 410 vertices



This is why we really need to figure out the structure of .oct files in order to read meshes properly.

[chrrox]

if you want to send me a sample i can look.

[Chipicao]

Here you go:

If anyone else is curious to take a look here is an example model (.oct/.vbuf/.ibuf/.bent/.mtb)
http://cra0kalo.com/public/research/wr_vanellope.zip

The oct file looks like some sort of database with string values at the beginning and data afterwards.
uint32 at offset 0x0C indicates the size of the string portion
next uint32 is the size of the rest of the file

[howfie]

indeed, OCT files must be parsed for proper mesh information. OCT = scene graph format though. have fun. i parsed a few nodes and stopped. confusing has hell to put the tree together (hard to determine what the structures are for each node). some, like Translation nodes are easy to determine, but others... not so.

Code: Select all

     // 45 00 - 05 08 SubNetworkPool
     // 46 00 - 03 00 0B 0C SubNetwork
     // 47 00 - Name
     // 48 00 - 0B 0C RB_lowerBody_Mesh
     // 49 00 - Type
     // 4A 00 - 01 0C Scene
     // 4B 00 - 05 10 BasisPool
     // 4C 00 - 03 00 0B 14 49 00 Basis
     // 4D 00 - 0B 14 - Geometry3d
     // 4E 00 - Behavior
     // 4F 00 - 05 10 - 4C 00 - Root
     // 50 00 - 0B 14 - 47 00 - 48 00 - 1B 14
     // 51 00 - 00 0B 14 4E 00
     // 52 00 - 05 10 4C 00
     // 53 00 - 0B 14 49 00
     // 54 00 - 0B 14 4E 00 4F 00 0A 0C
     // 55 00 - 02 48 00
     // 56 00 - 1A 0C
     // 57 00 - 02 00 01 1A 0C
     // 58 00 - 04 00 01 01 01 01 0C
     // 59 00 - 05 10
     // 5A 00 - 03 00 1B 14
     // 5B 00 - 02 0B 14 49 00
     // 5C 00 - 1B 14
     // 5D 00 - 01 1B 14
     // 5E 00 - 00 01 14
     // 5F 00 - 12 18
     // 60 00 - 03 - 00 00 00 00 - E1 4D 68 3F - 00 00 00 00 - 01 0C - Translation
     // 61 00 - 01 0C - ProcessorNodePool
     // 62 00 - 01 10 - BasisConversionPool
     // 63 00 - 1B 14 - BasisConversion
     // 64 00 - 01 1B 14 - FromBasisRef
     // 65 00 - 00 1B 14 - ToBasisRef
     // 66 00 - 00 01 0C - DataNodeRef
     // 67 00 - 01 0C - ComponentFamilyPool

[TaylorMouse]

What version of Infinity are we talking about here, the Wii, PS3, ... other?

T.

[pepsiguy2]

PC, I believe.

[CriticalError]

very nice, thanks a lot for all supporters, thats great, only maximport remain

[TaylorMouse]

Yeah, that mesh import with multiple submeshes, like Misses Incredible, is a pain,
on the other hand I found that the .tbody files can easily renamed to .dds and you have the texture

Any progress on the OCT files?

T.

[jmgg]

I am trying to extract some models. but I get unexpected results with the obj file.
I do not know what I'm doing wrong. Smd with MilkShape gives the same problem...

1.jpg