In the second part of the book, the focus is all on animation, starting with a simple ball exercise, and rapidly ramping up into character animation. The first chapter is mainly technical (like the rigging section) in it’s setup: that is, he starts with workflow, then with things like IK/FK switching, etc. This book introduces workflow and technique first, so the focus at start is learning animation in blender, not learning animation in general yet. This chapter is basically an introduction to blender for animators, and I think maya or even 2D animators picking up Blender will spend most of their time here.

After the technically-heavy blender intro, the rest of the animation chapters return to the basics a bit, with lessons in timing, spacing, anticipation, squash and stretch, etc… All those basic animation principles we know and love. The book is good at using blender features to enable animators to get what they need done efficiently, using Blender’s path-drawing features to adjust their arcs, or using the Open GL preview to better see their timing.  As in the rigging sections, the downloads for the book contain Blend files that make it easy for students to get right in with each chapter working on the exercises with no fuss.

The book ends with an appendix with some useful tips on planning, organisation, and terms.

Some criticisms: Even in a good book such as this, I can find some things to crit , but they are mainly small things. In the rigging section, Virgilio fails to warn his audience about the (current) fragility of one setup, when talking about the corrective shapes (an otherwise excellent segment). Luckily, a current summer of code project fixes this problem, so it’s likely that any such warning will be unneeded in the next release of Blender! Another tiny nitpick is that Virgilio uses the term spacing in two different ways, the first time unconventionally (referring to actual physical locations) the second more like the usual way for animators. I feel that he could have picked a better word for the first time. Finally, in the rigging section, I think that a tiny introduction to Python for creating interfaces would be quite good, and give riggers an alternative to the object/bone based sliders in the 3D view.

Conclusion: These are really tiny nitpicks. This book really is good, in fact, I’d say it’s the best animation and rigging reference for Blender yet, and even as a general reference for riggers and animators in 3D applications (since most techniques will be similar in different programs). While I read through linearly from beginning to end, the book also has ‘See also’ segments at the end of each section, that allow students focusing on a particular track, to follow a different path of learning in the book, something I thought was a good idea. I would put this on my ‘recommend’ list, as a book for intermediate/strong beginners, as a Blender reference for riggers/animators from other software,  or as a book for teachers to use as a textbook.

Сейчас я работаю над персонажем Gilgamesh. Пришлось сделать полностью новую модель и вылепить лицо. Трудно было с УВ-разверткой. Но!!! Пришло время рисования текстур! Много тестов с Projection Painting и слоями (diffuse, bump, specular….).

English Version:

I am currently working on the character Gilgamesh. I had to make a completely new model and sculpt the face. It was difficult to do the UV unwrapping. But! It’s time to paint textures! Many tests with Projection Painting and layers (diffuse, bump, specular ….).

Some cool things you can do with it:

• Find errors in your project globally without having to check each file one by one in blender- and fix them (could benefit from batch tools so you can do multiple at a time)
• Create ‘bundles’ of files, e.g. to send to an off-site animator who doesn’t have SVN access, by quickly seeing all the dependencies of a given scene file. This can be done by hand right now, but I’m pretty sure it could be scripted fairly easily.
• Make sure your files are up to date, track problems with SVN visually
• Rename models/assets, find out where they get used, etc.
• Probably a lot more

Blenderaid could change the way we work with SVN for projects – instead of checking out several gigabytes of production data, each artist need only check out exactly what they need– saving time, local disk space, bandwidth. We could use it also to have versions of assets and switch (optionally) some scenes to use newer versions or to continue working with the old.

I’m hoping to have time after tube to experiment with blenderaid in conjunction with helga, or alone, and to have server-side installation as well as the local one. This could be the key for large-scale projects in blender, big thanks to Jeroen and Monique for writing it, and I look forward to seeing how it evolves.

Quick note from Jeroen: the python2 version saves time by removing the need for additional compiling, and should work without any problem. (I was under the mistaken notion that Blenderaid’s python version had to match Blender’s).

I’ve often wanted to have lines for ‘rule of thirds’ in the Blender Camera as a composition aid – I’ve got countless blend files with little no-face meshes parented to cameras (that have to be moved or scaled whenever I change the camera view angle). Granted this problem could be solved with a driver (That might not update – driving on camera angle is not dependable yet), but I got tired of ad-hoc solutions.

