Mancandy updated

  / by Bassam

Mancandy Revisited Perhaps you remember this post in which we introduced blender’s new drivers with the mancandy character. Well, subsequent changes in blender broke the old file; The jaw, eyeballs and other facial controls stopped working once keyed. I was unaware of this until I read this thread on blenderartists, after which I came to two conclusions:

1- Nobody knows the character’s name ;) ! ( His name is Mancandy, an homage to the movie Manchurian Candidate and his candylike outfit)
2- I had to fix the rig to work with the recent improvements in blender, and not just his broken face. Many of the armature’s internals were workarounds for old blender limitations. The intent of the model is for people to learn animation and rigging- which can be confusing if there are 4 bones where only one is needed. So I did a little update of the character. I fixed a few things, simplified some others, and took advantage of the new features.

Though the character is not realistic, the rig isn’t a toon rig; it lacks controls for e.g. squash and stretch ( which I may add at a later date, or can be left as an excersise for the user ). For a more toony setup, visit Sketchy’s excellent Ludwig rig, which is extremely light and has some rather fun squash N stretch-ability.

So without further ado, here is the next update on mancandy, featuring simplified controls , an on face animation control setup, and most importantly, working facial controls.
If you are using a current cvs of blender, or a recent testing build, download the blend file here and read on for a quick rundown of controls / features and what they do- all the features (bone shapes, armature layers will work)
If you are using the latest release, all the functionality is there, but bone shapes and armature layers aren’t. You can download your blend file here and read on, but note that the control bones will show up like plain old bones, and that there are no layers in the armature; all the controls are visible all the time.
(sorry to those who downloaded the cvs version of mancandy yesterday and saw all the bones at once)

Layer one contains the Mancandy mesh itself. Layer three contains the armature that has all animatable controls in it, and layer 20 has all the “non renderables” – meshes starting with the prefix MCBOT that define the custom shapes for mancandy’s controls. With one exception, they are not intended for editing, and are hidden within mancandy’s head in case the layer is unintentionally left on during a render.

All of the bones in the armature are locked to translate only in useful ways; for instance, if a bone should be rotated and not translated or scaled, only the rotation transforms are allowed. You can easily discover what each bone can do by turning on the manipulators and enabling all three transforms, then clicking on the bones and seeing which ones show up ( locked transforms or axis don’t show up in the manipulator)

The controls are also organized via layers- in this case, armature layers, which you can turn on or off via the armature edit buttons, in the Armature tab. Here’s a quick rundown of what you get:

Armature Layer One- general controls Layer one: General controls: Includes IK controls for the legs, and FK controls for the arms, torso and head controls. The controls marked with an asterix ( *) in the image work like hinges in blender; rotating the parent affects their location but not the rotation. This is useful when posing the torso mainly, since you can rotate the head, or torso in any order without having to adjust them constantly. The main torso controller which looks like two blue triangles pointing at Mancandy’s waist give a quick way to rotate/translate the entire upper body in one “chunk”. The chest is setup as a targetless IK bone, and can be moved around as well as rotated. If you have auto key on, set to available, and you have already keyed the backbones’ rotation, this can be a very fast way of posing the upper body; just grab the chest, rotate it, and you’re done!. Feet are IK targets pivoting at the heel, with the addition of two foot controls pivoting at the ball of the foot (these last two rotate around the X axis)
All controls here are locked to the “legal” transformations, so turning on the manipulators, normal mode, for rotation,location, and scale can give you a good indication of what they can do.

hand IK targets Armature Layer Two: this layer has only two bones; the left and right (optional ) IK targets for the hands. Arm IK can be enabled by turning on the IK and copyrot constraint on the hand bones (located in layer One) A future enhancement might be having easy IK FK switching via a python script, that does the requisite keying for “no jumping” on an IK/FK switch… this is somewhat possible right now, albeit manually via keying location and rotation and constraint influence.

