I am working on a new script called RE:Pose. It is an attempt to make a Poser like Walk Designer in Blender. I have the basic interface in place, which is flexible enough to adapt to a variety of IK based rigs. I also have some math in place to make the rig’s arms, foot and hip move. But what I don’t have is the math to make it look right. I am wondering if anyone has any time to look at the attached file and check my math? I have highlighted the math code in the text editor all updates take place inside of updatePose.
The test RIG in this attached file is Skinny Character from Blendswap by Chagas1983.
Download the BLEND file, open it up in Blender 2.6.3 or better and press play to see Skinny Guy do a funny walk.
NOTE: Influence sliders have no effect yet.
26_repose_RIG_skinny character_1b.blend (372 KB)
I was walking down the street to pick up a sub at the local pizza joint when I observed a person walking. It occurred to me that foot steps are really just traveling along the perimeter of a semi-circle with the flat side of the semi-circle representing the ground plane. With that in mind I thought all I need to do is to calculate the points of a circle with the x-radius being the stride length and the y-radius being the leg lift, using the current frame as the angle.
This new version of the BLEND is an attempt at that.
@test-dr: I have looked at the McHammond’s ant move and your BiPed script. I notice in your BiPed script you are animating the influence of constraints. My approach is to animate the pose bones directly with the hope this will make it more compatible with a large number of rigs via direct bone name mapping.
I feel like I am close with this new version, however, I am not able to completely get the clipping rotation for the semi-circle right. I have enabled the influence sliders in this version. So, when this is complete, you will be able to auto-walk then animate the influence from 1.0 to 0.0 to cause the feet, arms, or hips to stop. Or add a noise modifier to the Influence sliders to have a less robotic walk.
Once again I have highlighted the code in question in the text editor.
26_repose_RIG_skinny character_1d.blend (373 KB)
@atom: no, this is wrong. What you did see about “animating the influence of bone-constraints” is only the way to adjust the bones and keep the location like glued to the ground. If you ever did look about the part to animate the arms, those are “only swinging” … or the pelvis bone (or head-bone) etc. those are animated not with such constraints.
The constraints for the feet are only one way to have the feet not slipping on the ground and its an easy way to get the feet to the ground on “rough” (no plane) surfaces.
For example the pelvis movement uses a curve (visible curve in the constraint driver) thats a kind of wave(sinus)-curve and the movement is taken from the repeated walk-movement(time-value transformed to the cyclic movement 0->2pi.
Instead of using such a driver-curve, its possible to have the thing as a single math-function, but for the setup and changes - special if it comes to do a switch from walk to run and back - its more easy to switch the usages of a curve-part than to do the calculation (and create a math-function for the new curve-settings).
For walking one could do a total math-expression like this (i did note at one of my postings this kind)
btw. i dont know if for newer blender-version(like 2.63) its not necessary to use an empty to adjust the foot-location to the ground and do the setting inside of the armature (in older versions this did break – even crash blender – and could not be used with multiple armatures animated at the same time).
I have visited biomotionlabs. I would love to peek inside the SWF to see how they did that. That is my goal, a total math solution, but I am math challenged and may have bitten off more than I can chew.
I just did a multiple armature test with 2.6.3 and indeed there are bugs. I thought because the pose was at the object level I could share the same armature data (like I have done in the past with mesh data) and simply change the poses for each object. While the developers have intended for poses to operate independently of the armature data, it does not seem to work that way in my experience. Perhaps it is just a problem with this test rig.
I got a little further. I realized that most people don’t walk with a perfect semi-circle. So instead of just scaling by 1.0 when the foot is off the ground plane I calculate the percentage through the step and use that as a scale for the semi-circle. This produces a tear drop shape instead of a semi-circle. So the leg lifts higher at the beginning of the step and drops off as the step completes. This looks a little bit more natural.
I feel like this is really close to my goal, however, for some reason the left leg steps higher than the right leg and I can not figure out why…? I am wondering if it might be in the rig itself?
Here is another update to the RE:Pose autowalk script.
Because I have not made much progress in solving this as a math problem, it finally occurred to me “Why not just abandon the mathematical solution and just use sampled data?” This revision implements that concept. In the attached BLEND file there is a companion script that will sample a RIG’s pose bones and generate an array of Vector and Quaternion values. I sampled one of the Sintel background character’s walk-in-place rigs to obtain the foot movements and installed that data into the RE:Pose script. Because I already had a working percentage through step I simply use that percentage to choose a sampled value. This is actually faster at the code level because all those multiplies, divides, sin and cos lookups are no longer calculated for the feet.