03-28-2018, 02:03 PM
(This post was last modified: 03-30-2018, 01:28 AM by TwiliChaos.)
So I put in quite a bit of work trying to get animations ripped. For the most part, I've figured out the format, but some bytes are encrypted and I only have 1/5 of them solved, as of writing this. Basically the animation chunk goes as followed.
PLM Chunk:
I don't know how to explain the format without a bit of indentation, so here you go
The values of dynamic bytes are plugged into a 256 length array that outputs values 0 through 8, and these values are added together to get the final value for that bone's quaternion, position, or scale. (Scale seems to always be empty with the models I've checked)
My current progress on the decryption array
Unfortunately I'm starting to find that some of these values are likely incorrect, and with this being such a tedious and very error-prone process where any mistake, if not caught early, will undo a ton of work, I need to know if there is a quicker way to get this array filled out with 100% accuracy.
Also, some of the values seem like they work for newer models, but not work for older ones, such as 0x1F as 5 works for newer ones, but 0x1F as 4 works for older ones. It's difficult to say if the newer models add 1 to the final number, the older ones subtract 1, or if there's a flag somewhere that tells the game to add or subtract... I don't know.
Edit: In regards to the existence of a flag that may add or subtract from the keyframe count, that might be true. With a couple files I've looked at that have been a pain in the neck in that regard, it looks like in the PLM$ area with the track info, the 1st byte's 2nd nibble is 0 for unaffected keyframe counts, and 8 for keyframe counts that subtract 1 to get the final result. I don't know yet if the first nibble has much relevance, as it's mostly C and in one example 4. This byte is also always the same for each track in the file.
Edit2: Okay, if there is a flag, what I pointed out is almost certainly not it.
Edit3: Confirmed because of Valkyrja transmog 3's idle animation having 361 frames, the 6th and 7th byte are 2 bytes frame count rather than one.
PLM Chunk:
- 4 bytes String "PLM$"
- 2 bytes > unknown_size_A anim_track_count
- 20 bytes > some unknown value
- anim_track_count * 7 bytes > the 6th byte 6th and 7th byte are a short for the maximum size of an animation track, which I put in track_size array
I don't know how to explain the format without a bit of indentation, so here you go
- Track (amount of tracks equal to anim_track_count)
- 24 bytes unknown, possibly position values for UI elements
- Bone data, amount equal to bone_count
- Dynamic bytes > encrypted values that contain the amount of Quaternion keyframes.
- quaternion_keyframe_count * 8 > quaternion values
- Dynamic bytes > encrypted values that contain the amount of Position keyframes.
- position_keyframe_count * 12 > position values
- Dynamic bytes > encrypted values that contain the amount of Scale keyframes.
- scale_keyframe_count * 12 > scale values
- Dynamic bytes > encrypted values that contain the amount of Quaternion keyframes.
- 24 bytes unknown, possibly position values for UI elements
The values of dynamic bytes are plugged into a 256 length array that outputs values 0 through 8, and these values are added together to get the final value for that bone's quaternion, position, or scale. (Scale seems to always be empty with the models I've checked)
Code:
FF FF FF FF FF FF FF FF FF FF 01 -- Quaternion keyframe count, 10 bytes of 8 and 1 byte of 1, adds to 81
EF 0C A6 6C C6 C9 A6 D9 -- Quaternion values (81 * 8 bytes)
EE 0C A7 6C C7 C9 A7 D9
EB 0C AB 6C CC C9 AA D9
...
EF 0C A6 6C C6 C9 A6 D9
00 -- position keyframe count (empty)
C7 4F 00 00 F4 40 00 00 4A 1D 00 00 -- position value
00 -- scale keyframe count (empty)
00 00 01 00 00 00 01 00 00 00 01 00 -- scale valueMy current progress on the decryption array
Code:
decrypt_keyframe_size_value = #(
-- 0 1 2 3 4 5 6 7 8 9 A B C D E F
0, 1, 1, 2, 1, 1, , 3, 1, , , , , 3, 3, 4, -- 0x00
1, , , , , 2, , , , , , , , , , 5, -- 0x10
1, 2, , , , , , , , , , , , , , , -- 0x20
, 3, , , , , , , , 4, , , , , , 6, -- 0x30
1, 2, , , , , , , , , , , , , , , -- 0x40
1, , , , , 4, , , , , , , , , , 6, -- 0x50
, , , , , , , , , , , , , , , , -- 0x60
, , , , , , , , , , , , 4, , , 7, -- 0x70
1, 2, , 3, , 4, , 4, , , , , , , , 5, -- 0x80
, , , , , , , , , , , , , , , 6, -- 0x90
, , , , , , , , , , , , , , , 6, -- 0xA0
, , , , , , , , , , , 6, , , , 7, -- 0xB0
2, 3, , , , , , 5, , , , , , , , , -- 0xC0
, , , , , 5, , , , , , , , , , 7, -- 0xD0
3, 4, 5, 5, , , , 6, , , , , , , , 7, -- 0xE0
4, 5, , , , 6, , 7, 5, , , 7, 6, 7, 7, 8, -- 0xF0Also, some of the values seem like they work for newer models, but not work for older ones, such as 0x1F as 5 works for newer ones, but 0x1F as 4 works for older ones. It's difficult to say if the newer models add 1 to the final number, the older ones subtract 1, or if there's a flag somewhere that tells the game to add or subtract... I don't know.
Edit: In regards to the existence of a flag that may add or subtract from the keyframe count, that might be true. With a couple files I've looked at that have been a pain in the neck in that regard, it looks like in the PLM$ area with the track info, the 1st byte's 2nd nibble is 0 for unaffected keyframe counts, and 8 for keyframe counts that subtract 1 to get the final result. I don't know yet if the first nibble has much relevance, as it's mostly C and in one example 4. This byte is also always the same for each track in the file.
Edit2: Okay, if there is a flag, what I pointed out is almost certainly not it.
Edit3: Confirmed because of Valkyrja transmog 3's idle animation having 361 frames, the 6th and 7th byte are 2 bytes frame count rather than one.