vagonumero13 tools (REDELBE, rdbtool, g1mtools, doa6decsave) Update 17 Aug: REDELBE 3.0

[4cite]

On 12/14/2019 at 1:43 AM, vagonumero13 said:

UPDATE REDELBE.

Hey man, I'm brand new to DoA6 Modding and I've only been able to find Modder Base which has v0.82 last edited in June. Where do I go for further updates?

[vagonumero13]

5 hours ago, 4cite said:

Hey man, I'm brand new to DoA6 Modding and I've only been able to find Modder Base which has v0.82 last edited in June. Where do I go for further updates?

It is in this thread, in the first post.

[4cite]

9 hours ago, vagonumero13 said:

It is in this thread, in the first post.

Thank you!

[ayudokic]

Thank You!

[Rebel o Conner]

where to find the input8.dll file?

[3566482543]

11 minutes ago, Rebel o Conner said:

where to find the input8.dll file?

Input or dinput?

dinput8.dll

[Joschuka]

Hey @vagonumero13, just wanted to tell you that my partners have almost labelled everything in G1A/G2A, you can find the latest binary template here https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1A.bt

 

Basically section 1 is bit packed and contains some kind of "frame headers" with some info like the number of splines for this frame and the data offset. Other header info include the max bone index and other stuff.