finger bones Armature Layer Three: This layer has eight bones, four for each hand. They control the thumbs and fingers of the character. rotating rotates the digits, while scaling the bones cause the fingers to curl in and curl out. The fingers are allowed to rotate on all but the Y axis, and scale on all axis (which results in curling the finger, not scaling it.) for instance, to make a fist: select all the digits, including the thumb and scale them till they are nicely cureled, select the thumb and rotate it on its local X axis, select the rest of the digits and rotate then on their local Z axis.. done. The benefit of this setup is that it gives very few but powerful controllers, It has almost complete flexibility and allows for very few or no “weird” positions, and it is hard to get lost as can happen if you have a bunch of little floating IK targets everywhere.

this is no face robot
Armature Layer Nine (sorry was off by one! -fixed): This layer has all the facial controls. These are similar in function to the controls in the old controller2.blend file, but have been moved into the armature ( to take advantage of the action /NLA system) and onto the face ( for a quick and easy feel for animation). The default layout might seem a bit funny; there are 12 controllers, and, with the exception of some of the eye controls, they all lie in one line down the face. I’ll go into detail on how they work with the mouth Emotion controller- it is the most complex one. If you played with controller2.blend from the last posting, you’ll find that their function is the same as before even though the appearance has changed.

  1. mouth controller diagramBOTmemo controls mouth emotion.. The controller works in a “cross” fashion: Moving it up causes smiling, down causes frowning, and moving it to the left or right at the same time makes the effect lopsided (i.e. a left side smile or a right side one) In addition, scaling the control down causes the mouth to pucker.
  2. BOTbrows: Another cross style controller , it can move in its X and Y axis ( in terms of the head it can move up, down, left and right). The outer brows follow the controller, i.e. moving it straight up lifts the outer brows, straight down lowers them, and moving it up or down and to one side affects the brow to that side only.
  3. BOTbrowmid: This is a limited up and down controller; it moves up and down to raise and lower the middle brow. scaling the controller down furrows the brows, to create the impression of thought or concetration.
  4. BOTeyetrack: moves up, down, left and right, causing the eyes to follow it. scaling it in and out causes the eyeballs to cross or part, good for cross eyed looks or focusing the eyes on close or far objects (imagine the character tracking a fly that lands on his nose) . The eyelids also move with the eyes as they look up and down, much in the same way real eyelids do.
  5. BOTpupil: scaling this up and down shrinks or enlarges the pupil, this is usually not going to be visible in a render, but might be good to register illumination changes, desire/repulsion, drug addiction, or hypnosis by sadistic socially climbing secret agents.
  6. BOTeyelid( _L and _R) scaling them down closes the eyes, scaling them up opens the eyes wide, moving them up and down moves the eyelids’ “center” up and down- this allows to control whether the closing of the eye is done mostly by the upper lid, lower lid or both.
  7. BOTsquint is another cross style controller (like BOTmemo) ; it can move left, right, up or down, but it only does anything in the up direction: squints the left or right eye or both, depending on whether you move it up-left, up middle or up-right.
  8. BOTsneer works the same way as BOTsquint but sneers the nose.
  9. BOTulip is a full on cross controller, and works similar to BOTbrows or BOTmemo; moving up and to the left curls up the left upper lip, up and to the right curls up the right upper lip, and up and to the center curls up the entire upper lip. moving down and to the left curls down the left upper lip… you get the picture
  10. BOTlolip works the same as BOTulip, but for the lower lip
  11. tongue stuff: The three balls in the mouth just move the tongue segments around- they have stretch to constraints to each other, and while the result may not be very delicate or precise it should be fine for 99% of tongue animation needs
  12. BOTjaw can be moved in any direction, to move the jaw up, down, left, right or to jut it in and out.

Armarure Layer 10 (fixed) contains the stride bone, for use in walkcycles. You can see it has a ruler like shape- this is the one case for scaling the display object for the bone, since it can be used to “measure” the stride of the character in a walk. ( you can find the stride bone shape in layer 20, conveniently parented to the actual stride bone)

