Silent Hill 4 Xbox animations

[roocker666]

Hi, we already have a Noesis plugin for SH4 Xbox characters(meshes and skeleton), thanks to Durik256 and alanm1: SH4 Xbox characters & skeleton

So now I want to know if it is possible to extract animations too. I analyzed animations format and this is my research:

Ok, first a reminder, .bin files have a main header. First 4 bytes of this header tells you the number files or parts and then pointers to each part, I am using henry01.bin, most of all pointers go to animations, just last 3 pointers go to mesh, textures and shadow. I cut the 1st animation to analyze it better:

 

Edited Friday at 06:53 AM by roocker666

[roocker666]

In some animations Table2(T2) are Floats, looks like 3 Floats of data and 1 Float padding. You can see this in animation number 2. Here is henry01.bin and the two first animations(I cut those from henry01.bin):
henry01

I have zero  knowledge about animation formats, lol. I just tried to understand the different blocks of SH4 animations. Thanks! 

[shak-otay]

Well, looks to me like an unusual proceeding.  Wouldn't you go for the bone count first, then check a simple animation for its frames per bone?

edit: I see you found 29 pointers. Surprise... (== bone count)

In the smd file created from Henry.bin using Durik256/alanm1's py script the rotations are all zero. No idea whether it's a SH4 feature or whether they need to be found.

(Also it would be nice to have the real bone names instead of placeholders bone_[number].)

bone_0 is 'root', the two "chains" starting at 12 and 17 are not fingers, seems, because there's left hand/right hand bones only?

version 1
nodes
  0 "bone_0"  -1
  1 "bone_1"  0
  2 "bone_2"  1
  3 "bone_3"  2
  4 "bone_4"  3
  5 "bone_5"  1
  6 "bone_6"  5
  7 "bone_7"  6
  8 "bone_8"  0
  9 "bone_9"  8
  10 "bone_10"  9
  11 "bone_11"  10
  12 "bone_12"  9
  13 "bone_13"  12
  14 "bone_14"  13
  15 "bone_15"  14
  16 "bone_16"  15
  17 "bone_17"  9
  18 "bone_18"  17
  19 "bone_19"  18
  20 "bone_20"  19
  21 "bone_21"  20
  22 "bone_22"  4
  23 "bone_23"  11
  24 "bone_24"  7
  25 "bone_25"  16
  26 "bone_26"  -1
  27 "bone_27"  -1
  28 "bone_28"  -1
  29 "bone_29"  -1
end
skeleton
time 0
  0 0.000000 -219.022919 -2.569616 0.000000 -0.000000 0.000000
  1 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000
  2 18.000000 33.022919 -7.430384 0.000000 -0.000000 0.000000
  3 0.000000 78.000000 -2.000000 0.000000 -0.000000 0.000000
  4 0.000000 84.000000 -6.000000 0.000000 -0.000000 0.000000
  5 -18.000000 33.022919 -7.430384 0.000000 -0.000000 0.000000
  6 0.000000 78.000000 -2.000000 0.000000 -0.000000 0.000000
  7 0.000000 84.000000 -6.000000 0.000000 -0.000000 0.000000
  8 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000
  9 0.000000 -40.977081 -5.430384 0.000000 -0.000000 0.000000
  10 0.000000 -43.284210 -2.452426 0.000000 -0.000000 0.000000
  11 0.000000 -13.832092 3.474270 0.000000 -0.000000 0.000000
  12 10.000000 -30.000000 -4.000000 0.000000 -0.000000 0.000000
  13 24.000000 6.000000 -4.000000 0.000000 -0.000000 0.000000
  14 56.000000 0.000000 -2.000000 0.000000 -0.000000 0.000000
  15 54.000000 0.000000 2.000000 0.000000 -0.000000 0.000000
  16 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000
  17 -10.000000 -30.000000 -4.000000 0.000000 -0.000000 0.000000
  18 -24.000000 6.000000 -4.000000 0.000000 -0.000000 0.000000
  19 -56.000000 0.000000 -2.000000 0.000000 -0.000000 0.000000
  20 -54.000000 0.000000 2.000000 0.000000 -0.000000 0.000000
  21 0.000000 0.000000 0.000000 0.000000 -0.000000 0.000000
  22 1.000000 18.000000 22.000000 0.000000 -0.000000 0.000000
  23 0.000000 -3.830841 -0.022519 0.000000 -0.000000 0.000000
  24 -1.000000 18.000000 22.000000 0.000000 -0.000000 0.000000
  25 17.274750 6.581696 1.481747 0.000000 -0.000000 0.000000
  26 -18.000000 -24.000000 -18.000000 0.000000 -0.000000 0.000000
  27 18.000000 -24.000000 -18.000000 0.000000 -0.000000 0.000000
  28 -144.000000 -284.000000 -16.000000 0.000000 -0.000000 0.000000
  29 144.000000 -284.000000 -16.000000 0.000000 -0.000000 0.000000
