IKBoneID.FootIKTarget_L @ 956898
Pos X:
Frame: 0 @956898
Val: 0xAE7F / -0.10150146484375 @[956902 / 0xE99E6]
----------------------------------------------------------
[1] - 0x149C5AE80+0xE99E6 // 0x7FF7FEB64866
read bp set here
[2] read with `setNewMOTNData()`
read bytes are written to 0xFEF41AF668
[3] value is now being expanded from f16 to f32 (`convertFourHalfFloatsToFloat`)
[4] value now has some time/interpolation related ops done on it and then written to a new space in memory (`readAndConvertPositionMOTNData`)
the new value (`0.10157251`) has now been used in the construction of a Vector3 (potentially Vector4), which is stored at 0x7FF7FE9AEE50
[5] the Vector3
is then translated
with the current transform matrix:
Vector3 still stored @ 0x7FF7FE9AEE50
kind of supplementary to the next point I make, here is the callee of
translateWrapper
:
I think this is simply creating a worldspace vector3 out of the previously created vector3.
[6]
the data around here, which I have made structures of (in which the one we're tracing is named
tmpStr
), represents the whole node structure and basically consists of offsets into the MOTN data itself, the expanded keyframe values and some other variables like node etc
[7] Setting a new breakpoint on the newly translated
vec3
leads us to a known foot planting function.
This is pretty interesting as usually IK systems do foot planting after the usual animation system does its solving for the skeleton itself, for clarity, here is the foot planting function:
I've purposely clipped this rather short, as I've already done a lot of research on this function, including completely removing it and all animations still appear correctly, except Ryo no longer plants his feet on the ground:
I also tested this by removing the function from the executable before starting it and all of the results were the same, but for presentation purposes, I used Cheat Engine to make this change at runtime. It's important to note that from here on I simply make use of the
disableFootPlanting
offset shown in the screenshot to stop this function from reading any keyframe values.
So we'll skip this and move on.
[8] Now the game is reading the vector3 from this function:
Here, some pretty interesting stuff is happening.. the keyframe values
keyframe->vec3
are now being used to create some rotations for the active node/bone.. this is 100% animation IK-related.
Stepping outside of this function, and applying some research, gives the following picture of everything:
This function calls
MOTN::IKSolver
4 times and it seems to be arbitrarily transforming multiple nodes.