Well, that’s all for now folks. Next post will return you to your regularly scheduled orange news.

[EDIT] If you’d like to use a recent checkout of blender, and you’re not sure how to build it or don’t want to, head over to the testing builds forum on

« | »

117 Responses to “Mancandy updated”

  1. Roger Wickes said on 3 May, 2006:

    Mike S.: In my previous life of running a software development company, we had to do two things when releasing new versions: regression testing and backward compatibility. The regression testing made sure that the new version did not introduce new bugs. We re-ran hundreds of object-action test scripts, even if we all thought that no-one touched the code. Sure enuf, an object-method or database property (persistence) change screwed up code that referenced that property which none of us thought of. We used an rdb for our persistence store and I guarantee that a new version would never work with an old db version; they always had to sync up and in fact had to first run scripts to convert the db data over to the new db schema version.

    With Blender therefore, I am simply amazed when a new version even opens an old file version! The file compatibility issue must be a nightmare, since there are so many file format versions (1.4, 2.1, 2.4) floating around that contain so many versions of so many objects stored in them. I myself have opened other’s models only to find their bones wierdly strewn and reoriented every which way. I am sure that the Bone object from version 1 does not match bone version 2.4. When we get into objects like armatures that have had recent total rewrites, I would think it is almost guaranteed that old file versions would not work with the new software as is. There has to be some sort of code that fills in missing properties with default values when the old object definition is read in. And with objects, it isn’t as simple as setting =null(); oft times the objects are linked, in fact must be linked, and so chaos ensues. Add Newbie ignorance on top of that, and we can have one heck of a confusion. On top of all that, I suppose there are some who like 2.3 and want to stay with 2.3; thus when they open a 2.4 file and get wierd results that just layers on the fuddle factor. And then the best of us just forget about stuff, like the layers buttons turning off visibility of objects. So, expect discrepancies when you upgrade, and read the release notes to see what kinds of objects you might have problems with.

    My second thought is that of the hated word, the unspeakable, the word that elicits groans. You know what word I’m talking about and I shall not mention it by name, for to utter its name gives it form. For it is sooooo much more fun to create than to document. Ooops. I said it. darn. sorry. But now that my loose lips have spilt the word, I think the dev team should put some thought to how to contain user-entered documentation or guidance within a model or object. For example, the layers and what they contain – I use a embedded file to doco my layers, but then I get into Ipo and keyframes of scenes and it gets VERY cluttered and messy and I end up keeping paper notes. Well, what if I was working over the web with someone else (blender artists forum recently suggested trying a simple multi-person dev) – how would they know the list of possible poses and actions that Mancandy could attain, and which of those actually worked and which I was still working on? It would be nice to be able to attach a note (similar to the hover/popup toolbar hint) to objects that I include to indicate how to be used or development/modeling status or usage or links to other objects and why. Hmmmm…maybe I need to post this idea to the dev forum feature request. Thanks for listening. Like with Mancandy, good, clear object names is a lifesaver, but how are we to know that to stretch out his arm, we are to rotate (not grab and move) the xxxxx object, but really the best way to so grab and move the hand target and let the system figure out the ‘best’ arm position?

    And Matt, I remember when chess moves were the only spam to come over the Internet. I am sorry for the huge volume of spam and the idiots that seek to ruin the greatest creation mankind has yet birthed by making good people like you literally waste their lives away deleting garbage. Perhaps this posting system should have one of those distorted images (Vroom?) that we have to type in…

  2. Roger Wickes said on 3 May, 2006:

    Sorry, this is the Orange blog. I should ask: how did Orange team members communicate and coordinate work?

    Because it was a small team in close physical proximity, maybe by vertical task assignment (Only Bassam does textures, and all textures are assigned by Bassam, so everyone, submit your final models to Basaam for texturing and then to @ndy for rigging because all rigging is done by @ndy….which would be great until Matt gets run over biking to work, and then no-one knows how Proog was supposed to squint and why he had that funny little neck thing going on…

  3. LetterRip said on 3 May, 2006:


    “With Blender therefore, I am simply amazed when a new version even opens an old file version! ”

    the file format has been designed and tested for forwards and backwards capability, and changes to SDNA are carefully evaluated, with older versions are supposed to ignore stuff they don’t understand. But their have been official points where known breakage would happen (specifically the armature system with the 2.40 release).

    There is a python script which parses blender files, that perhaps in the future could be used to fix that as well.

    “I think the dev team should put some thought to how to contain user-entered documentation or guidance within a model or object.”

    Custom properties is on the todo list, right now you could add multiple text files with the name of the object as the text name.

    “For example, the layers and what they contain”

    layers is on the todo list for an overhaul.


  4. Mike Stramba said on 3 May, 2006:

    Roger W,

    So I take it you don’t know the answer to my question(s) ;)

    “There is a python script which parses blender files”

    Do you have link to that file ?


  5. LetterRip said on 4 May, 2006:



  6. Roger Wickes said on 4 May, 2006:

    LetterRip: Thanks! Again, I am amazed at the progress youzeguys make when really really talented people work together.

    Mike: I think LetterRip answered the armature question, assuming IPO Drivers are linked to Armatures…

    My problems are always so much simpler than all of yours, like in ManCandy, all the actions seem to work except the last one, that is MCDrivenELR which (i think) is ManCandy Driven Eyes Left to Right. And then I think about fixing it but I get overwhelmed at what to do because I find the things that I am doing don’t fix the problem but cause more problems instead, so I end up grabbing and rotating stuff but only clicking the right button to abort any changes, ultimately closing the file without learning anything (except that when it comes to use blender, I am no expert). Orange guys, let me just say that I have an inkling of the amount of work it must have taken to get the character’s expressions…hundreds…? of these little movements…down and sychronized to a voice track… wow.

  7. Mike Stramba said on 4 May, 2006:


    Thanks for that link.


  8. Vassilios Boucer said on 4 May, 2006:

    Call for Entrys!What about “Elephants Dream”?

  9. Toni said on 4 May, 2006:

    Well, every one seemed to ignore my comment so I think I’ll take the model and give him some guns and a trench coat and make a cool CGI movie. Say around 2-3 min. When I get the guns, etc. I’ll post some screens. :P

  10. dave said on 5 May, 2006:

    i liked mancandy -the animation figure . it was kind apre-historic , as if it came out of some archaeologists excavations. however , the article on the product contained all the required information. you could have added some pictures to it too.

  11. joeri said on 8 May, 2006:

    Isn’t that been done before? I seem to remember something like that called Loki.

  12. Toni said on 8 May, 2006:

    I don’t know…. Oh well, I decided to scratch that project and just make my own.

  13. Toni said on 8 May, 2006:

    Oops! theres a guy on the team named Toni also. Sorry thats not me. I’m not on the team. Hee Hee… oops! Kinda Ironic. :P

  14. Paul said on 10 May, 2006:

    Awesome rig.

    I have a quick question about posing mancandy’s FK arms — if anyone knows. Even when I have the IK solver set to 0, when I try to rotate the forearm, the upper arm still seems to be affected by the movement(almost as if IK is kind of still working). The elbow bounces around. Any suggestions on how to get it to work completely FK? Or am I doing something wrong?

  15. Mike Stramba said on 11 May, 2006:


    re: fk/ik

    I just tried it (Windows) with both 2.41 and the latest CVS and I’m not getting any “elbow bounce”. Tried it with both a (g)rab and a (r)otate. His upper arm doesn’t move at all.

    I also tried both the ‘new’ and ‘old’ files, they both work correctly


  16. Bassam said on 5 Jun, 2006:

    Paul, sorry for the belated reply..
    it seems like influence “zero” doesn’t always work- I need to investigate this further, it’s possibly a bug.
    deleting the IK constraints is a workaround for now.
    sorry for the delay!