"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!

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.

Controllers Implemented in Pythonic Boids for Blender

While college was on I hardly had any time at all to work on this.  I found a spare three hours this morning and implemented 'controllers'.  Currently you can instruct the boids to follow or to be attracted/repelled/directed by controllers.  I also implemented a way of detecting the orientation of the ground plane from the cross product of the last two direction vectors (with necessary error checking, direction flipping etc) and replaced all of the orientation interpolation code with quaternion slerp.  This will obviously need some more careful coding to make sure that the boids don't suffer from quaternion flip - hopefully I can get the smooth interpolations of quats with the twistability of eulers (i.e. >360 degree angles).



I've also been messing with low-poly stuff seeing as that seems to be in vogue this year what with 'Between Bears' rocketing up the vimeo charts.  After walking in the woods this evening in low light I was trying to work out how to get the sense of a curved ground plane from only the striation of the tree trunks.  Kept running into anti-aliasing issues though - the opposite type from usual - smooth fades from black to white wasn't quite what I had in mind.

 

Boundaries for Python Boids and Using the NLA for Animation Layers

Thanks to Campbell's bug fix for the shrinkwrap constraint, my python coded boids (not blender's built in types) can now stay constrained to a surface, albeit very slowly.  The execution of my python code is pretty rapid, considering the number of adjacencies which need to be taken into account, and I have some tidy ups planned which should make it even faster.  The downside is that I need the code to know the visual location (not actual location) of each boid after shrinkwrapping, and then apply this to the actual location.  Logically if I did object.location=object.matrix_world.copy().translation_part() you would expect this to update the visual location.  However it seems that (somewhat sensibly) blender doesn't always update constraints after every line of python which could make the visual location of an object differ from its actual location.  Trying to tell blender to update the world matrix to reflect changes in the object's location seems to be the main problem, especially when the object has keys (so just setting the current frame won't work).  The best option seems to be to key the location (and oddly enough using object.keyframe_insert('location') doesn't update the matrix, but ops.anim.keyframe_insert(....) does, but is much much slower) then read back the matrix.  This unfortunately is extremely slow, but does seem to work.

UPDATE: documented a workaround inspired by some of Bassam's suggestions.

Some python work which on the other hand has been more successful is a workaround to use NLA strips as animation layers (in the same way they would work in maya).  To use the script key the base animation in and then snowflake the action in the NLA window.  Then add a new NLA strip on a higher layer and set the mode to additive (to do this you'll probably have to create an action with a garbage key which you can later delete, link the action to the object then snowflake it).  Set your new top layer NLA strip to add mode then tab into it (tweak mode as its now called).  Start posing and whenever you want to insert a key use this script http://www.pasteall.org/16791/python instead of the 'I' key.  This makes sure that the new keys are relative to the layer below.  In good news aligorith confirmed that this behaviour will soon be built into blender and you won't need my script for much longer!

Python Boids in 3D

I'd only tested my code out in 2D up till now, even though I'd been coding all the vector maths in a way I hoped would work in 3D.  I ran a simulation above and to my pleasant surprise it worked perfectly first time.  Sadly trying to shrinkwrap/constrain the boids to a surface (a mesh marking the limits of where they are allowed to wander) I ran into a new bug in blender.  Its in the tracker, fingers crossed that by the next time I have a moment to work on the code all will be resolved!

Escape Route Searching in Python Boids

Yey! after some more coding this morning I got escape route searching working.  In this example the boids just give up when they collide as there are no controllers (or boid brains) yet to tell them to do anything other than that.

Boids in Python

Coding boids in blender's python API might seem like a lot of unnecessary work, but when the built in simulation system doesn't offer quite the options you need there really isn't much choice!  At least there's the hope that the python prototyping I'm doing might inspire a competent coder to leap to the mantle and take on the hard work.  Boids generally work in 3D space without stable collisions and don't have the ability to be constrained to a surface/mesh (ie a mesh offset from the ground plane which represents the translational limits of say their torso/root bone).  On the tube project we'll soon be starting work on a scene which requires a large scale crowd simulation.  Over the last 4 days I've put down the foundations of an almost-stable collisions system in python with some basic flock awareness.  More importantly I've implemented some important optimisations which make slow python less painful than it otherwise would be.  Black specks on a grey background might look pretty boring, but this is a big milestone (almost) successfully reached in implementing my half typed up design docs!