I don’t use the Title safe option that much or at all, so with the help of a trusty text editor (gedit in my case) I hacked a couple of files and now I have ‘Thirds’ instead of title safe for the camera. The internal property is still the same, it just displays differently, so no messing with RNA happened.

If you want the same functionality and are comfortable building blender/applying patches, you can get it here . Usual disclaimers about baby eating and such apply.

Free/Open Source software is nice, isn’t it?

Jeroen Bakker showed me his awesome openCL nodes in the compositor on his laptop, running 20!zoom!! times faster than the CPU equivalent. When this stuff hits it’s going to make a mini-revolution for Blender. I’m no longer a sceptic about GPU computing I guess
Wolfgang Draxinger did a fantastic job making the stereoscopic version of Elephants Dream. Great choices, hard work and technical precision- I’m blown away both by the result, which rivals the best stereo work from major studios, and by the amount of work he put into it. He’s planning Big Buck Bunny next, but in the meantime, some snaps of us removing (the unfortunately crumpled) screen after the show:

I met with Josh, Henri, Francesco, Jason, Jonathan, Jean Sebastian, Heather, and recruited Dolf, Tal, and perhaps Luciano, Andy and Pablo for our project. We had a meeting the second day of the conference, which gave me a chance to finally pitch the story and current animatic to the team in person, talk about where we are at in the project and assign some short-term tasks. We also had a presentation on Sunday, mainly about technical issues: rigging, though I did not demo rigamarule- turns out auto-registration of operators had somewhat broken the UI while I wasn’t looking (it’s fixed in current tube SVN). Josh showed off his work on procedural animation, and Henri demoed building scene layouts from library models using our LODing system and the landmark-snapping system created by Pablo Lizardo.

As Fateh has blogged, Tube member Jarred De Beer won the Suzanne Animation award, congrats dude!

The presentation had an unexpected benefit; it introduced the project to new contributors- Thanks Tal

Sadly I missed some people- Malefico has too many conferences on his plate to make it to Blender conference this year, and I was too swamped to meet up with Stani, Python coder and artist extraordinaire.

Finally, I had the honor of working for a bit on Andy and Eva’s awesome stopmotion animation project- Omega- which has some CG elements. I spent a large part of Monday (the day after the conference) rigging an amazingly designed and detailed character Andy built for the movie.

Big thanks to Ton, Anja, Anna, Nathan and everyone who made the conference possible and enjoyable.

The model for the train is currently very high poly as it will probably be used in a few close-up shots (these renders are all geometry – no texture normal/bump maps!).  There’s a bit of work still left to do (naming 3000 objects and parenting them in a nice ordered heirarchy for one!) and making a low poly version, not to mention further tweaking of the design and rigging the moving parts!  To make the low poly version lots of the objects can simply be moved to a hidden layer (or excluded from the ‘HI’ group – we use group instances to bring models into scene files), but many of the meshes need to be split up into smaller parts so that the smaller parts can be excluded from the low poly renders – for example we need to move the rivets out of the body panel meshes as they will be so small in many of the long shots they won’t be noticeable – even at 2K!

For continuity’s sake we need to make sure the rivets are in the same place in the high and low poly versions.  To save the texture painters some time later down the pipeline I’ve written a script which goes through every object in the mesh and separates the details from the main lower poly mesh component (I can define these using vertex groups etc) and then bakes the details’ AO ‘shadow’ onto the lower poly part of the mesh and saves the texture in a maps file.  The script also intelligently names all of these textures in case links get broken up as the SVN gets reorganized over time.  For example if the script finds an object called ‘side_door’ it will split the object into ‘LOW0001side_door’ (for low poly) and ‘DET0001side_door’ (for details) and then bake out the AO to an image called ‘IMG0001side_door’ while making sure that all the meshes stay linked to save memory (rendering without any textures is already taking up over 2GB of memory).

