models

Path	Type	FixedSize	ArrayValueSize	Interleaved	Name
/root/0/x/0/0	s_t2fsDataModelInfo	32			info
/root/0/x/0/1	t2fsArray		4		model_0_1
/root/0/x/1/0/x	t2fsArray < s_t2fsDataVertex >		20	Yes	vertexBuffer
/root/0/x/1/1/0	t2fsArray		4		model_1_1_0
/root/0/x/1/2/x/x/0	s_t2fsDataMaterial	24			material
/root/0/x/1/2/x/x/1	unknown				indices
/root/0/x/1/3/x/0	t2fsArray		4		model_1_3_x_0
/root/0/x/1/3/x/1	s_t2fsDataBone	112			bone
/root/0/x/1/4/x	t2fsArray < s_t2fsDataHotpoint >		20		hotpointsArray
/root/0/x/1/5/x	unknown	8			model_1_5_x
/root/0/x/2/x/0	t2fsArray		2		model_2_x_0
/root/0/x/2/x/1	t2fsArray < s_t2fsDataAnimationBoneIndices >		4		model_2_x_1
/root/0/x/2/x/2	t2fsArray < s_t2fsDataBoneOrientation >		20		boneOrientations
/root/0/x/2/x/3/0	unknown	16			model_2_x_3_0
/root/0/x/2/x/3/1	t2fsArray		12		model_2_x_3_1
/root/0/x/2/x/4	t2fsArray		28		model_2_x_4
/root/0/x/2/x/5/0	s_t2fsDataAnimationHeader	32			model_2_x_5_0
/root/0/x/2/x/5/1	unknown				model_2_x_5_1
/root/0/x/2/x/5/2	unknown				model_2_x_5_2
/root/0/x/3	t2fsArray		28		model_3

/root/0

• child-type: variable
• childeren: /root/0/x model

/root/0/x

• child-type: fixed
• childeren:
  • /root/0/x/0 model_0
  • /root/0/x/1 model_1
  • /root/0/x/2 poses
  • /root/0/x/3 model_3

/root/0/x/0

• child-type: fixed
• childeren:
  • /root/0/x/0/0 info
  • /root/0/x/0/1 model_0_1

/root/0/x/0/0

• child-type: data
• data-type: s_t2fsDataModelInfo
• data-size: 32

only 8 zero bytes when unset, this is only set when there are bone(s)? SEE s_t2fsDataModelInfo

/root/0/x/0/1

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 4 bytes

array count is the same as amount of poses/orientations, to is mostly absent.

/root/0/x/1

• child-type: fixed
• childeren:
  • /root/0/x/1/0 meshes
  • /root/0/x/1/1 model_1_1
  • /root/0/x/1/2 surfaces
  • /root/0/x/1/3 bones
  • /root/0/x/1/4 hotpoints
  • /root/0/x/1/5 model_1_5

/root/0/x/1/0

• child-type: variable

model_1_0: same child count as model_1_2, model_1_4, model_1_5

• childeren: /root/0/x/1/0/x vertexBuffer

/root/0/x/1/0/x

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 20 bytes

/root/0/x/1/1

• child-type: fixed
• childeren:
  • /root/0/x/1/1/0 model_1_1_0

/root/0/x/1/1/0

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 4 bytes

only 57/2430 models have this

/root/0/x/1/2

• child-type: variable

same child count as model_1_0, model_1_4, model_1_5

• childeren: /root/0/x/1/2/x meshId

/root/0/x/1/2/x

• child-type: variable

model_1_2_x: child count might be different per sibling

• childeren: /root/0/x/1/2/x/x surface

/root/0/x/1/2/x/x

• child-type: fixed

model_1_2_x_x

• childeren:
  • /root/0/x/1/2/x/x/0 material
  • /root/0/x/1/2/x/x/1 indices

/root/0/x/1/2/x/x/0

• child-type: data

model_1_2_x_x_0: first u32 is texture-id

• data-type: s_t2fsDataMaterial
• data-size: 24

/root/0/x/1/2/x/x/1

• child-type: data
• data-type: unknown
• data-size: varies

Read as 16 bit values, what to do depends on whether what flag is set. When bit number 16 is flagged, the next 15 bits are 3 indices, 5 bits each, so max 32 verts per indice block, thus we have to keep a vert offset. When bit number 15 is flagged, bit numbers 1 to 8 are the bone id. When bit number 14 is flagged it indicates a new indice block, bit numbers 1 to 5 is the vert count to add to a vert offset after this block has been processed, bit numbers 6 to 10 indicate some operation that is currently not fully understood yet, the seen set values are either 0, 11 or 22, it has to do with using vert indexes outside of the current inside block, when set to 0 there seems to be no issue.

/root/0/x/1/3

• child-type: variable
• childeren: /root/0/x/1/3/x model_1_3_x

/root/0/x/1/3/x

• child-type: fixed
• childeren:
  • /root/0/x/1/3/x/0 model_1_3_x_0
  • /root/0/x/1/3/x/1 bone

/root/0/x/1/3/x/0

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 4 bytes

some indexes?

/root/0/x/1/3/x/1

• child-type: data

model_1_3_x_1

• data-type: s_t2fsDataBone
• data-size: 112

node/bone

/root/0/x/1/4

• child-type: variable

same child count as model_1_0, model_1_2, model_1_5

• childeren: /root/0/x/1/4/x hotpointsArray

/root/0/x/1/4/x

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 20 bytes

possible hotpoints, only 116 entries on all models but looks interesting

/root/0/x/1/5

• child-type: variable

same child count as model_1_0, model_1_2, model_1_4

• childeren: /root/0/x/1/5/x model_1_5_x

/root/0/x/1/5/x

• child-type: data
• data-type: unknown
• data-size: 8

only 607 entries on all models, all set to 0000 0000 0800 0000

/root/0/x/2

• child-type: variable

model_2: variable count equals pose count

• childeren: /root/0/x/2/x pose

/root/0/x/2/x

• child-type: fixed

model_2_x

• childeren:
  • /root/0/x/2/x/0 model_2_x_0
  • /root/0/x/2/x/1 model_2_x_1
  • /root/0/x/2/x/2 boneOrientations
  • /root/0/x/2/x/3 model_2_x_3
  • /root/0/x/2/x/4 model_2_x_4
  • /root/0/x/2/x/5 model_2_x_5

/root/0/x/2/x/0

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 2 bytes

almost always has count, but most times all values are just 0x0000, counts differ

/root/0/x/2/x/1

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 4 bytes

count is the same as there are bones, these appear to be two 16bit values, possible signed. Maybe rotation count and position count? These are either set to 0xFFFF or seem to count up starting from 0.

/root/0/x/2/x/2

• child-type: data

model_2_x_2

• data-type: array
• data-size: varies
• array-value-size: 20 bytes

array count equals bone count

/root/0/x/2/x/3

• child-type: fixed
• childeren:
  • /root/0/x/2/x/3/0 model_2_x_3_0
  • /root/0/x/2/x/3/1 model_2_x_3_1

/root/0/x/2/x/3/0

• child-type: data
• data-type: unknown
• data-size: 16

/root/0/x/2/x/3/1

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 12 bytes

Mostly unset

/root/0/x/2/x/4

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 28 bytes

/root/0/x/2/x/5

• child-type: fixed
• childeren:
  • /root/0/x/2/x/5/0 model_2_x_5_0
  • /root/0/x/2/x/5/1 model_2_x_5_1
  • /root/0/x/2/x/5/2 model_2_x_5_2

/root/0/x/2/x/5/0

• child-type: data
• data-type: s_t2fsDataAnimationHeader
• data-size: 32

Mostly starts with 0x00000000, lots of same values for all models, some variation

/root/0/x/2/x/5/1

• child-type: data
• data-type: unknown
• data-size: varies

based on data sizes and some repeating values this is likely bone rotation data, however I fail to make sense of the data, it looks compressed or maybe some sort of other bit stream. all start with 0x71c35b87 or 0x71c35b07, these bytes reoccur in large files, sizes between them are weird (some are even others are uneven).

/root/0/x/2/x/5/2

• child-type: data
• data-type: unknown
• data-size: varies

based on data sizes and some repeating values this is likely bone position data, however I fail to make sense of the data, it looks compressed or maybe some sort of other bit stream.

/root/0/x/3

• child-type: data
• data-type: array
• data-size: varies
• array-value-size: 28 bytes

0x1C, mostly unset