My younger brother (age 10) has recently started learning to play Bach’s Prelude No.1 on the piano. I asked him to follow a simple set of instructions, an algorithm of sorts, to investigate how, as a relatively naive musician, he interpreted the music:
Taking each note in turn:
listen to the note and the note that immediately preceeds it.
draw a pictogram which expresses how you feel regarding the preceeding note.
on the same piece of paper draw another pictogram relative to the first one, expressing the relative diference between the two notes.
shape the ball of plasticine provided and place in on the grid in a way that expresses how you feel regarding the pair of notes.
repeat
Again, check out the scribd link for the accompanying analysis- if you want a higher quality copy of the pdf for any reason give me a shout and I'll yousendit.
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.)
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.
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!
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.
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.
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.