Unlike the normal P-key behaviour, the script makes sure that separating meshes affects all the linked duplicates, not just one of them.  The numerical prefix helps identify one specific detail mesh with its corresponding specific lower poly mesh.  For example if there are 5 duplicates of ‘side_door’ (‘side_door.001′,’side_door.002′…), the first will be renamed ‘LOW0001side_door’ with its details saved in ‘DET0001side_door’, the second will be renamed ‘LOW0002side_door’ and its details saved in ‘DET0002side_door’ and so on, so future ‘tubers’ to work on the model won’t have to spend hours searching the outliner list to find the right object!  The reason the number is at the start and not the end of the name is to stop blender messing with the numbers, and to help sorting in an alphabetized list!

Fingers crossed there won’t be any surprising bugs in the script, as baking out 1000 unique meshes is likely to take some time and we haven’t written a resume function for the script yet!

There’s also a ‘hidden’ operator you can use in the 3d view (search for change bone name layer) that allows you to switch selected bones to a named layer.  It’s a bit rough, but the panel at least beats having to hunt and peck one of those 32 nondescript little buttons

This isn’t really part of the gilgamesh rig, just a utility I’ve been using while rigging. The final UI (you can see a peak of it just under the layers in the screenie) has hardcoded layer names, and only those that are relevant to animation.

I had great help from JPBouza, who customized a Blenrig model and rig to Gilgamesh proportions from the Zepam mesh – after deliberation, I will do a from scratch rig for our main character, while borrowing some features from this rig, the most important in my opinion is the awesome mesh deformation cage he has made that gets excellent results, which he adapted to Gilga’s proportions, so I’ll probably use that with no modification. I’ve got a list of ‘must have’ features, a good idea of how the overall rig should look like, and a list of ‘nice to have’ features. Some ‘advanced’ techniques are surprisingly easy to do, while some (ahem, skin sliding) will take more work to find workable.
Requirements
We need to start animation in September, so the first thing is deadlines: we need the main body controls locked down by then. No time to wait for a final character model, so I work on a proxy I made for rigging.
A small list of needed features on the very basic proxy:

• IK/FK Blending on the arms and legs
• Locked Elbows for the arms
• Locked Knees for the legs
• Adjustable automatic shoulder rotation
• Adjustable rotation isolation for arms in FK
• Seamless IK/FK blending for legs and arms
• FK control chain for Torso
• Adjustable rotation isolation for torso controls in FK
• IK controls for Torso
• FK/IK switch for Torso
• Seamless Pivot Switching for Torso
• Toe-Midfoot-Heel Pivot for Feet
• Neck controls that allow nice motion/deformation of Gilgamesh’s very unique neck and shoulders
• Eye direction and tracking controls
• Rule tagged bones for easy adjustment and robustness of the rig (with rigamarule)
• Optional stretch for arms, legs and torso

This is not the final list, is enough to get animation started, but not finaled. More features will happen, some on the proxy, some after we get the final character model done, such as:

• Facial animation
• Hand and finger animation
• Deformation tweaks
• Bend tweaks
• Cloth and hair
• Procedural shakes and vibration
• Direct knee and elbow control

Progress

We’ve got the basic FK controls for the Torso, IK and FK for the arms and legs, Auto shoulder rotation tweakable, IK FK blending working on arms and legs, seamless (no jump) blending working 90% on the arms (both ways) and working on the legs going from IK to FK. An initial control UI exists, ready for tweaks, and we have rigamarule ported to 2.5, lacking only nice UI so we can start tagging bones (Thanks Daf and Josh)

I’ve long been frustrated by the limitations of ‘Remove Doubles’ in blender.  Remove doubles searches for verts which are close together (in all axes) and merges them, which is great.  However sometimes its nice to be able to constrain this action to a single (or pair of) axes.  For instance if I have a row of vertices running along the X axis and I want all of them to have the same Y and Z coordinates I could select the entire row then press “s” (to scale), “shift-x” (to constrain to Y and Z), then “0″ (to snap all of them together) .  This is fine if you only have one row of vertices.  Say now that you have 100 such rows of vertices, all running roughly in the X axis direction, and you want each row to run exactly in the x-axis, so for every single one of those 100 rows you have to select each row, and press “s, shift-x, 0, enter”.  Does it get a bit boring?  Would you prefer if it was automated?

Have a look at the quick tutorial image below to see what I mean, and then if you want, download the add-on and install it.  As always let me know if you find any bugs in the comments below and I’ll try to fix them ASAP.  Happy (faster) blending!