The unknown ushort in section 2 (the one who's mostly 0 and 1) is suspected to design the spline type (0 for rotation, 1 for translation, 2 for scale).

What's left to do is to figure out how to read the section 3 data and we should be good to go.

 

On an unrelated note, could you tell me what NUNO/NUNV versions do the DOA6 models use ? I suspect cloth fixing equations to rely on that since I have to use different formulas to fix old g1m like Hyrule Warriors and recent ones like FETH. But maybe they just rely on Cloth sections like 0301 and 0303, I need to dig a bit more.

[vagonumero13]

2 hours ago, Joschuka said:

Hey @vagonumero13, just wanted to tell you that my partners have almost labelled everything in G1A/G2A, you can find the latest binary template here https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1A.bt

 

Basically section 1 is bit packed and contains some kind of "frame headers" with some info like the number of splines for this frame and the data offset. Other header info include the max bone index and other stuff.

The unknown ushort in section 2 (the one who's mostly 0 and 1) is suspected to design the spline type (0 for rotation, 1 for translation, 2 for scale).

What's left to do is to figure out how to read the section 3 data and we should be good to go.

 

On an unrelated note, could you tell me what NUNO/NUNV versions do the DOA6 models use ? I suspect cloth fixing equations to rely on that since I have to use different formulas to fix old g1m like Hyrule Warriors and recent ones like FETH. But maybe they just rely on Cloth sections like 0301 and 0303, I need to dig a bit more.

 

Precisely I was looking at this this morning, I could figure out that the value at offset 0x10 in the header is the number of frames (including non-keyframes, e.g. you can virtually extend any animation by increasing this value, although that just will cause the character to be in the last position for longer, since the number of keyframes will remain the same). If you divide this by fps, you get the length in seconds of the animation. I think this part doesn't match your data (that would be, more or less, max_bone_index in your code, I think). So basically those 4 bytes are number of real frames & number of keyframes, it would make sense that they go together.

 

Also had figured out that one of the two 16 bit values that go in pairs was the offset of the keyframe divided by 4, but I will check later with your data, as I had no idea of what the other value was (I hadn't thougt that these things would be bitpacked).

 

As for the data of matrices, I can tell you about the translation. In DOA6 animations, the first matrix is always an all 0 matrix, and the opcode value in the frame (the 0, 1, 2) is 0, and the second matrix has opcode 1. I did tests with the later and the translation is stored at the last 4 float values (well, only first 3 of those 4), so well, this coincides with where the translation data in a transformation matrix where columns are stored before rows. (I did test with an animation, and this caused moves to x, y, z). I think that was the order of DirectX matrices, but me and matrix orders don't get along very well, and I don't know if they would use same matrix order in all plattforms.

 

(btw only difference between G2A 0300 and 0500, is that 0300 doesn't have the " unknown1_count " in header).

 

---------

A random .g1m I had at hand (Mai standard costume): NUNO is 9200. NUNV is 1100. That said, I have never looked at these sections.

[Joschuka]

Ah that info about the value at 0x10 is interesting, wouldn't have thought about it being the total duration in frames. I need to double check with my friend though but apparently they found out that game reads these 4 bytes as

// Actual disasm
    // frame_header_size = (packed_data >> 18) & 0x3FFC;
    // max_bone_index    =  packed_data & 0xFFF;
    //
    // frame_header_blob_size could be 12 bits, and max_bone_index could be 20--
    // however this is not how the game parses the data.

the "frame header size" seems to match almost everytime but what is called "max_bone_index" is probably the duration you're talking about. Unfortunately we can't check this ourselves as this game doesn't have any name for the anims so we can't modify some stuff and see what happens in game afterwards, we weren't able to isolate some stuff yet since there are so many... But if you tested it that should be the case, thanks for the info.

 

Nice, thanks for the info about the translation stuff, this doesn't the idea that 01 would be an ID for a translation spline, that's good. I thought about these matrices being transform matrices but some values seemed wrong and if the int gives the spline type as we suppose it wouldn't be needed to have a whole transform matrix with all rotation, translation and scale, We'll look more into it.

When you say floats you mean 16bits floats (or halffloats) not 32 bits floats right ?

Yeah my partner noticed that about the " unknown1_count " , it's completely missing in the G1A and early G2A files apparently.

 

Ok interesting, the NUNO version is the same as in Fire Emblem, there are no NUNV versions in FE but these NUNV are almost exactly the same as NUNO, just used for hair instead of cloth (although NUNO is used for hair in FE lol)

There's a lot of info we don't know yet but basically it contains some physics bones which are probably used by the physics engine. Also the NUNO version seems to indicate which equations have to be used to fix the cloth meshes. To illustrate, here's Edelgard without the NUNO sections not parsed by my script:

And here's one with the NUNO sections taken into account and cloth fixed:

Don't mind the white planes, these are just mesh drivers created to facilitate cloth rigging in Blender (with some Data transfer stuff for example)

I don't know much more about these though, only NUNO0301 and NUNO0303 sections seem to be used to get these bones from.

[vagonumero13]

17 hours ago, Joschuka said:

 

 

 

I have soem doubts about the "next_header_offset". I think it may mean other thing. This is a dump of those three values in a DOA animation (spline_count, next_header_offset, data_offset): (btw, I had to change data type to unsigned int, or otherwise spline_count=2 would get the -2 value).

 

Spoiler

2 0x4 0x0
2 0x8 0x160
1 0xc 0x300
1 0x10 0x530
1 0x14 0x810
1 0x18 0x9f0
1 0x1c 0xba0
1 0x20 0xef0
1 0x24 0x11d0
1 0x28 0x1340
1 0x2c 0x1530
1 0x30 0x1730
1 0x34 0x19d0
1 0x38 0x1bf0
1 0x3c 0x1e60
1 0x40 0x2320
1 0x44 0x2720
1 0x48 0x29b0
1 0x4c 0x2c50
1 0x50 0x31a0
2 0x54 0x3640
2 0x58 0x37e0
1 0x5c 0x3a30
1 0x60 0x3d40
1 0x64 0x3e00
1 0x78 0x3e30
1 0x7c 0x40f0
1 0x80 0x42f0
1 0x84 0x44f0
1 0x88 0x4710
1 0x8c 0x48b0
1 0x90 0x4ac0
1 0x94 0x4bf0
1 0x98 0x4cc0
1 0x9c 0x4db0
1 0xa0 0x4e50
1 0xa4 0x4f10
1 0xa8 0x5000
1 0xac 0x50e0
1 0xb0 0x51c0
1 0xb4 0x5280
1 0xb8 0x5390
1 0xbc 0x5460
1 0xc0 0x55d0
1 0xc4 0x5690
1 0xc8 0x57d0
1 0xcc 0x5900
1 0xd0 0x5a60
1 0xd4 0x5b70
1 0xd8 0x5cc0
1 0xdc 0x5e00
1 0xe0 0x5ee0
1 0xe4 0x6030
1 0xe8 0x6150
1 0xec 0x6280
1 0xf0 0x63a0
1 0xf4 0x64b0

 

 

The spline count is correct. The data offset is also correct (you have to divide that number by 4 to actually get the offset, though).

But the next header offset doesn't seem to match. Notice that at some point it goes from 0x64 to 0x78. And offsets like 0xe8-0xf4 would be out of range.

 

I think that number is actually that number / 4 (probably the bit field was incorrect), which causes the number to go in a sequence like: 1, 2, 3, 4, ... 61, where the range 25-29 was skipped for some reason.

[acuna43]

Vagunumero13

I have problem to launched doa6 please help i have lastest version redelbe 

[vagonumero13]

8 hours ago, acuna43 said:

Vagunumero13

I have problem to launched doa6 please help i have lastest version redelbe 

 

Latest REDELBE only supports 1.17 and 1.16. You have a very old game version (1.08, from what I can tell from those .rdb.bin in the screenshot).

[Joschuka]

10 hours ago, vagonumero13 said:

 

I have soem doubts about the "next_header_offset". I think it may mean other thing. This is a dump of those three values in a DOA animation (spline_count, next_header_offset, data_offset): (btw, I had to change data type to unsigned int, or otherwise spline_count=2 would get the -2 value).

 

  Reveal hidden contents

2 0x4 0x0
2 0x8 0x160
1 0xc 0x300
1 0x10 0x530
1 0x14 0x810
1 0x18 0x9f0
1 0x1c 0xba0
1 0x20 0xef0
1 0x24 0x11d0
1 0x28 0x1340
1 0x2c 0x1530
1 0x30 0x1730
1 0x34 0x19d0
1 0x38 0x1bf0
1 0x3c 0x1e60
1 0x40 0x2320
1 0x44 0x2720
1 0x48 0x29b0
1 0x4c 0x2c50
1 0x50 0x31a0
2 0x54 0x3640
2 0x58 0x37e0
1 0x5c 0x3a30
1 0x60 0x3d40
1 0x64 0x3e00
1 0x78 0x3e30
1 0x7c 0x40f0
1 0x80 0x42f0
1 0x84 0x44f0
1 0x88 0x4710
1 0x8c 0x48b0
1 0x90 0x4ac0
1 0x94 0x4bf0
1 0x98 0x4cc0
1 0x9c 0x4db0
1 0xa0 0x4e50
1 0xa4 0x4f10
1 0xa8 0x5000
1 0xac 0x50e0
1 0xb0 0x51c0
1 0xb4 0x5280
1 0xb8 0x5390
1 0xbc 0x5460
1 0xc0 0x55d0
1 0xc4 0x5690
1 0xc8 0x57d0
1 0xcc 0x5900
1 0xd0 0x5a60
1 0xd4 0x5b70
1 0xd8 0x5cc0
1 0xdc 0x5e00
1 0xe0 0x5ee0
1 0xe4 0x6030
1 0xe8 0x6150
1 0xec 0x6280
1 0xf0 0x63a0
1 0xf4 0x64b0

 

 

The spline count is correct. The data offset is also correct (you have to divide that number by 4 to actually get the offset, though).

But the next header offset doesn't seem to match. Notice that at some point it goes from 0x64 to 0x78. And offsets like 0xe8-0xf4 would be out of range.

 

I think that number is actually that number / 4 (probably the bit field was incorrect), which causes the number to go in a sequence like: 1, 2, 3, 4, ... 61, where the range 25-29 was skipped for some reason.

Ah that's funny, on all the g2a files I checked it worked (I checked like 10). There were all G2A 0500 though, maybe your file was a g1a or a g2a 0300 and in these dividing by 4 is necessary ? We don't have those unfortunately in FETH so maybe our BT is innacurate for them, it was a bit of an over extension to assume it'd work for all animation versions.
That jump is interesting indeed, I didn't have anything like that in any of the g2a 0500 files I checked, the next offset header always matched. I'll double check though.

[vagonumero13]

25 minutes ago, Joschuka said:

Ah that's funny, on all the g2a files I checked it worked (I checked like 10). There were all G2A 0500 though, maybe your file was a g1a or a g2a 0300 and in these dividing by 4 is necessary ? We don't have those unfortunately in FETH so maybe our BT is innacurate for them, it was a bit of an over extension to assume it'd work for all animation versions.
That jump is interesting indeed, I didn't have anything like that in any of the g2a 0500 files I checked, the next offset header always matched. I'll double check though.

 

I confirmed by live debugging. The value is used as an index into this 16bit array:

 

Spoiler

 

As you see, after 0x19 (25), there are several -1 indexes, which is exactly the gap I noticed.

So at beginning, indexes would match the value in the array, but index 30 would get the value 26. And so, until index 61 (0x3D) would get value 57 (0x39). After that there is another gap, but all of my animations samples only have until index 61.

 

61 is the total number of animation steps, 57 the number of keyframes, cannot be a coincidence.

The array has actually 827 entries (the game compares the index to ensure it is lower than that), but I don't know from where the 827 was calculated or if it is fixed.

[vagonumero13]

Ok, I found out from where the gap is. The gap matches the gap in bones of characters. The list of basic body bones in a DOA6 character:

 

Spoiler

0,root
1,SK_Skeleton
2,SK_Hips
3,SK_L_UpLeg
4,SK_R_UpLeg
5,SK_L_Leg
6,SK_R_Leg
7,SK_L_Foot
8,SK_R_Foot
9,SK_Spine01
10,SK_Spine02
11,SK_Neck
12,SK_Head
13,SK_L_Shoulder
14,SK_R_Shoulder
15,SK_L_Arm
16,SK_R_Arm
17,SK_L_ForeArm
18,SK_R_ForeArm
19,SK_L_Hand
20,SK_R_Hand
21,SK_L_Weapon
22,SK_R_Weapon
23,SK_L_Toes
24,SK_R_Toes
25,SK_Endangle
30,SK_L_Thumb01
31,SK_R_Thumb01
32,SK_L_Index01
33,SK_R_Index01
34,SK_L_Middle01
35,SK_R_Middle01
36,SK_L_PinkySide
37,SK_R_PinkySide
38,SK_L_Thumb02
39,SK_R_Thumb02
40,SK_L_Index02
41,SK_R_Index02
42,SK_L_Middle02
43,SK_R_Middle02
44,SK_L_Ring01
45,SK_R_Ring01
46,SK_L_Pinky01
47,SK_R_Pinky01
48,SK_L_Thumb03
49,SK_R_Thumb03
50,SK_L_Index03
51,SK_R_Index03
52,SK_L_Middle03
53,SK_R_Middle03
54,SK_L_Ring02
55,SK_R_Ring02
56,SK_L_Pinky02
57,SK_R_Pinky02
58,SK_L_Ring03
59,SK_R_Ring03
60,SK_L_Pinky03
61,SK_R_Pinky03
65,RF_L_Arm_00
66,RF_R_Arm_00
67,RF_L_Arm_01
68,RF_R_Arm_01
69,RF_L_Arm_02
70,RF_R_Arm_02
71,RF_L_Elbow_00
72,RF_R_Elbow_00
73,RF_L_ForeArm_00
74,RF_R_ForeArm_00
75,RF_L_ForeArm_01
76,RF_R_ForeArm_01
77,RF_L_UpLeg_00
78,RF_R_UpLeg_00
79,RF_L_UpLeg_01
80,RF_R_UpLeg_01
81,RF_L_UpLeg_02
82,RF_R_UpLeg_02
83,RF_L_Knee_00
84,RF_R_Knee_00
85,RF_L_Leg_00
86,RF_R_Leg_00
87,RF_L_HipBack
88,RF_R_HipBack
89,RF_L_HipOutSide
90,RF_R_HipOutSide
91,RF_L_HipInSide
92,RF_R_HipInSide
120,F_Face
121,F_C_01
122,F_C_02
123,F_C_03
124,F_C_04
125,F_C_05
126,F_C_06
127,F_C_11
128,F_C_12
129,F_C_14
130,F_C_15
131,F_C_16
132,F_C_17
133,F_C_18
134,F_C_19
135,F_C_20
136,F_C_21
137,F_C_22
138,F_C_23
139,F_C_24
140,F_C_25
141,F_C_26
142,F_C_27
143,F_C_30
144,F_C_31
145,F_C_32
146,F_L_22a
147,F_L_22b
148,F_L_22c
149,F_L_23a
150,F_L_23b
151,F_L_23c
152,F_L_24a
153,F_L_24b
154,F_L_24c
155,F_L_25a
156,F_L_25b
157,F_L_25c
158,F_L_26a
159,F_L_26b
160,F_L_26c
161,F_L_26d
162,F_L_26e
163,F_L_26f
164,F_L_26g
165,F_L_27a
166,F_L_27b
167,F_L_27c
168,F_L_27d
169,F_L_27e
170,F_L_27f
171,F_R_22a
172,F_R_22b
173,F_R_22c
174,F_R_23a
175,F_R_23b
176,F_R_23c
177,F_R_24a
178,F_R_24b
179,F_R_24c
180,F_R_25a
181,F_R_25b
182,F_R_25c
183,F_R_26a
184,F_R_26b
185,F_R_26c
186,F_R_26d
187,F_R_26e
188,F_R_26f
189,F_R_26g
190,F_R_27a
191,F_R_27b
192,F_R_27c
193,F_R_27d
194,F_R_27e
195,F_R_27f
196,F_C_28
197,F_L_01a
198,F_L_01b
199,F_L_01c
200,F_L_01d
201,F_L_01e
202,F_L_01f
203,F_L_01g
204,F_L_01h
205,F_L_02a
206,F_L_02b
207,F_L_02c
208,F_L_02d
209,F_L_02e
210,F_L_02f
211,F_L_02g
212,F_L_02h
213,F_L_03a
214,F_L_03b
215,F_L_03c
216,F_L_03d
217,F_L_03e
218,F_L_03f
219,F_L_03g
220,F_L_03h
221,F_L_04a
222,F_L_04b
223,F_L_04c
224,F_L_04d
225,F_L_04e
226,F_L_04f
227,F_L_04g
228,F_L_04h
229,F_L_05a
230,F_L_05b
231,F_L_05c
232,F_L_05d
233,F_L_05e
234,F_L_05f
235,F_L_05g
236,F_L_05h
237,F_L_06a
238,F_L_06b
239,F_L_06c
240,F_L_06d
241,F_L_06e
242,F_L_06f
243,F_L_06g
244,F_L_06h
245,F_L_06i
246,F_L_07a
247,F_L_07b
248,F_L_07c
249,F_L_07d
250,F_L_07e
251,F_L_07f
252,F_L_07g
253,F_L_08a
254,F_L_08b
255,F_L_08c
256,F_L_09a
257,F_L_09b
258,F_L_09c
259,F_L_09d
260,F_L_10a
261,F_L_10b
262,F_L_10c
263,F_L_10d
264,F_L_10e
265,F_L_11a
266,F_L_11b
267,F_L_11c
268,F_L_11d
269,F_L_11e
270,F_L_11f
271,F_L_11g
272,F_L_12a
273,F_L_12b
274,F_L_12c
275,F_L_12d
276,F_L_12e
277,F_L_12f
278,F_L_12g
279,F_L_12h
280,F_L_13a
281,F_L_13b
282,F_L_13c
283,F_L_13d
284,F_L_14a
285,F_L_14b
286,F_L_14c
287,F_L_14d
288,F_L_14e
289,F_L_14f
290,F_L_14g
291,F_L_14h
292,F_L_14i
293,F_L_14j
294,F_L_15a
295,F_L_15b
296,F_L_15c
297,F_L_15d
298,F_L_15e
299,F_L_15f
300,F_L_15g
301,F_L_16a
302,F_L_16b
303,F_L_16c
304,F_L_16d
305,F_L_16e
306,F_L_16f
307,F_L_17a
308,F_L_17b
309,F_L_17c
310,F_L_17d
311,F_L_18a
312,F_L_18b
313,F_L_18c
314,F_L_19a
315,F_L_19b
316,F_L_19c
317,F_L_20a
318,F_L_20b
319,F_L_20c
320,F_L_20d
321,F_L_20e
322,F_L_20f
323,F_L_20g
324,F_L_20h
325,F_L_20i
326,F_L_20j
327,F_L_20k
328,F_L_20l
329,F_L_20m
330,F_L_28a
331,F_R_01a
332,F_R_01b
333,F_R_01c
334,F_R_01d
335,F_R_01e
336,F_R_01f
337,F_R_01g
338,F_R_01h
339,F_R_02a
340,F_R_02b
341,F_R_02c
342,F_R_02d
343,F_R_02e
344,F_R_02f
345,F_R_02g
346,F_R_02h
347,F_R_03a
348,F_R_03b
349,F_R_03c
350,F_R_03d
351,F_R_03e
352,F_R_03f
353,F_R_03g
354,F_R_03h
355,F_R_04a
356,F_R_04b
357,F_R_04c
358,F_R_04d
359,F_R_04e
360,F_R_04f
361,F_R_04g
362,F_R_04h
363,F_R_05a
364,F_R_05b
365,F_R_05c
366,F_R_05d
367,F_R_05e
368,F_R_05f
369,F_R_05g
370,F_R_05h
371,F_R_06a
372,F_R_06b
373,F_R_06c
374,F_R_06d
375,F_R_06e
376,F_R_06f
377,F_R_06g
378,F_R_06h
379,F_R_06i
380,F_R_07a
381,F_R_07b
382,F_R_07c
383,F_R_07d
384,F_R_07e
385,F_R_07f
386,F_R_07g
387,F_R_08a
388,F_R_08b
389,F_R_08c
390,F_R_09a
391,F_R_09b
392,F_R_09c
393,F_R_09d
394,F_R_10a
395,F_R_10b
396,F_R_10c
397,F_R_10d
398,F_R_10e
399,F_R_11a
400,F_R_11b
401,F_R_11c
402,F_R_11d
403,F_R_11e
404,F_R_11f
405,F_R_11g
406,F_R_12a
407,F_R_12b
408,F_R_12c
409,F_R_12d
410,F_R_12e
411,F_R_12f
412,F_R_12g
413,F_R_12h
414,F_R_13a
415,F_R_13b
416,F_R_13c
417,F_R_13d
418,F_R_14a
419,F_R_14b
420,F_R_14c
421,F_R_14d
422,F_R_14e
423,F_R_14f
424,F_R_14g
425,F_R_14h
426,F_R_14i
427,F_R_14j
428,F_R_15a
429,F_R_15b
430,F_R_15c
431,F_R_15d
432,F_R_15e
433,F_R_15f
434,F_R_15g
435,F_R_16a
436,F_R_16b
437,F_R_16c
438,F_R_16d
439,F_R_16e
440,F_R_16f
441,F_R_17a
442,F_R_17b
443,F_R_17c
444,F_R_17d
445,F_R_18a
446,F_R_18b
447,F_R_18c
448,F_R_19a
449,F_R_19b
450,F_R_19c
451,F_R_20a
452,F_R_20b
453,F_R_20c
454,F_R_20d
455,F_R_20e
456,F_R_20f
457,F_R_20g
458,F_R_20h
459,F_R_20i
460,F_R_20j
461,F_R_20k
462,F_R_20l
463,F_R_20m
464,F_R_28a
500,RF_L_ForeArmNoTwist
501,RF_R_ForeArmNoTwist
502,RF_L_HandNoTwist
503,RF_R_HandNoTwist
504,RF_L_ElbowNoTwist
505,RF_R_ElbowNoTwist
506,RF_L_LegNoTwist
507,RF_R_LegNoTwist
508,RF_L_KneeNoTwist
509,RF_R_KneeNoTwist
510,RF_L_F_ShoulderSeam
511,RF_R_F_ShoulderSeam
512,RF_L_B_ShoulderSeam
513,RF_R_B_ShoulderSeam
514,RF_L_U_ShoulderSeam
515,RF_R_U_ShoulderSeam
516,RF_L_D_ShoulderSeam
517,RF_R_D_ShoulderSeam
518,RF_L_F_U_ShoulderSeam
519,RF_R_F_U_ShoulderSeam
520,RF_L_F_D_ShoulderSeam
521,RF_R_F_D_ShoulderSeam
522,RF_L_B_U_ShoulderSeam
523,RF_R_B_U_ShoulderSeam
524,RF_L_B_D_ShoulderSeam
525,RF_R_B_D_ShoulderSeam
526,SK_INI_FrontSkirt_01
527,RF_FrontSkirt_01
528,SK_INI_FrontSkirt_02
529,RF_FrontSkirt_02
530,RF_B_Collar
531,RF_L_Collar
532,RF_R_Collar
533,RF_L_F_Collar
534,RF_R_F_Collar
535,SK_INI_B_Collar
536,SK_INI_L_Collar
537,SK_INI_R_Collar
538,SK_INI_L_F_Collar
539,SK_INI_R_F_Collar
540,SK_INI_L_FootAdjust
541,SK_INI_R_FootAdjust
542,SK_INI_L_ToesAdjust
543,SK_INI_R_ToesAdjust
544,RF_L_FootAdjust
545,RF_R_FootAdjust
546,RF_L_ToesAdjust
547,RF_R_ToesAdjust
550,CN_L_Contact01
551,CN_L_Contact02
552,CN_R_Contact01
553,CN_R_Contact02
555,SOFT000_ROOT
556,SOFT001_ROOT
557,SOFT002_ROOT
558,SOFT003_ROOT
559,SOFT004_ROOT
560,SOFT005_ROOT
561,SOFT006_ROOT
562,SOFT007_ROOT
565,OPT_ywrk_00
566,OPT_ywrk_01
567,OPT_ywrk_02
568,OPT_ywrk_03
569,OPT_ywrk_04
571,SK_INI_L_ShoulderArmor
572,SK_INI_R_ShoulderArmor
573,RF_L_ShoulderArmor
574,RF_R_ShoulderArmor
575,RF_L_F_ShoulderArmor
576,RF_R_F_ShoulderArmor
577,RF_L_B_ShoulderArmor
578,RF_R_B_ShoulderArmor
799,before_ponytail2_dummy

 

 

It has the same gaps, so that thing is a bone ID...

So, we got wrong a lot of things. If the bone is specified there, then that means that the thigns we thought were bones in sectinon 2, may actually be time stamps. The time stamps for that bone.

 

And that would explain a lot about some of my tests doing weird things, or why all animations looked like they had same number of keyframes regardless of their length, that was obviously bullshit.

It also exaplains why you or your friend though that the number of real frames was max bone ID: if the things we thought were bones ID are timesteamps specified as frames, it totally explains it.

[Joschuka]

14 minutes ago, vagonumero13 said:

Ok, I found out from where the gap is. The gap matches the gap in bones of characters. The list of basic body bones in a DOA6 character:

 

  Reveal hidden contents

0,root
1,SK_Skeleton
2,SK_Hips
3,SK_L_UpLeg
4,SK_R_UpLeg
5,SK_L_Leg
6,SK_R_Leg
7,SK_L_Foot
8,SK_R_Foot
9,SK_Spine01
10,SK_Spine02
11,SK_Neck
12,SK_Head
13,SK_L_Shoulder
14,SK_R_Shoulder
15,SK_L_Arm
16,SK_R_Arm
17,SK_L_ForeArm
18,SK_R_ForeArm
19,SK_L_Hand
20,SK_R_Hand
21,SK_L_Weapon
22,SK_R_Weapon
23,SK_L_Toes
24,SK_R_Toes
25,SK_Endangle
30,SK_L_Thumb01
31,SK_R_Thumb01
32,SK_L_Index01
33,SK_R_Index01
34,SK_L_Middle01
35,SK_R_Middle01
36,SK_L_PinkySide
37,SK_R_PinkySide
38,SK_L_Thumb02
39,SK_R_Thumb02
40,SK_L_Index02
41,SK_R_Index02
42,SK_L_Middle02
43,SK_R_Middle02
44,SK_L_Ring01
45,SK_R_Ring01
46,SK_L_Pinky01
47,SK_R_Pinky01
48,SK_L_Thumb03
49,SK_R_Thumb03
50,SK_L_Index03
51,SK_R_Index03
52,SK_L_Middle03
53,SK_R_Middle03
54,SK_L_Ring02
55,SK_R_Ring02
56,SK_L_Pinky02
57,SK_R_Pinky02
58,SK_L_Ring03
59,SK_R_Ring03
60,SK_L_Pinky03
61,SK_R_Pinky03
65,RF_L_Arm_00
66,RF_R_Arm_00
67,RF_L_Arm_01
68,RF_R_Arm_01
69,RF_L_Arm_02
70,RF_R_Arm_02
71,RF_L_Elbow_00
72,RF_R_Elbow_00
73,RF_L_ForeArm_00
74,RF_R_ForeArm_00
75,RF_L_ForeArm_01
76,RF_R_ForeArm_01
77,RF_L_UpLeg_00
78,RF_R_UpLeg_00
79,RF_L_UpLeg_01
80,RF_R_UpLeg_01
81,RF_L_UpLeg_02
82,RF_R_UpLeg_02
83,RF_L_Knee_00
84,RF_R_Knee_00
85,RF_L_Leg_00
86,RF_R_Leg_00
87,RF_L_HipBack
88,RF_R_HipBack
89,RF_L_HipOutSide
90,RF_R_HipOutSide
91,RF_L_HipInSide
92,RF_R_HipInSide
120,F_Face
121,F_C_01
122,F_C_02
123,F_C_03
124,F_C_04
125,F_C_05
126,F_C_06
127,F_C_11
128,F_C_12
129,F_C_14
130,F_C_15
131,F_C_16
132,F_C_17
133,F_C_18
134,F_C_19
135,F_C_20
136,F_C_21
137,F_C_22
138,F_C_23
139,F_C_24
140,F_C_25
141,F_C_26
142,F_C_27
143,F_C_30
144,F_C_31
145,F_C_32
146,F_L_22a
147,F_L_22b
148,F_L_22c
149,F_L_23a
150,F_L_23b
151,F_L_23c
152,F_L_24a
153,F_L_24b
154,F_L_24c
155,F_L_25a
156,F_L_25b
157,F_L_25c
158,F_L_26a
159,F_L_26b
160,F_L_26c
161,F_L_26d
162,F_L_26e
163,F_L_26f
164,F_L_26g
165,F_L_27a
166,F_L_27b
167,F_L_27c
168,F_L_27d
169,F_L_27e
170,F_L_27f
171,F_R_22a
172,F_R_22b
173,F_R_22c
174,F_R_23a
175,F_R_23b
176,F_R_23c
177,F_R_24a
178,F_R_24b
179,F_R_24c
180,F_R_25a
181,F_R_25b
182,F_R_25c
183,F_R_26a
184,F_R_26b
185,F_R_26c
186,F_R_26d
187,F_R_26e
188,F_R_26f
189,F_R_26g
190,F_R_27a
191,F_R_27b
192,F_R_27c
193,F_R_27d
194,F_R_27e
195,F_R_27f
196,F_C_28
197,F_L_01a
198,F_L_01b
199,F_L_01c
200,F_L_01d
201,F_L_01e
202,F_L_01f
203,F_L_01g
204,F_L_01h
205,F_L_02a
206,F_L_02b
207,F_L_02c
208,F_L_02d
209,F_L_02e
210,F_L_02f
211,F_L_02g
212,F_L_02h
213,F_L_03a
214,F_L_03b
215,F_L_03c
216,F_L_03d
217,F_L_03e
218,F_L_03f
219,F_L_03g
220,F_L_03h
221,F_L_04a
222,F_L_04b
223,F_L_04c
224,F_L_04d
225,F_L_04e
226,F_L_04f
227,F_L_04g
228,F_L_04h
229,F_L_05a
230,F_L_05b
231,F_L_05c
232,F_L_05d
233,F_L_05e
234,F_L_05f
235,F_L_05g
236,F_L_05h
237,F_L_06a
238,F_L_06b
239,F_L_06c
240,F_L_06d
241,F_L_06e
242,F_L_06f
243,F_L_06g
244,F_L_06h
245,F_L_06i
246,F_L_07a
247,F_L_07b
248,F_L_07c
249,F_L_07d
250,F_L_07e
251,F_L_07f
252,F_L_07g
253,F_L_08a
254,F_L_08b
255,F_L_08c
256,F_L_09a
257,F_L_09b
258,F_L_09c
259,F_L_09d
260,F_L_10a
261,F_L_10b
262,F_L_10c
263,F_L_10d
264,F_L_10e
265,F_L_11a
266,F_L_11b
267,F_L_11c
268,F_L_11d
269,F_L_11e
270,F_L_11f
271,F_L_11g
272,F_L_12a
273,F_L_12b
274,F_L_12c
275,F_L_12d
276,F_L_12e
277,F_L_12f
278,F_L_12g
279,F_L_12h
280,F_L_13a
281,F_L_13b
282,F_L_13c
283,F_L_13d
284,F_L_14a
285,F_L_14b
286,F_L_14c
287,F_L_14d
288,F_L_14e
289,F_L_14f
290,F_L_14g
291,F_L_14h
292,F_L_14i
293,F_L_14j
294,F_L_15a
295,F_L_15b
296,F_L_15c
297,F_L_15d
298,F_L_15e
299,F_L_15f
300,F_L_15g
301,F_L_16a
302,F_L_16b
303,F_L_16c
304,F_L_16d
305,F_L_16e
306,F_L_16f
307,F_L_17a
308,F_L_17b
309,F_L_17c
310,F_L_17d
311,F_L_18a
312,F_L_18b
313,F_L_18c
314,F_L_19a
315,F_L_19b
316,F_L_19c
317,F_L_20a
318,F_L_20b
319,F_L_20c
320,F_L_20d
321,F_L_20e
322,F_L_20f
323,F_L_20g
324,F_L_20h
325,F_L_20i
326,F_L_20j
327,F_L_20k
328,F_L_20l
329,F_L_20m
330,F_L_28a
331,F_R_01a
332,F_R_01b
333,F_R_01c
334,F_R_01d
335,F_R_01e
336,F_R_01f
337,F_R_01g
338,F_R_01h
339,F_R_02a
340,F_R_02b
341,F_R_02c
342,F_R_02d
343,F_R_02e
344,F_R_02f
345,F_R_02g
346,F_R_02h
347,F_R_03a
348,F_R_03b
349,F_R_03c
350,F_R_03d
351,F_R_03e
352,F_R_03f
353,F_R_03g
354,F_R_03h
355,F_R_04a
356,F_R_04b
357,F_R_04c
358,F_R_04d
359,F_R_04e
360,F_R_04f
361,F_R_04g
362,F_R_04h
363,F_R_05a
364,F_R_05b
365,F_R_05c
366,F_R_05d
367,F_R_05e
368,F_R_05f
369,F_R_05g
370,F_R_05h
371,F_R_06a
372,F_R_06b
373,F_R_06c
374,F_R_06d
375,F_R_06e
376,F_R_06f
377,F_R_06g
378,F_R_06h
379,F_R_06i
380,F_R_07a
381,F_R_07b
382,F_R_07c
383,F_R_07d
384,F_R_07e
385,F_R_07f
386,F_R_07g
387,F_R_08a
388,F_R_08b
389,F_R_08c
390,F_R_09a
391,F_R_09b
392,F_R_09c
393,F_R_09d
394,F_R_10a
395,F_R_10b
396,F_R_10c
397,F_R_10d
398,F_R_10e
399,F_R_11a
400,F_R_11b
401,F_R_11c
402,F_R_11d
403,F_R_11e
404,F_R_11f
405,F_R_11g
406,F_R_12a
407,F_R_12b
408,F_R_12c
409,F_R_12d
410,F_R_12e
411,F_R_12f
412,F_R_12g
413,F_R_12h
414,F_R_13a
415,F_R_13b
416,F_R_13c
417,F_R_13d
418,F_R_14a
419,F_R_14b
420,F_R_14c
421,F_R_14d
422,F_R_14e
423,F_R_14f
424,F_R_14g
425,F_R_14h
426,F_R_14i
427,F_R_14j
428,F_R_15a
429,F_R_15b
430,F_R_15c
431,F_R_15d
432,F_R_15e
433,F_R_15f
434,F_R_15g
435,F_R_16a
436,F_R_16b
437,F_R_16c
438,F_R_16d
439,F_R_16e
440,F_R_16f
441,F_R_17a
442,F_R_17b
443,F_R_17c
444,F_R_17d
445,F_R_18a
446,F_R_18b
447,F_R_18c
448,F_R_19a
449,F_R_19b
450,F_R_19c
451,F_R_20a
452,F_R_20b
453,F_R_20c
454,F_R_20d
455,F_R_20e
456,F_R_20f
457,F_R_20g
458,F_R_20h
459,F_R_20i
460,F_R_20j
461,F_R_20k
462,F_R_20l
463,F_R_20m
464,F_R_28a
500,RF_L_ForeArmNoTwist
501,RF_R_ForeArmNoTwist
502,RF_L_HandNoTwist
503,RF_R_HandNoTwist
504,RF_L_ElbowNoTwist
505,RF_R_ElbowNoTwist
506,RF_L_LegNoTwist
507,RF_R_LegNoTwist
508,RF_L_KneeNoTwist
509,RF_R_KneeNoTwist
510,RF_L_F_ShoulderSeam
511,RF_R_F_ShoulderSeam
512,RF_L_B_ShoulderSeam
513,RF_R_B_ShoulderSeam
514,RF_L_U_ShoulderSeam
515,RF_R_U_ShoulderSeam
516,RF_L_D_ShoulderSeam
517,RF_R_D_ShoulderSeam
518,RF_L_F_U_ShoulderSeam
519,RF_R_F_U_ShoulderSeam
520,RF_L_F_D_ShoulderSeam
521,RF_R_F_D_ShoulderSeam
522,RF_L_B_U_ShoulderSeam
523,RF_R_B_U_ShoulderSeam
524,RF_L_B_D_ShoulderSeam
525,RF_R_B_D_ShoulderSeam
526,SK_INI_FrontSkirt_01
527,RF_FrontSkirt_01
528,SK_INI_FrontSkirt_02
529,RF_FrontSkirt_02
530,RF_B_Collar
531,RF_L_Collar
532,RF_R_Collar
533,RF_L_F_Collar
534,RF_R_F_Collar
535,SK_INI_B_Collar
536,SK_INI_L_Collar
537,SK_INI_R_Collar
538,SK_INI_L_F_Collar
539,SK_INI_R_F_Collar
540,SK_INI_L_FootAdjust
541,SK_INI_R_FootAdjust
542,SK_INI_L_ToesAdjust
543,SK_INI_R_ToesAdjust
544,RF_L_FootAdjust
545,RF_R_FootAdjust
546,RF_L_ToesAdjust
547,RF_R_ToesAdjust
550,CN_L_Contact01
551,CN_L_Contact02
552,CN_R_Contact01
553,CN_R_Contact02
555,SOFT000_ROOT
556,SOFT001_ROOT
557,SOFT002_ROOT
558,SOFT003_ROOT
559,SOFT004_ROOT
560,SOFT005_ROOT
561,SOFT006_ROOT
562,SOFT007_ROOT
565,OPT_ywrk_00
566,OPT_ywrk_01
567,OPT_ywrk_02
568,OPT_ywrk_03
569,OPT_ywrk_04
571,SK_INI_L_ShoulderArmor
572,SK_INI_R_ShoulderArmor
573,RF_L_ShoulderArmor
574,RF_R_ShoulderArmor
575,RF_L_F_ShoulderArmor
576,RF_R_F_ShoulderArmor
577,RF_L_B_ShoulderArmor
578,RF_R_B_ShoulderArmor
799,before_ponytail2_dummy

 

 

It has the same gaps, so that thing is a bone ID...

So, we got wrong a lot of things. If the bone is specified there, then that means that the thigns we thought were bones in sectinon 2, may actually be time stamps. The time stamps for that bone.

 

And that would explain a lot about some of my tests doing weird things, or why all animations looked like they had same number of keyframes regardless of their length, that was obviously bullshit.

Omg, back to the drawing board I guess.

Wait you have some bone names in DOA6 ? Unless I missed something obvious they don't seem to be any in FE.

[vagonumero13]

5 minutes ago, Joschuka said:

Omg, back to the drawing board I guess.

Wait you have some bone names in DOA6 ? Unless I missed something obvious they don't seem to be any in FE.

 

The bone names were present only until 1.06 update. They were stored in separate file with .oid extension. Theere are now hashes only in the .oid file, but since I know the hashing algorithm, I can translate them back with string cracking. Anyway, I still got the old files that had these (in fact, qrdbtool can recover almost all old DOA6 files due to how packaging works in this game).

 

The bone names actually miss some specific bones, like bones >= 800, some of which are specific for soem characters or for some costumes.  But it looks like all animations are just using bone 1-61, so the basic of basic bones.

[Joschuka]

1 hour ago, vagonumero13 said:

 

The bone names were present only until 1.06 update. They were stored in separate file with .oid extension. Theere are now hashes only in the .oid file, but since I know the hashing algorithm, I can translate them back with string cracking. Anyway, I still got the old files that had these (in fact, qrdbtool can recover almost all old DOA6 files due to how packaging works in this game).

 

The bone names actually miss some specific bones, like bones >= 800, some of which are specific for soem characters or for some costumes.  But it looks like all animations are just using bone 1-61, so the basic of basic bones.

Ah ok I see.

 

Back to g2a it's beginning to make some sense :

-num_splines would actually be the number of channels for the bone (rotation, translation, scale etc)

-next_header_offset divided by 4 would be the bone ID

-data_offset is the offset of the timing info for the above bone, divided by 4 or not depending of the version it seems

 

section 2, what we called splines before:

-type : channel type

-bone_count : it's actually the number of keyframes in the channel for the bone

-first matrix is the one of the first keyframe, next ones being for the next keyframes

-the bone_ID would be the keyframes' values, in frames probably

 

section 3 would be the transform matrices according to your translation experiment.

 

Overall it'd make some sense, I'll update the BT

[vagonumero13]

7 hours ago, Joschuka said:

Ah ok I see.

 

Back to g2a it's beginning to make some sense :

-num_splines would actually be the number of channels for the bone (rotation, translation, scale etc)

-next_header_offset divided by 4 would be the bone ID

-data_offset is the offset of the timing info for the above bone, divided by 4 or not depending of the version it seems

 

section 2, what we called splines before:

-type : channel type

-bone_count : it's actually the number of keyframes in the channel for the bone

-first matrix is the one of the first keyframe, next ones being for the next keyframes

-the bone_ID would be the keyframes' values, in frames probably

 

section 3 would be the transform matrices according to your translation experiment.

 

Overall it'd make some sense, I'll update the BT

 

I have some doubts about the format of the matrix. There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, there is probably some hardcore optimization going on there, because the 32 bytes are loaded as 4 64 bits values), and it creates 3 float values from it. This function is called for the three opcodes 0, 1 and 2. But for opcode 0, those 3 values are then passed to a second function that transforms those 3 floats into 4 floats (maybe a quaternion).

[Joschuka]

15 hours ago, vagonumero13 said:

 

I have some doubts about the format of the matrix. There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, there is probably some hardcore optimization going on there, because the 32 bytes are loaded as 4 64 bits values), and it creates 3 float values from it. This function is called for the three opcodes 0, 1 and 2. But for opcode 0, those 3 values are then passed to a second function that transforms those 3 floats into 4 floats (maybe a quaternion).

That'd make sense, as I said above that was weird to store transform matrices which are supposed to be the result of all transform when they have explicit info on which transform is happening thanks to the opcode. So we'd have a quaternion for the rotation and a scale/translation vector for opcodes 2 and 1 respectively.

Ok that computation seems a bit weird indeed, Maybe they store some interpolation information info or something like that here too cause it doesn't to be anywhere else

Btw the 20 bits "bone_timing_data_offset" doesn't seem to match for Dissidia NT's g2a files so it may be something else. Everything else seem correct on these.

Could you share the code parts in PM please ? I'd like to take a look at them

[vagonumero13]

54 minutes ago, Joschuka said:

That'd make sense, as I said above that was weird to store transform matrices which are supposed to be the result of all transform when they have explicit info on which transform is happening thanks to the opcode. So we'd have a quaternion for the rotation and a scale/translation vector for opcodes 2 and 1 respectively.

Ok that computation seems a bit weird indeed, Maybe they store some interpolation information info or something like that here too cause it doesn't to be anywhere else

Btw the 20 bits "bone_timing_data_offset" doesn't seem to match for Dissidia NT's g2a files so it may be something else. Everything else seem correct on these.

Could you share the code parts in PM please ? I'd like to take a look at them

I haven't really written new code yet, I still have the old parse code, I need to correct it.

About the matrix, this is what I could gather after some look (some of it may be incorrect).

 

It is not a 4x4 matrix. It is a 4x3 matrix, or just 4 vectors of 3 components each one. They aren't in standard float formats.

Each vector is 64 bits, where each component has 20 bits.  The remaining bits (bits 59-63) seem to be a shared exponent for all the components (or something like that). That number is shifted << 23 (which matches float32 exponent) and added number 0x32000000 (which is float32 exponent 100). The 3 components are shifted 12 bits to the left.

 

Let's call each of these vectors X, Y, Z and W

The returned value is something more or less like this (this is where I may have some incorrect part).

 

returned X = X1 + Y1 + Z1 + W1

returned Y = X2 + Y2 + Z2 + W2

returned Z = X3 + Y3 + Z3 + W3

 

But well, there is more to this, the function that does these things is passed two additional parameters, both of which seem to be calculated from the frame timer (and maybe duration too, duration beign next frame timer - current frame timer), and number 65536.0 is used there, but I have to look better to that. The thing is that all returned values are actually multiplied with those values in different ways, so the above thing was just a simplification ignoring those parameters.

[Joschuka]

1 hour ago, vagonumero13 said:

I haven't really written new code yet, I still have the old parse code, I need to correct it.

About the matrix, this is what I could gather after some look (some of it may be incorrect).

 

It is not a 4x4 matrix. It is a 4x3 matrix, or just 4 vectors of 3 components each one. They aren't in standard float formats.

Each vector is 64 bits, where each component has 20 bits.  The remaining bits (bits 59-63) seem to be a shared exponent for all the components (or something like that). That number is shifted << 23 (which matches float32 exponent) and added number 0x32000000 (which is float32 exponent 100). The 3 components are shifted 12 bits to the left.

 

Let's call each of these vectors X, Y, Z and W

The returned value is something more or less like this (this is where I may have some incorrect part).

 

returned X = X1 + Y1 + Z1 + W1

returned Y = X2 + Y2 + Z2 + W2

returned Z = X3 + Y3 + Z3 + W3

 

But well, there is more to this, the function that does these things is passed two additional parameters, both of which seem to be calculated from the frame timer (and maybe duration too, duration beign next frame timer - current frame timer), and number 65536.0 is used there, but I have to look better to that. The thing is that all returned values are actually multiplied with those values in different ways, so the above thing was just a simplification ignoring those parameters.

Ah I was more talking aboout the code you referred to in that sentence " There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, ". I didn't start working on my G2A parser either, I will soon after cleaning my NUNO sections.

 

Great progress ! I'll update the BT accordingly soon.

About the 2nd function that would change 3 floats into 4 (for the rotation supposedly), my partner who worked on OW before saw something similar : https://github.com/overtools/OWLib/blob/develop/TankLib/teAnimation.cs#L234

[Boliu]

@vagonumero13 Hello, can you tell me what tools did you use to make stage mods?

[vagonumero13]

3 hours ago, Boliu said:

@vagonumero13 Hello, can you tell me what tools did you use to make stage mods?

There are no tools to create stage mods. All current stage mods consist in replacing the motor kidsobjdb of the stage with the one of another. This usually causes the stage to get some characteristics of that other stage, such as snow, day time, etc.

 

And then, there is the story mode stages mods, those just instruct REDELBE to make the game load those story mode stages.

[vagonumero13]

7 hours ago, Joschuka said:

Ah I was more talking aboout the code you referred to in that sentence " There is this function that operates all the values in the matrix (in a weird way, I can't even understand the code, ". I didn't start working on my G2A parser either, I will soon after cleaning my NUNO sections.

 

Great progress ! I'll update the BT accordingly soon.

About the 2nd function that would change 3 floats into 4 (for the rotation supposedly), my partner who worked on OW before saw something similar : https://github.com/overtools/OWLib/blob/develop/TankLib/teAnimation.cs#L234

 

Well, the function I talked about was a function in the game. It is this function (horrible IDA decompiled code right ahead):

Spoiler

signed __int64 __fastcall sub_140A605D0(__int64 a1, __int64 a2, float a3, float a4)
{
  __int64 v4; // r9@1
  float v5; // xmm2_4@1
  float v6; // xmm7_4@1
  float v7; // xmm1_4@1
  float v8; // xmm3_4@1
  float v9; // xmm5_4@1
  float v10; // xmm0_4@1
  float v11; // xmm1_4@1
  float v12; // xmm6_4@1
  float v13; // xmm5_4@1
  float v14; // xmm6_4@1
  signed __int64 result; // rax@1
  unsigned int v16; // ecx@1
  float v17; // [sp+40h] [bp+18h]@1
  float v18; // [sp+40h] [bp+18h]@1

  v4 = a1;
  LODWORD(v17) = ((*(_QWORD *)a2 >> 37) & 0x7800000) + 0x32000000;
  v5 = a3 / a4;
  v6 = (float)(v5 * v5) * v5;
  LODWORD(v7) = ((*(_QWORD *)(a2 + ? >> 37) & 0x7800000) + 0x32000000;
  v8 = (float)((float)(signed int)((*(_QWORD *)a2 >> 28) & 0xFFFFF000) * v17)
     + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + ? >> 28) & 0xFFFFF000) * v7) * v5);
  v9 = (float)((float)(signed int)((*(_QWORD *)a2 >> ? & 0xFFFFF000) * v17)
     + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + ? >> ? & 0xFFFFF000) * v7) * v5);
  v10 = (float)(signed int)(((unsigned int)*(_QWORD *)(a2 + ? << 12) & 0xFFFFF000) * v7;
  LODWORD(v11) = ((*(_QWORD *)(a2 + 0x10) >> 37) & 0x7800000) + 0x32000000;
  v12 = (float)((float)(signed int)(((unsigned int)*(_QWORD *)a2 << 12) & 0xFFFFF000) * v17) + (float)(v10 * v5);
  v13 = v9 + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x10) >> ? & 0xFFFFF000) * v11) * (float)(v5 * v5));
  LODWORD(v18) = ((*(_QWORD *)(a2 + 0x18) >> 37) & 0x7800000) + 0x32000000;
  v14 = v12
      + (float)((float)((float)(signed int)(((unsigned int)*(_QWORD *)(a2 + 0x10) << 12) & 0xFFFFF000) * v11)
              * (float)(v5 * v5));
  result = (*(_QWORD *)(a2 + 0x18) >> ? & 0xFFFFF000i64;
  v16 = ((unsigned int)*(_QWORD *)(a2 + 0x18) << 12) & 0xFFFFF000;
  *(float *)v4 = (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x18) >> 28) & 0xFFFFF000) * v18) * v6)
               + (float)(v8
                       + (float)((float)((float)(signed int)((*(_QWORD *)(a2 + 0x10) >> 28) & 0xFFFFF000) * v11)
                               * (float)(v5 * v5)));
  *(float *)(v4 + 4) = (float)((float)((float)(signed int)result * v18) * v6) + v13;
  *(float *)(v4 + ? = (float)((float)((float)(signed int)v16 * v18) * v6) + v14;
  return result;
}

 

