From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Rationale

While our current ways of posing rigs - using transforms tools to either grab, rotate, or scale selected bones; directly editing some value sliders; or applying predefined poses (PoseLib) - are effective and production proven methods commonly used throughout the industry, there is still quite a bit room for improvement.

For instance, transforms and using value sliders is quite a logical analytical approach to the posing problem. However, they can often be tedious to tweak to obtain the desired curvature and/or orientation differentiation required (i.e. for tree/branch-like rigs, manual hair controls, limbs), especially when different levels are required for different parts.

Pose Libraries, while a slightly different approach, are still by and large dependent on the tools mentioned earlier, since they require some input to be useful. Hence they are still only a secondary-level solution.

Some of this pain could be reduced through the use of rigs which repackage the above methods to provide rig controls which act as meta-controllers, providing simplified controls to achieve certain results. The downsides to these are that they usually make tweaking difficult.


Method 1 - Sculpt

Sculpt-based approaches are popular already for things like modelling and also for combing fur. An approach like the one used for combing fur could be useful, as continuous segments of bones (like limbs, fingers, branches) could be made to curl up by brushing (and holding) over them for varying amounts of time, without the need to make a selection first.


As a sort of subset of this though, are tools to "push" or exaggerate key poses. In 2.4x, there was a tool of this sort, though it only allowed to interpolate between poses defined by nearby keyframes.

Method 2 - Sketch

Current sketch based approaches fall into several categories:

  • full figure sketch decoding - animator makes sketches using blobs or so, which the software tries to find position of limbs and generate possible alternatives for user to use...
  • stick figure sketch decoding - similar to above, except that only line segments are used, and the line segments have joints marked to help the system identify the joints and hence a projection for the pose
  • sketches are used merely as an annotation tool for animators to plan their animation (i.e. Grease Pencil)

The first two approaches (explored in papers as recently as 2006/7 last time I checked), are still quite unsuited for production work and have many only existed in experimental research work. A main flaw with such approaches is that they assume that the user only wants to work with full-body type posing, and knows exactly how all parts of the pose will be like. While this approach is kindof recommended by animation mentors, it does create a bit more work for the user. Also, these fail to work well for things like facial animation too well.

A possible alternative (though rather more involved), is to take advantage of common animator concepts such as "line of action" which are likely to be defined as part of the planning done (using Grease Pencil). A "line of action" is simply a single curve which can be drawn through the main extents of the limbs, acting like a kind-of tent-pole of the pose. Now, in many cases, it is quite obvious (intuitively) that the projection of such a curve on to some part of a rig should be able to be used to make that part of the rig take the given shape. For instance, when roughly side-on to a character, a C-shaped curve could be used to create an arching spine or so. This does become a bit more involved to resolve for something like a s-curve for line of action from outstretched leg to arm in a run-cycle.


Further Issues

A quick list of other items that need attention are:

  • Animating contact/interactions between characters efficiently. Perhaps more of the territory of scripts running as part of the character rigs, but some way to deal with this would be good. What is unclear here is the exact bounds of the problem region - what are the main bottlenecks/problems there?