DOWNLOAD: http://urchn.org/wp/wp-content/uploads/2010/08/snap_with_axis_constraints.zip

Tutorial:

On another note we’ve been out to the pictures a few times recently.  We saw a double feature of “I am Love” and “Winter’s Bone” on Sunday.  Personally I thought that the cinematography in Winter’s Bone was a refreshing break from the all-to-common extreme-DOF-fatigue that we got to see in the europudding (see Truffaut) of a movie that was “I am Love”, a film laced with religious salvation metaphor and comic (decency induced) visual-analogy-as-substitute-for-the-explicit.  Conversely the portrayal of value-less material items as symbolic of ‘our’ personal hollow ambitions for wealth (in the form of tacky debris spread around the dwelling; toy horses, kitsch garden ornaments displaying cherubic qualities), set against the wholesome immaterial but valuable actions of the film’s main character provided an interesting subtext for what would otherwise have been a straightforward plot.  Sadly some of our friends didn’t see it the same way and criticized the ‘off’ direction and cinematography.  One way to look at it is that they were only judging according to their own personal objective perceptions of how films ‘should’ be directed and shot, rather than to how an audience subjectively perceives a film.  Fire off in the comments; lets hear your own views!

I’m Josh, one of new crew members for tube.  I travelled over to the US from England last week, and I’m here until mid September undertaking cultural studies, and working on the models for the film.  While I attempt to mediate transatlantic differences (such as introducing the rest of the team to Branston Pickle and Marmite, explaining the etymology of ‘bangers and mash’, and justifying why I need a knitted cosy for my teapot), my hosts are offering an American exchange programme complete with drive-in movies, fried dough, Independence Day Celebrations and Root Beer.  In my time away from the screen I’ve been out enjoying the fresh air, beautiful countryside and very un-British weather.  I’ve been running to and from work each day (8 ½ miles each way), and when I had a few hours to spare last weekend I biked up to the Sugarloaf Mountain.

Fresh out of finishing a long and traumatic Architecture degree at Cambridge University, I vowed never to work in the industry again.  My first task in the studio, however, was to design the station roof and columns, and to provide general advice to the rest of the team on all things architectural!  Being British, and naturally strongly resistant to change, I was slightly thrown when I realised the team was working with up to the minute svn builds of Blender.  Back home in my own work I’d been hanging on to the 2.49 vintage with its historical interface not unlike the quirky 400 year old tumbledown cottage I lived in at uni.  2.5 comes with its own breed of glossy newness, an impersonal homogeneity with other 3D apps akin to the monotony of the skyscrapers in downtown LA and a feature set which sprawls on and on like the city-edge of Phoenix, Arizona.

Bewildered at first, I was tempted away from the path of the righteous by the glowing red devil’s tail of Maya on one side and the swirling captivating vortex of 3DS on the other, but eventually I found my way through the valley of darkness.  I still miss many of the 2.49 features which haven’t yet been ported – skinning loops and multi-knife-cuts to name a few, and in my first few days I’ve spent a considerable amount of time filing bug reports, hopefully for the greater good.

There are still some very simple features I wish had been integrated into the new release.  As what Pirsig might call a ‘mechanic of the photographic mind school’, all of my previous organisation and labelling systems have been tainted with a certain amount of… dyslexic logic.  To make life easier for everyone else on the project I have to name every object, bone, group and file according to a strictly prescribed style, not least so our python automation knows what’s going on!  While I don’t mind accumulating road miles on my way to and from Amherst every day, I hate the unnecessary mouse miles blender’s UI demands.  I’ve illustrated one of the key issues (which could be solved by a simple hotkey and under-mouse-dialog) using an analogy that will be familiar even to non-blender users.

After breaking free from summers spent as a CAD-monkey in local architecture firms, I now find myself pining for the logical and consistent snapping and tracking systems I was so familiar with from hours spent in front of Rhino, Vectorworks, AutoCAD and the like.  At least the resulting ‘errors’ present in my incapable use of Blender’s snaps often results in a more derelict and aged look!  Here’s a work-in-progress snapshot of the interior of the train which I’ve been working on today, by virtually bashing it up:

That’s all for now,

Josh