Kion
DashGL
- Joined
- Oct 11, 2018
- Location
- dashgl.com
I had to admit that I'm definitely surprised to see the game go from the leg sticking out behind the player, to an animated walk cycle on a single leg. I went ahead ahead and passed the parameter into my parser to less than effective results. So let's go ahead and grab more data. The best way to do this is to probably disable each axis to test by adding one animation to see what the effect of each axis is.
That means that we will test x, xy and xyz. Admittedly it would be better to test x, y, z as each axis separately, but that would require a script to rewrite the order of the animation. To be lazy we'll do this by adding in one axis at a time. We're working with the fourth instruction which is 0x11c0. This is node id 8, which right now I think is attached to bone 33 in the mt5 rig. The instruction will have 3 bits for x, y and z. The bit for x is 0x100, the bit for y should be 0x80, and the bit for z is 0x40.
This means that to test only x we want to replace this instruction with 0x1100. To test xy we will replace the instruction with 0x1180, and then we already have the effect of xyz, which is the original value. Time to pull up the emulator and see how horribly this turns out.
Can't say I was expecting this. When we replace 0x11c0 with 0x1100 (and then 0x0000 in the the following instruction), we get the surprising result that this causes Ryo to pump his leg up and down. So we have the surprising result that the X axis is actually the Y axis. We can go ahead and pin that to the the wall of surprises. Let's go ahead and see what the next axis has in store for us.
Just when I think i've had enough crazy pills they just keep coming. Replacing 0x11c0 with 0x1180 showed no change from the previous animation. But this should provide us with a little of context with how the animation works. This could indicate that the x and y axis are swapped for the non-root position key values. Shenmue uses a pretty standard coordinate system. The z-axis is front to back with -z being the direction Ryo moves forward. The X axis is the direction to the left and right of his body, so it looks like the feet don't have any translation in that direction.
The keyframes should be in YXZ order, and then only Y and Z axis should have any values. We can go back and check the values we read from the MOTN file to confirm if this is what we see.
That means that we will test x, xy and xyz. Admittedly it would be better to test x, y, z as each axis separately, but that would require a script to rewrite the order of the animation. To be lazy we'll do this by adding in one axis at a time. We're working with the fourth instruction which is 0x11c0. This is node id 8, which right now I think is attached to bone 33 in the mt5 rig. The instruction will have 3 bits for x, y and z. The bit for x is 0x100, the bit for y should be 0x80, and the bit for z is 0x40.
This means that to test only x we want to replace this instruction with 0x1100. To test xy we will replace the instruction with 0x1180, and then we already have the effect of xyz, which is the original value. Time to pull up the emulator and see how horribly this turns out.
Can't say I was expecting this. When we replace 0x11c0 with 0x1100 (and then 0x0000 in the the following instruction), we get the surprising result that this causes Ryo to pump his leg up and down. So we have the surprising result that the X axis is actually the Y axis. We can go ahead and pin that to the the wall of surprises. Let's go ahead and see what the next axis has in store for us.
Just when I think i've had enough crazy pills they just keep coming. Replacing 0x11c0 with 0x1180 showed no change from the previous animation. But this should provide us with a little of context with how the animation works. This could indicate that the x and y axis are swapped for the non-root position key values. Shenmue uses a pretty standard coordinate system. The z-axis is front to back with -z being the direction Ryo moves forward. The X axis is the direction to the left and right of his body, so it looks like the feet don't have any translation in that direction.
The keyframes should be in YXZ order, and then only Y and Z axis should have any values. We can go back and check the values we read from the MOTN file to confirm if this is what we see.
Last edited: