Guest Blogger: Raffaele Fragapane

What is Rigging?

Rigging, for the uninitiated, isn’t all that hard to frame.
Every puppet goes from the wood carving to needing holes drilled and joints fitted before it can be articulated.
Every marionette requires that the ends of the limbs are weighted then wired to a frame for the puppeteer to swing it around.
Every radio controlled animatronic you see in old (and some new) movies requires you fit radio receivers and servos to move the motorised frame hidden under the exterior.

Rigging is just that. Half black art and half engineering, it’s the creative endeavour that ensures every puppeteer can move a frame and make the marionette dance without worrying about the wires getting tangled (too much); that every operator at the radio control can move a stick and expect a frown on an animatronic face.

Riggers come from all walks of life: From animators who wanted to keyframe, but needed a rig, and never got to the animating part because they got lost in the art of making the puppets instead of making them move, all the way to engineers who decided numbers weren’t enough, and they wanted to see something dance.
We all end up in the same place though: building the characters someone else can do the acting for.

Caveat

Given the scope of this articles we’ll concentrate on rigging for feature animation and creature VFX; games or other real time applications would complicate the subject past the scope of this article.

Historical Context

Rigging in computer graphics is notionally unchanged from what vehicle and animatronic teams took care of in the 30+ years precedent to Jurassic Park.

1. Art designs a character or a vehicle the story needs and the director wants
2. Feasibility is assessed
3. Design gets iterated until it reaches “physically possible” stage (or “well, we gotta try”)
4. An articulated armature is fit then mechanised,  so it can be moved on set
5. Tweak and repeat until enough rigs and puppets are produced (sometimes more than one for the same creature or vehicle depending on shot needs) so that all shots can be realised.

In terms of how it’s done things get fuzzier; you’ll find different animation and vfx houses, or sometimes even just different teams within each, can operate very differently from each other.

Pipeline Presence

Rigging is positioned in the pipeline no differently than pre-digital era. Computer graphics in general, and large pipelines particularly, tend to be more compartmentalised than work on set and in model shops used to be, but the nature of the work isn’t all that different, mostly the medium is.
It’s common for rigging to specialise in the armature and mechanics part of the old process.

So Let’s stick to two things: Armature and  Mechanics (puppetry), and Model (deformation).

Rigging as Tool Development

Don’t worry, this isn’t going to be about how everyone should be an ace programmer, although programming is certainly a useful and increasingly requested skill in rigging.

Animation looks at draftsmanship skills like understanding of spaces and poses, acting, and experience in the  observation and intuition of reality, as the qualities of a professional.
Modelling has never been particularly hard to identify as a newer way of sculpting. Lighting’s lineage couldn’t be more obvious.

What does a rigging department actually do?
It produces tangible assets, the rigs that will be loaded in the shot, but that’s just pipeline details.
It will inform the (re)design of a creature, possibly even significantly, but that’s process, not the nature of the discipline; the responsibility of design is usually left to the loop between director unit and art department.
one could be animating their own rigs, but that’s not really rigging as much as someone doing two jobs.

What rigging actually produces is tools enabling animators to act by proxy while facilitating “staying on model”
Joe Animator might be using Maya, or Blender, or some other commercial or proprietary software, but that’s limited almost entirely to editing function curves and interacting with a viewport.
What animators see and use all day to translate on screen controls and sliders into posed geometry, and what can make or break an animator’s flow in acting a shot, is all in the rig. It tends to work out well to think of designing and using rigs in the same terms you would of software tools.

On the authoring side of the fence it’s also practical to think of the rig in terms of software/tool design, as almost all the coarse grained problems are shared with tool development and deployment. I’ll circle back to this analogy repeatedly.

Tools of the Trade

Rigging’s blurry identity comes through in the toolkit as well.
Other disciplines have evolved some clarity over the years and often have very specialised tools around sharpening the view of that discipline: ZBrush for Modelling, Mari for Texturing, Nuke for Compositing, Katana for lighting etc.

Rigging, however, unlike most or all other disciplines remains firmly planted in no man’s land.
With some notable exceptions such as rigging for a specific motion capture or performance capture system, work tends to happen inside general purpose software (such as Maya or similar).

Lack of highly specialised environments might or might not be a negative thing, it’s hard to tell since there is no historically significant successful or failed commercial attempt, but at the end of the day it’s how the cookie crumbles, and it’s been a very influential factor in forming the current stock of professionals and hobbyists doing it.

Rig Breakdown

What follows is by no means a standard, nor are all things required or that neatly separated, but they are common enough to use them as a framework.

Let’s divide the responsibilities of a rig in four categories, or layer,s of the rig. Armature, Guide, Control and Deformation.

Armature

As in the days of old of model making it’s usually possible identify an internal armature to a rig. This are the joints between the rigidly moving parts that coarsely articulate the rig.

An example would be having a box for the pelvis, a ball and socket joint at the top of each femur reaching to a hinge at the knee, then reaching to another ball and socket at the ankle and so on.
You can think of it as stick-man, twined metal wire the way it’s used to support sculptures.

Depending on how the other layers will be implemented it might not necessarily be appropriate to design the armature exactly the way the skeleton of a creature would be laid out, but it’s often a starting point; joint placement is commonly first done coarsely and then tweaked as other steps are iterated.

Correct Armature placement is almost 100% a matter of experience and it should never be executed as a stand-alone exercise, always be ready to move it in function of what works best for the rig as a whole.

In simple rigs there might be no difference between the armature and skinning influences, and in a lot of places the notion of having a stand-alone armature might be completely missing from how they operate, so don’t get too stuck on this.
What’s notionally important to think of the armature as is: the relationship between Control Layer and Deformation influences.



Control

This is the quintessential part of a rig when animators talk about one.

Interface,

As software has a UI with active areas (buttons, sliders etc.), rigs will have controls you can manipulate: objects in the scene that can be selected, manipulators in the viewport, or numerical attributes to be set.

Much like UI/UX design in software development communication with the users and willingness to iterate into agreeance are key to providing them with a useful interface.
Are all controls easily selected? Is the viewport too cluttered and they occlude each other all the time? Are we missing some first-class-citizen controls because we hid them in some deeply nested attribute somewhere? Is the colour scheme helping identify elements and is it colorblindness friendly?

Mechanics,

The mechanics part is highly specific to each rig’s component and can be hard to formalise. When a user manipulates the interface they expect many things, far, far downstream of that control (a point on a mesh) to happen, and they don’t need or want to know what’s going on under the hood.
The mechanics are what’s under the hood. All the nodes, expressions, connections and magic sauce ensuring, when you move a wrist control and set a limb to “bendy”, that dozens of hidden transforms in the scene change in position and rotation accordingly.
This is largely the same as fitting all the motors, servos, stabilizers etc. in the animatronics rigs of old.

Mechanics also determine interdependency of parameters, which is a fancy way to say that quite a lot of stuff might need moving around when the animators change the state of a seemingly innocent “auto clavicle” parameter.
Complexity and variance of those interactions determines two things: Performance (how fast the rig will evaluate) and Interface complexity.

Rich or versatile behaviour is more expensive to evaluate and will gradually slow down a rig.
Complexity in mechanics is sometimes added to simplify an interface (few parameters combined combine into multiple behaviours), or other times to build an uber-rig of versatility while complicating interaction (all kind of space switches and blends end up being everywhere).

There is no clear right or wrong. Just don’t choose on those trade-off factors lightly.
The speed of a rig isn’t just how fast it evaluates, it’s also how quickly it can understood by the user.

Overly complex rigs that evaluate sluggishly will fall below real time and force animators into frequent flipbooking.
An overly simplistic rig might be fast, but will cost time animating complex behaviour with insufficient tools (e.g. an FK only limb is a terrifying thing animate stuck or following something else).
A rig that’s both fast and rich in features, but overly complex to control (dozens of obscure knobs and dials) will weigh on artists’ cognitive load and make use frustrating; even worse functionality might go unused and an expensive rig will end up being used as an overly simplistic one.

It’s a juggling act that can only come to a good end through frequent and meaningful communication between users (animators), developers (riggers), and architects (supervisors/leads).

Guide

This might or might not be an optional or even existing step for the production you are on.
In this we include both guide layers that offer interactive rig authoring as well as so called “auto-rigging” tools that procedurally build a rig from some parameter or script changes.

While not always seen that way rigging scripts and configurable rigs serve exactly the same purpose: building multiple assets from a common root, and have the same responsibilities.

How many taxonomically similar creatures you need rigged will determine whether guides are desirable, but even with single deliveries per taxonomy it’s not uncommon to want a way to re-configure a rig procedurally or intuitively, especially if it works well for revising and versioning a rig as user inevitably ask for new features and bug fixes they found in the previous delivery (see? Software).

It’s also common to have a Guide affecting deformation, and not just the layout of controls, especially if a single rig needs to be produced in multiple resolutions; more on that subject later.

With all that in mind: Build rigs that have explicit and easily altered connections between all their parts, be it components representing limbs or layer representing responsibilities. The more unambiguously structured and compartmentalised a rig is the easier it will be to maintain it (yes, software again).

If you have an explicit armature layer it’s sometimes a good and cheap to implement idea to use that as the framework for the guide, especially if controls and deformation are relatively well tied to it.

Now, does this mean you should always spend a lot of time on guides? Not necessarily:

You can eschew guides when working on fast prototypes meant to exemplify or validate ideas, just make sure those are disposable and not altering assets on storage and already in use if you have a standard for guidable rigs.

It’s also not impossible the answer to the guide question might well be you don’t need, or can’t afford one at all.

If you have a long running production (many release cycles), or a lot of developers (riggers), or a lot of users (animators), You’re likely to benefit from consistency across releases, and you need to take care of versioning and building/deploying.

If you’re on a short lived project with a small team that already has a short-hand between members you might not be able to find the time and deal with the overhead of guides, but do remember (especially for short but recurring work) that making rigs guidable after the fact tends to be a great deal more painful and disruptive than working that way from the start.

 

Deformation

Last but certainly not least a rig is ultimately responsible for posing geometry, and that’s what deformation is all about.
We’ll only talk in the context of organic creatures for the sake of simplicity.

Deformation bookends all animation work.
Without geometry bound to the controls animators would see nothing but a crowded wireframe, so it’s common to at least rigidly bind sliced proxy geometry to the armature or the controls before delivering anything to animation for testing.

As animation progresses and artists put every anatomical impossibility in a shot in service of the camera, deformation has to be iterated to cope with more breakage, while also being iterated to wrangle the results back “on character” (this last thing is particularly true for faces).

If there is one thing in rigging where the mythical eye for detail shines through it’s here.
The timeline, what tools are available, and the quality of the geometry will often be your constraining factors.

The most ubiquitous deformation techniques tend to be skinning and shape animation. These two things, given enough time and patience, can be taken to extraordinary lengths and levels of quality.

Skinning (bindings points on a mesh to the motion of one or more bones) and shapes (saving per point offsets on geometry) will usually move the main masses of a creature into poses well enough, but rarely without any issues, which leads into either more shapes (correctives) or some “plastering” via smooth and push operators and other such things.

Specific or creative effects and corrections are also par for the course and often added with generic operators such as lattices and clusters.

From this point on things tend to get complicated, and certainly not ubiquitous or commonly available, so we’ll leave it at this.

All those operations on each point of a geometry can be very computationally expensive.
While some progress has been made in making better use of resources recently (e.g. Maya 2016 use of the videocard to assist in the deformation stage), this often comes with caveats and limitations, and it can still easily bring a workstation to its knees and playback choppily if you push it too far.

Deformation therefore becomes another balancing act where you trade fidelity for playback performance.
A common choice is to spend some time on redundancy and produce multiple resolutions of a rig that are paired with multiple sets of geometry of increasing complexity.

 

Geometry

Now, for a segway out of our last paragraph on deformation: it’s still very common that each character will be produced in multiple resolutions. These will sometimes be referred to as LODs (Level of Detail) but could also be called anything else depending on where you work.

Commonly employed ones (neither mandatory or exhaustive) are Proxy -> Low Res -> Mid Res -> High Res

1.  Proxy: The mesh is sliced into overlapping, capped pieces of geometry like a marionette, and those are rigidly bound (parented or constrained) to the armature. This has very little cost, and is often enough to block a shot and get most coarse body motion done, and is often also how a rig starts its iterations
2.  Low Res: Usually a non subdivided but contiguous piece of geometry for the creature is used, and only simple skinning and face mechanics are used (non fine grained things like jaw, eyelids and tongue that can easily be skinned or require few shapes).
   This is probably not going to have enough fidelity to take a shot to finaling, but it will usually get very close to it for anything that isn’t subtle acting or dialogue centric shots.
3.  Mid Res: This is called a million different names and is different in every place, but some variation of the rig with reasonable geometry fidelity to the one used in final shots, and a full face system attached is usually available.
   Sometimes this might be the highest resolution deformation reaches, especially for the more cartoony work or in tighter budgets, but not all the time. This is something that should take all shots through most of the polish pass.
4.  High Res: And here everything and the kitchen sink live. Whatever you have that the final shots and other departments use (charFX, FX etc.), as well as deformer configurations that kill performance, will need to live somewhere between the keyframes and the rendering engine. This is their home.

There would be more to be said about the geometry side of things, but it straddles the boundary between rigging and modelling, and much of that tends to quickly become specific to the specific company or workflow.

I.E. Geometry is often a lot more than just your “base mesh”, it can  include several varieties of shapes, and those can also be of many different types. Any amount of those shapes might be done by rigging in some places, and not at all in others.

 

Core Skills

For the sake of example let’s accept that Animation is built on three skills: Acting, Draftsmanship (pose, composition etc.) and some intuition of physics and how to represent it.
Each animator will often have their own mix of amounts and quality of those skills, which is why you see some animators do amazing work for action shots, but struggle with dialogue, or vice versa. Very few people, usually very experienced individuals, have taken all facets of their work to mastery and can span all shots in a show.

Rigging has a similar trifecta: An intuition for design and aesthetics (the ephemeral “eye for detail”),  software dexterity (knowing all dark corners of software and process), and some scientific knowledge (knowledge of relevant maths and engineering skills involved in translation function curves into moving vertices).

As animators are often cast to a sequence or a character based on their strengths, riggers will often thrive or struggle in certain scenarios depending on the environment they work in and how competent they are in each key area.

It’s rare that you can do outstanding work by the mastery of just one, most really good riggers will have a solid grasp on two, and more rarely you will find someone that’s been around and dedicated for long enough to be really good at all three.

Which two can be the most useful or important is often determined by the environment you work in.

Software Dexterity

Let’s start with the easiest. Rigging is inextricably tied to the software it’s executed on.
The old adage “it’s the artist, not the tools” while not false is a shallow truth. It’s a knee jerk reaction to internet software wars of old where “all software do the same things” had become the software equivalent of being overly politically correct, and as a result it’s often uncool to believe otherwise.

Whether you’re in the deep end and understand how software operates at a low level, or more of a tinkerer who learned every software trick in the book for a specific application: knowing the software is an important part of executing ideas quickly and often necessary to best squeeze performance out of rigs.

In small teams and when the work place doesn’t have a hugely formal and rigid pipeline, when  turnaround time is short, software dexterity and breadth of knowledge can be extremely desirable.
In more general terms, even for the most technical of riggers, it’s unwise to generalise problems so much that platform specific knowledge (e.g. the software’s API and execution models) can be ignored.

If you identify as a software expert, and haven’t spent times on much else yet, you’re in a good position to be a valuable asset in a place that has a quick turnaround of low budget assets, or even in a larger facility you can still be busy and be “that guy” that animators and other riggers go to for software knowledge, but I wouldn’t recommend living on software expertise alone.

I wouldn’t recommend making this your only focus, but it’s not a skill set that should be looked down on by otherwise inclined people, and it’s certainly a valid starting point for many positions, and often where some of the most eager students get their break through into rigging.



Scientific Knowledge

These remain broad categories, so what follows isn’t a shopping list of everything you should absolutely know, rather these are some subjects people often think of as “technical” that come in extremely handy in rigging.
I would argue a very small modicum of each subject is probably desirable even very early out of juniorship. At the very least i can state with certainty that things aren’t as intimidating as people often think these subjects are, and you will get tremendous mileage out of even very little applied mathematics and engineering knowledge.

Mathematics,

Even in small amounts this can go a long way toward producing more efficient rigs. Some simple arithmetic and trigonometry for expressions, or to know what some nodes or utilities in your application do, are nearly impossible to escape when rigging even at a basic level.

Some people have managed to do spectacular work for years by simple trial and error and some intuition matured from that, so again you can actually get by with little to nothing, but it’s not ideal.

In decreasing order of popularity: Algebra, Trigonometry, Linear Algebra (the simple kind, vector and matrix math) and Calculus (again the simple stuff, simple interpolation and minimisation are often enough).
There is plenty more that can apply to rigging, but past the above one starts to get closer to what in most facilities is often the domain of RnD and is rarely done on the production floor past sketching state.

Programming,

There is some odd distinction in a lot of people’s mind where scripting, or writing expressions, or connecting nodes isn’t programming; a notion that programming is only coding (writing in text that requires machine interpretation), but that’s incorrect as well as unnecessarily discouraging.

If you can cobble together logic control with expressions, you make choices with driven keys, you open a node graph and noodle together a flow, you are programming already, and chances are if you rig you have done all of that and thought nothing of it.

As you grow comfortable with less “tactile” and experimental forms of programming, and learn what languages and tools you need on the way, a lot opens up in how versatile you can make a rig, and how much stuff you can move out from the guts of the rig, where they cost you performance, and turn into tools that manipulate the scene instead (tooling is an extremely important and often underprivileged part of rigging).

Maturing your technical skills is very important.
Firstly: they are the most portable: Not only math and programming transcend the application you use, which is handy when a software house decides to end-of-life your favorite software, or you are required to use a different one for a job, but they cross over to industries other than Computer Graphics.
Possibly more importantly: Technical disciplines are formative; practicing literally changes a person’s view of the world and gives a completely different kind of insight in the problems the field (rigging) concerns itself with.

Eye for detail

You will find references to the mythical eye for detail just about everywhere when looking for a job.

There is no formal definition; everybody might well have a slightly different idea of how it’s described, but it usually boils down to all those things that aren’t measurable and go into making the end result of a rig “pretty”, or “feel right” in one way or another.

It’s often used to refer to modeling pleasant shapes when doing face systems or PSD states (Pose Space Deformation shapes), or the sense of aesthetics, and intuition, required to put together UIs that “feel right”, or a number of other similar things that aren’t measurable, and are often only obvious by their absence.

It might seem weird to have such a hand-wavey concept as the third corner when the other two are more objective and measurable, but that’s kind of the point.
Eye for detail is usually a direct consequence of experience, and not just the grind of having done something a million times, but having done it and re-done it differently many times, to completion, and with frequent self-assessment.

Much like accomplished artists will both have a routine daily practice, as well as frequently put themselves outside their comfort zone, this is about being the right amount of diligent and adventurous for enough hours that patterns that are intuited and not known are learned.

Same as for the other qualities, not everybody cares to excel at this.
Some people would rather spend time immersed in more grounded technical details, or the production just doesn’t demand “details” in any form.
Within certain budgets and deadlines it’s not uncommon to have simple rigs that don’t offer much space to elaborate on interfaces, and deformations can be basic, but there are also some facilities where rigging is seen almost entirely as this kind of aesthetic exercise (and technical aspects are left to RnD or to another small, static swat team inside the department) and it might be highly valued.

 

On communication

It’s very rare that the best hardware wins a console race; usually the one with the most user appeal and the most published titles does.

Most ubiquitous every-day devices aren’t the cheapest in their category, nor the most powerful, and hardly ever the best bang for buck, they are the ones that people can intuit and that marketing can sell.

I’m sure you see where I’m going with this, and the software analogy.
Your rig is only as good as the understanding the users can develop in the time they have leading to a shot.

It’s by far one of the hardest things to deal with in production, especially when you start becoming accomplished and far sighted, but the best rigs are the rigs that people like the most.
It doesn’t mean you can’t occasionally be disruptive, introduce some brilliant and original feature that people are unfamiliar with, but when you do you have to be ready to go the extra mile it takes to demonstrate it and sell it.

Iterating with animation

“Keep showing me stuff, I’ll know it when I’ll see it”. While the phrase is usually negatively attributed to indecisive directors it’s actually how a lot of creative people work in the face of something they don’t know the details of.
Creative processes are by nature iterative, and both good software design as well as animation are creative processes.

Dealing with this is a two part process: Accept iteration is often the nature of the game, and organise to work by it; and second remember it’s a balancing act between sometimes knowing better, and other times listening and finding legitimate pain points or requests that need addressing.

On the rigging side prototype quickly and frequently. Don’t discuss things at a table for hours to deliver a Frankenstein’s Monster rig two months later. Don’t argue technicalities in endless impersonal email threads. Show ideas in practice, even if the material is buggy or limited (it’s what a prototype is for).
On the animation side it’s important that testing and feedback are taken seriously and carried forward in front of a monitor and with prototypes in actual use. E-mail notes about something as complex as a rig simply never worked, and likely never will; make sure notes and issues are delivered in person while manipulating the prototype.
Work with production to make sure that adequate time is set aside to model rig to the needs of staff and production, build trust with the user base, and make sure they feel invested in what ultimately is deployed to animate shots.

This doesn’t solve everything, always, but easily three quarters of problems with controls I’ve seen were ironed out promptly when continuous iteration and rapid prototyping were in the picture, and immensely painful when not.

There would be more to say about this; how supervisors work across departments, how the teams are structured and whether communication is facilitated or hampered etc. all play a huge part in this, but even in the more challenging situations (multi-site with cross-department comms only going through supes) there’s usually enough elbow room to build at least some mutual trust.

If the the production is structured in such a way to be averse to iterating, and you can’t seem to change that, then brace for impact and structure your work in such a way that avalanche level revisions every few weeks can be managed.

Iterating with modelling

While you have a relatively clear service provider to client relationship with animation, you also receive assets from modelling which will rarely be good at their first iterations. You will also frequently need to cope with revisions to the geometry caused by character design changes or other similar circumstances.

A great deal of work in rigging is tightly coupled with the indexing and topology of the geometry you deal with.

Figure out early which department has what responsibilities and make sure they work in context.

Base Geometry

Make sure that you fit a simple skeleton and do some approximate bindings on geometry as soon as possible.
Experienced riggers and some modellers, especially if they have worked together for a long time or work by standards established company wide, will often start from a good point, but there’s nothing like actually posing the geometry as soon as possible to figure out if the proportions actually work, and whether some junctions might need slimming or fattening in such a way that there’s an effect on topology.

If you have multiple resolutions that are sequential subdivisions of the same base mesh also make sure that those subdivisions are consistent, and that they aren’t derived up and down from a different starting resolution every revision. Consistency across versions of a geometry asset are important, but internal consistency between variations of that asset are just as important, and in some workflows even more so.

Don’t just resentfully remodel stuff coming from another department. If you have time, skill and inclination to remodel something put that skill to a good use, do a minimal amount of it and use it didactically to establish guidelines with practical examples for modellers to work on similar problematic areas.

Everything we said for animation still applies to modelling, communication and ensuring your asset providers remain invested in your choices is more important than making a point. It’s a team effort, even when it’s a team of only two or three people.

Lastly, since modelling can sometimes work after rigging has taken place (especially for correctives, but also for mixed face systems that combine parametric deformation with explicit shapes) ensure that work is done in context.

If a shape applies only in a specific space (pose or attributes set to certain values), ensure that modelling can work on top of the rigged mesh and extract shape differences correctly, or at the very least provide them with a strong and clearly labelled framework (might be as simple as having some reference meshes) to ensure they have as easy a time as possible to do that work for you in exactly the right space



In Conclusion

So, you made it this far after a massive sequence of walls of text, or maybe skipped here to see what this is all about, what is ultimately important to rigging?

• Treat rigging as you would software development
• Remember you have clients, and that making your client’s life as easy as possible is how software succeeds
• Find the right balance between disruptive changes and your desire to innovate, and delivering on some boring but widely accepted paradigms
• Avoid impersonal and confrontational communication means, you are dealing with an impossibly complex problem to just word it, prefer video captures or even better personal interaction to emails and scribbled screenshots
• Above all, establish and maintain trust with users. It’s paramount they trust your deliveries, that they know they can bring an idea to you, and that if you’re coming at some feature from the left field they can play with it and be invested in promoting it amongst their peers
• Iterate quickly and frequently, there is no other way to build quality and user investment
• Figure out what skills work best for a production, and make sure you position yourself with your peers to make the most use of your strongest, while finding chances to work at the right level to keep improving on your weakest
• There is NOTHING like having to deliver to learn quickly, but you want to be only a little bit out of your comfort zone and only on some of the tasks, while you retain or build your reputation by providing services on your strengths as well
• Remember every time you were frustrated at your clients (animation), remember what worked when you weren’t, and make sure you transpose that to those providing YOU with services (pipeline, modelling, RnD etc.)

Thanks for reading, and happy rigging

About Raffaele Fragapane

Raffaele is the Performance Technology Supervisor for Animal Logic, where he’s responsible for the consistency of architecture and design of technology and tools spanning rigging, layout and animation, as well as the host of www.cultofrig.com a video series about rigging from first principles.