12-26-2024, 07:48 AM
I managed to fit the data for the first time by reading num_joints + 2 pieces of information, in the following order. Here, num_joints is 2, so the total number of data read is 4.
First 4 floats are the x translation, then 4 y translation, then 4 z translation, values: [0,0,0,0]; [0,0.01,0,0]; [0,0,0,0]; I guess ozz-animation is Y-up and not Z-up, like blender.
Then come rotations: 4 floats for x, 4*y, 4*z and 4*w rotations [0,0,0,0]; [0,0,0,0]; [0,0,0,0]; [1,1,1,1]; Everything as expected for a "no rotation" quaternion
Then come the scales: 4*x, 4*y, 4*z, with the values [100,1,1,1]; [100,1,1,1]; [100,1,1,1];
So this is my guess: the first value is the value of the armature itself: Location 0,0,0; rotation 0,0,0,1; scale 100,100,100;
Second value is the base of the first bone (in its parent's coordinates): Location (or length? displacement?) 0,0.01,0; rotation 0,0,0,1; scale 1,1,1; Where the location 0.01 in its parent's coordinates get converted to 1 due to the parent's scaling.
Third value is the base of the second bone, its rotation and scale. It's a 0-length bone so all its coordinates are 0.
The 4th value might be ozz animation's own "leaf bone marker" or something, another 0-length bone attached to the 0-length bone that blender added.
This is definitely not the finalized file format spec, but it's the first time I've managed to read the correct amount of data and make it fit the values they should be
First 4 floats are the x translation, then 4 y translation, then 4 z translation, values: [0,0,0,0]; [0,0.01,0,0]; [0,0,0,0]; I guess ozz-animation is Y-up and not Z-up, like blender.
Then come rotations: 4 floats for x, 4*y, 4*z and 4*w rotations [0,0,0,0]; [0,0,0,0]; [0,0,0,0]; [1,1,1,1]; Everything as expected for a "no rotation" quaternion
Then come the scales: 4*x, 4*y, 4*z, with the values [100,1,1,1]; [100,1,1,1]; [100,1,1,1];
So this is my guess: the first value is the value of the armature itself: Location 0,0,0; rotation 0,0,0,1; scale 100,100,100;
Second value is the base of the first bone (in its parent's coordinates): Location (or length? displacement?) 0,0.01,0; rotation 0,0,0,1; scale 1,1,1; Where the location 0.01 in its parent's coordinates get converted to 1 due to the parent's scaling.
Third value is the base of the second bone, its rotation and scale. It's a 0-length bone so all its coordinates are 0.
The 4th value might be ozz animation's own "leaf bone marker" or something, another 0-length bone attached to the 0-length bone that blender added.
This is definitely not the finalized file format spec, but it's the first time I've managed to read the correct amount of data and make it fit the values they should be