Slow Dog Walk - Animation Reference

I was struggling with a dog walk in my short so I thought it best to try to find some live action reference and rotoscope it.  When a dog walks slower its feet spend much more time on the ground than in the air, so the contact pose is not the same as the lift off pose as it might be in say a fast 9-frame stride cycle where both front feet might only be on the ground together for just one frame.

On a 15-frames/stride cycle it seems that both front feet are on the ground together for 3-5 frames, and both back feet are on the ground together for 5-7 frames.  In this way the feet spend roughly the same amount of time in the air if the dog is walking fast or slow (around 5-7 frames in the air).  When a walk slows up, the dog takes smaller steps and spends more time with its feet on the ground.  Hence...

F per stride	F on the ground	F in the air	F both feet on the ground
9	~4-5	~4-5	~1
12	~6-8	~5	~2 (front) ~3 (back)
15	~8-10	~5-7	3-5 (front) 5-7 (back)

If you leave the feet hanging round in the air too long the walk starts to look stiff, like the dog is stuffed and artificially held in pose.  Remember the dog 'weighs' something and it needs to drop that leg to support itself on.

Here's some rotoscoping I did on a 15 frames/stride cycle.  I then adapted the the walk to a 17 frames/stride cycle which divides up much easier for 2D animators who don't have the computer to in-between on 5ths and 3rds.

"Spiders"

For info on how the auto-walking, crowd simulation and 'scribbler' work see my notes on scribd http://www.scribd.com/doc/47412229/Crowd-Simulation-and-Auto-Walking-Algorithms

A crash test dummy for my work in progress collection of scripts for auto-walking and flock simulation in blender. The crowd simulation system used for these was programmed from the ground up in python (not using blender's built in boids), as was the auto-walker (though I took a glance at the old 2.4x insect walker but decided to go down a different route for more flexibility with different numbers of legs etc.)

I also coded the 'scribbler' and the motion trails in python (thanks to this unofficial port of Python Image Library to Python3 which enabled me to use PIL inside blender to read pixels). Inspiration for the scribbler's algorithm comes in parts from mr doob's harmony​ and zefrank's original scribbler.

The sound is a combination of my own python code (sampling differentiated fcurve data in blender) and audiopaint.

I also had a bit of time to type up some notes on the 'Mushroomer' Algorithm as well based on some work I presented at the blender conference with the rest of the 'tube' project team: http://www.scribd.com/doc/47412460/Mushroomer-for-Blender-2-5-Algorithm-Description

Success at Last

First efforts to combine the data generated by my boids simulator with my auto-walking algorithm were fraught with difficulty.  'Noisy' fcurves had loads of jitter on them due to some of the fuzzy approximation methods used by the boids sim to keep the simulations fast.  Added to this as I was doing much of the calculations for the boids rotations using matrices or quaternions rather than Eulers, rotations would often flip from +/- 360 to 0 and back again.  I wrote a quick 'filter and smooth' script which effectively corrects Euler flips and blurs the data generated by the sim to allow the walking algorithm to produce more regular leg movement.



Here's the first crash test dummy... not particularly exciting but at least it works now!  Running is yet to be implemented and the walking algorithm falls apart if the distance the boid has to move in any given frame step is too large.  Writing sub-frame steps would easily correct this however and would probably be faster than any more intelligent algorithms.

Stay tuned for more demos and hopefully in the near future some source code for you to disect.

Leg Sequencing for the Auto-Walker

I've successfully implemented leg sequencing for the auto-walker I'm working on for the 'tube' project.  Its not a 'strict' method like many other auto-walkers use.  The legs can drift in and out of sequence if the bug turns a corner or so on, but the algorithm will then speed up or slow down each leg to reach the desired leg sequence order.

Hopefully by the end of the week I'll have stable enough source to release it!

Progress on the auto-walker

I spent most of yesterday just hitting dead ends.  My code became far too complex and it was almost impossible to find bugs.  I went for a full re-factor of the walking algorithm and now I'm getting much smoother motion.  It takes a few frames of pre-roll to get the legs in order - notice some jittering in the first second or so as legs are hurriedly placed to stabilise the bug.  By stabilisation I mean that if all the legs on one side of the bug (or in any given 'leg group' set by the user) become lifted then the algorithm will hurriedly place the leg which has been airborne the longest to keep the bug upright.  Still no body motion, but I've made a preliminary start on leg sequencing.

Autowalker Coding

Started work on coding the autowalker today... It's been harder than I expected!  Here's a first attempt without any kind of body movement.



All the extra bones (used for configuring the step size etc) get rather confusing in this quick video, but rest assured the feet are actually sticking to the ground.  Coding body movement comes next, then sorting out leg sequencing and step rates rather than the haptic steps that happen here!

Hopefully before long I'll get a chance to implement this with the boids sim.  Had a few helpful comments from Bassam on new features he'd like to see implemented, most of which require random movement which is not jitter - I'll need a time stable noise function to produce wavy paths rather than jittery ones... not too dissimilar to the noise modifier for fcurves.  Other features missing are the standard boid idle/rest states and a special option to 'playback' custom loops such as eating etc.