Today's Top Tip: Workaround for buggy auto-weighting in Blender

If you're using auto-weighting in blender and you come across a complex mesh where it just isn't working - you probably have flipped normals.  Just tab into edit mode and W>flip.  If that doesn't work  my workaround was to build a much lower resolution mesh with nice clean topology for auto-weighting, then use this script which I quickly cobbled together to proximity copy weights.  It will copy all the weights from the source object to the target object, but be warned it will overwrite any existing vertex groups on the target, which you might be using for other non-binding related tasks.

One Almost Sleepless Night and a Mood Change Walk

Wow, that's pretty much the first full project I've run from start to end through the blender 2.5 pipeline.  Its not bugless yet, but its getting there.  Automerging keyframes still seems to have a few problems on the animation front, and I encountered one or two armature bugs along the way - all thankfully now fixed in the SVN builds.  Hair sim seems a little crazy at times - It was adding a humongous amount to my render times in the calculating vector pass (probably a bug?) and getting blender to render from the same particle cache which is on display in the viewport takes some persuading. Much fewer crashes than I was used to last time I tried to render a complex scene in 2.5 but I still had to do the late night babysitting to restart the render when I hit an occasional glitch.  Hopefully I'll get some time to do some bug reporting over the weekend.



Thanks to some help from Jahka on #blendercoders I've now fathomed what the cache buttons do and a few other options relating to hair dynamics:

Cache Step:  This affects how often results are saved and as a result the accuracy of the played back simulation cache/bake.  When you run a simulation each frame (and any subframe steps if you have them enabled) gets calculated, but if your cache step is set at 10 then only every tenth frame is actually saved for playback.

Quick Cache: With this on the cache step is used for the simulation.  If cache step is at 10 then only every 10th frame is simulated and only every tenth frame is saved.

Effectors and Hair Dynamics: If you have hair dynamics off then effectors (objects with force fields etc) get used to shape/twist/curve the hair in all sorts of interesting and exciting ways.  You can use empties with forces on (on the same layer) to fake the effect of the wind/follow-though etc or curve guides to change the hair style.  If you switch on hair dynamics suddenly all these forces have a different meaning.  They are now used to effect the dynamic simulation of the hair rather than to effect its grown shape.

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!