Some tips to undersrand the code:

- The function is actually a void

- a1 is actually the "float *" where x, y and z are returned.

- a2 is what we thought it was a matrix. (type should be uint64_t *, or QWORD *).

- (x >> 37) & 0x7800000 -> is equivalent to getting bits 63-60 and shifting them << 23.

- (x >> 28) & 0xFFFFF000 -> is equivalent to getting bits 40-59 and shifting them << 12.

- (x >> 8 ) & 0xFFFFF000 -> is equivalent to getting bits 20-39 and shifting them << 12.

- (x << 12) & 0xFFFFF000 -> is equivalent to getting bits 0-19 and shifting them << 12.

 

I will do a proper manual decompilation of that functon to get more quality code.

 

In a "matrix" with following binary data:

 

Spoiler

01E1DF51582FFF3F993D200DFFFD4B00722BD0C800DBED0F77E6EF8AFF14F70F

 

The results were as following. The function is actually called N times, where N is the duration of the frame (e.g. next time stamp - current time stamp.) Current time stamp was 0, next time stamp was 18.

 

Spoiler

(0)  0.000000 1179648.000000 - -0.051025 88.319580 -1.937256
(1)  65536.000000 1179648.000000 - -0.018494 88.313286 -1.909507
(2)  131072.000000 1179648.000000 - 0.013091 88.307541 -1.879869
(3)  196608.000000 1179648.000000 - 0.043657 88.302269 -1.848546
(4)  262144.000000 1179648.000000 - 0.073134 88.297447 -1.815743
(5)  327680.000000 1179648.000000 - 0.101448 88.292976 -1.781667
(6)  393216.000000 1179648.000000 - 0.128529 88.288826 -1.746521
(7)  458752.000000 1179648.000000 - 0.154304 88.284927 -1.710512
(8)  524288.000000 1179648.000000 - 0.178703 88.281227 -1.673844
(9)  589824.000000 1179648.000000 - 0.201653 88.277649 -1.636723
(10)  655360.000000 1179648.000000 - 0.223082 88.274155 -1.599354
(11)  720896.000000 1179648.000000 - 0.242919 88.270676 -1.561942
(12)  786432.000000 1179648.000000 - 0.261093 88.267151 -1.524692
(13)  851968.000000 1179648.000000 - 0.277530 88.263535 -1.487810
(14)  917504.000000 1179648.000000 - 0.292161 88.259750 -1.451502
(15)  983040.000000 1179648.000000 - 0.304913 88.255753 -1.415971
(16)  1048576.000000 1179648.000000 - 0.315714 88.251472 -1.381424
(17)  1114112.000000 1179648.000000 - 0.324492 88.246864 -1.348066

 

The two float numbers at left are the parameters a3 and a4 (input). The 3 number at the right (after the -) are the returned x, y, z values.

It looks like the parameter a3 is just 65536.0*frame, and parameter a4 is the final time stamp (in this case 18*65536.0)

 

Btw, the example was of a translation.