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.

Boid Brain Implementation

After spending two weeks working on LESS THAN THREE, then taking a few days off, I'm now back at work again continuing my efforts to code a new in-house boids system for the tube project in Python.  This will all be open sourced in due course once I've tidied up the code.

I spent a day or so bug-fixing and clearing out some redundant defs, then I implemented a 'flock metrics' system.  Rather than considering the entire collection of boids to be the flock (as the built in boids system does), in my boids system the flock is defined as all boids within a certain radius (the 'sight distance') making computations much faster (and more realistic for ground based creatures).  Each boid needs to know a set of statistics ('flock metrics') about the flock before it can make a decision on what to do (in the 'boid brain').  It needs to know how dense the flock is, how many boids are in the flock, where the centre of the flock is, who its closest neighbour is, and what the rate of change of all of these factors is.

For example if the flock is very dense but it is becoming less dense then the boid can stop panicking.  If the flock is not dense but it is increasing in density the boid may wish to align its direction vector with other boids in the flock so as not to cause collisions.  If the flock becomes severely dispersed a boid may wish to head for the centre of the flock for protection and so on.  This decision making is called 'emotion modulation'.  The boid considers the flock metrics and makes decisions about what to do automatically.  Emotions such as panic can change very quickly when a boid becomes blocked in by its neighbours (this is called ' high volatility' in the boid script) whereas emotions such as centring (heading for the flock centre) may need more gradual adjustments (low volatility) as boids slowly notice they have been left behind.



The next step is to allow the user to control emotions with 'emotion effectors' in the same way the boids can be physically directed with 'direction effectors' (shown in the above video).  The emotions implemented in the above video are panic, sleep, herd (copy neighbours directions/alignment), centre (head for the centre of the flock - traditional boid/shoal/flocking behaviour) and cluster (approach but keep a safe distance from closest neighbour).  The last emotion left to implement is not so much an emotion but a signal to other boids which is repel/attract (a boid can signal other boids to move closer or further away).

As you can see in the above video there is still a slight issue with collision stickiness which needs to be solved.

Fingers crossed I'll be able to start work on the autowalker pretty soon.

LESS THAN THREE

LESS THAN THREE is for Rhiannon, Who has never thrown a snowball at me! (and took kindly to being portrayed as a rather rotund 'Christmas Pudding' eskimo)

Two weeks start to finish in Blender 2.5.  Animating took just over 4 days.  I felt like I was on a bit of a haptic path trying to get this finished... the characters probably are as well!  I watched a lot of Ivor Wood stop motion before starting the animating and tried out (and broke) every gag in the book.  I manage to re-target my 'disco guy' rig fairly successfully but uncovered a new problem (this time with the eye tracking).  One of my big aims was to get smooth motion without falling back on the crutch of motion blur (which I used in only one shot - the flying snowball) and to compose strongly enough and texture well enough so I wouldn't need depth of field to hide the mistakes (used only in one shot where I went for a slight dutch angle and the dropped camera look).

Thanks to my little brother George the ad-hoc stuntman who happily dressed up in 20 T-shirts, jumpers and hoodies, multiple tracksuits, scarves, hats and a balaclava and stumbled round the garden like a padded eskimo while I threw snowballs and a giant physio ball at him for reference footage.  I re-timed a lot of the reference in After Effects for comic effect and over exaggerated the poses in the animation stage.

Thanks also to all the freesound.org users whose clips were used, and to archive.org for providing the Public Domain Songs Ragtimers' "Shimmy Like My Sister Kate" and Johnny Johnson's "Raggedy Ann" from Stepping Stones.

Batch Texture Processing: GIMP and IrfanView
Texture Painting: Photoshop
Bump and Normal Maps: SSBump
Modelling Shading Animation Rendering Compositing: Blender 2.5
Skating Tracks: Jahka's Animated Texture Bake
Final Grade, Animated Textures and Reference Processing: After Effects
Edit: Premiere Pro
Sound: Reaper

Smooth Vertex Group Weights in Python

I had to do some weight painting this morning in blender (for masking displacement textures and wave modifiers, not skinning bones for once!) and was faced with the usual problem of having to smooth out vertex group weights.  It struck me that I was painting all the way along one of my edge loops, and instead of laboriously going up and down the edge loop with the blur brush trying ever so hard not to paint bits of mesh in the background, I could select those edge loops quickly and easily in edit mode and write an operator to smooth out the weights of the active vertex group.

Before and After

I've bundled this into the tube project's 'Edge Tools' which I wrote back in the summer.  The latest release is available here: http://www.pasteall.org/17726/python just copy and paste into a text file and run from the script editor or save it as a .py and install from the add-ons menu.  Its in the Ctrl-V menu or Spacebar>Smooth Vertex...