Page 1 of 5
[REL] Disney INFINITY Model Extractor
Posted: Mon Feb 03, 2014 1:20 pm
by 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

Re: [REL] Disney INFINITY Model Extractor
Posted: Mon Feb 03, 2014 8:28 pm
by 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

Re: [REL] Disney INFINITY Model Extractor
Posted: Tue Feb 04, 2014 8:08 am
by cra0
Chipicao wrote: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:
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
Re: [REL] Disney INFINITY Model Extractor
Posted: Tue Feb 04, 2014 11:51 am
by 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.
cra0 wrote: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?
Re: [REL] Disney INFINITY Model Extractor
Posted: Tue Feb 04, 2014 2:24 pm
by cra0
Chipicao wrote: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.
cra0 wrote: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
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu Feb 06, 2014 4:31 pm
by yocarinha
test
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu Feb 06, 2014 6:48 pm
by 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.
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu Feb 06, 2014 7:07 pm
by chrrox
if you want to send me a sample i can look.
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu Feb 06, 2014 8:16 pm
by Chipicao
Here you go:
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
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu Feb 06, 2014 8:20 pm
by 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
Re: [REL] Disney INFINITY Model Extractor
Posted: Thu May 01, 2014 4:48 pm
by TaylorMouse
What version of Infinity are we talking about here, the Wii, PS3, ... other?
T.
Re: [REL] Disney INFINITY Model Extractor
Posted: Sat May 03, 2014 2:39 am
by pepsiguy2
PC, I believe.
Re: [REL] Disney INFINITY Model Extractor
Posted: Fri May 23, 2014 11:26 pm
by CriticalError
very nice, thanks a lot for all supporters, thats great, only maximport remain

Re: [REL] Disney INFINITY Model Extractor
Posted: Sun May 25, 2014 1:21 pm
by 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.
Re: [REL] Disney INFINITY Model Extractor
Posted: Sat Oct 04, 2014 11:41 pm
by 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