end

Couldn't make sense of the pointers (to frame blocks?) Tried an offset (0x80) at no avail.

Search for signature 010001FF gave 170 results and might help structuring the bin.

(ok, you used it already - "animation ID")

Edited Saturday at 07:18 PM by shak-otay

[roocker666]

Sadly there are no bone names. Henry's skeleton has no bones in fingers because it is a playable character but it has an extra bone in one hand(for weapons maybe. Check this screenshot).  Yes, signature "010001FF" is the ID for animations so henry's file has 170 animations. Then each animation has two more signatures "030001FF"(don't know what this means, it has more bytes after this) and "020001FF"(pointers to frames?). We can search in SH4 E3 debug symbols, some .c files have structs about animations. For example this .c file:
SH4 E3 sg_anime.c this has some structs, maybe for those signatures. In line 236 that struct matches with "frame header", I don't know about Table1(T1) but Table2(T2) looks like key frames(?) 

Those .c files are for PS2 but Xbox and PC have the same animation format.

That animation folder has more .c files about animations, so maybe we can find some answers in those .c files.

[shak-otay]

Well, that c code is an information overkill for me. I'd start it simpler, here's an assumed animation curve of a bone:

(integer list at 0x5AA0 with 27 values should be the time line, 4 values skipped, 4, 0C etc )

The 27 points at 0x5AE0 are floats.

At 0xCAB0 a frame with 42 integer points (shorts):

Still we don't know which frame blocks belong to which bones.

I did a signature check (2 DWords):

   1C 3C    58x
   1C 4C    20x
   1C 5C    13x
   1C 6C     9x
   1C 7C     3x
   1C 8C     6x
   1C 9C     2x
   1C AC     2x
   1C BC     5x
   1C CC     2x

------------

   10 80    76x
   10 90    61x
------------------

  14 44    9x
  14 54    4x

  14 74    7x
  14 84    3x

  14 A4    3x
  14 B4    1x

  14 D4    1x

Sadly the sum of highest counts (58, 76, 61) exceeds 170, so I'm wrong here?

(The DWord before those 2 DWs (1C000000 8C000000 for example) is the count of frame lines in the specific frame block.

0x35 = 53 decimal at 0x407B8.)

edit: the high counts seem to be wrong because of uncomplete signature search:

for 0000 10000000 80000000 there's 3 findings only.

For 0000 1C000000 3C000000 still 58 results but 44 to be subtracted (DWord being 0)

so 14 findings remain. Good. But not checked now...

Edited Sunday at 03:00 PM by shak-otay

[roocker666]

According with this struct(which I think is "frame header"):

struct _anon4
{
	short key_type;
	short reserved;
	short nb_keys;
	char skeleton_no;
	unsigned char relative;
	unsigned int time_table_offset;
	unsigned int keys_offset;
};

first short "key_type"(unknow), 2nd short "reserved"(unknow2), 3rd short "nb_keys"(number of keys or count?), char "skeleton_no"(maybe bone number? ), char "relative"(unknow3), unsignet int "time_table_offset"(pointer to Table1), unsigned int "keys_offset"(pointer to Table2).

So yes, maybe Table1 is time line(0x5AA0) and Table2 is key frames(0x5AE0 and 0xCAB0, these could be short or Float). I still don't know what are those bytes after 03 00 01 FF signature..