Skinning Fundamentals

This chapter is a very brief but hopefully complete introduction to the fundamentals of skinning and how this applies to Blender. Please be prepared to read this chapter more than once. It is not an easy document and i have put a lot of effort into describing the topic as simple as possible. Still i am aware that this text is hard to read and i could easily write 5 times as much and still only scratch the surface. But i believe that you will find your way through this topic over time.

In the image you see an SL Avatar and the skirt is adjusted to its anticipated location (but not attached). I have also posed the Avatar into a walking pose. However, you see the upper leg pokes through the skirt fabric.

This is because the skirt does not know anything yet about the avatar, neither does it know where the avatar is, nor does it know how the avatar moves. Hence it stays where it is.

So the very first thing we have to do is to attach the skirt to the avatar. In SL you would probably attach it to the pelvis or the Torso. In Blender we will attach it to the Avatar’s rig (the Armature)…

The model skirt (not rigged yet).

Note: You could import this skirt as it is to SL (or OpenSim or similar) and attach it to the Hips or the pelvis attachment point. But when the legs move you will see how they poke through the mesh like in the image above.

Bones and more…

The SL Avatar Mesh

Let us first take a more detailed look on the SL Avatar. Actually the SL Avatar consists of a mesh made out of about 7500 triangles. When it comes to posing and animation all of these triangles have to be moved around somehow. However, it would not be very practical if we had to define the locations of all Mesh faces one by one for every possible pose. And luckily there is a better way to do this.

Bones

The SL Avatar has a small set of 26 control elements (bones) which can be moved separately. And we will see in a moment that each bone controls the deformation (bending and stretching) of a specific area of the mesh. Thus these bones are also named Deform Bones. But one step at a time…

Bone Relations

Bones are not just floating around as a pile of unrelated elements. Bones are attached to each other in a meaningful way. So a lower arm bone is attached to an upper arm bone, feet are attached to legs, toes to feet, etc.

So when you move one bone then all its attached neighbors move along with it so that the “skeletal” integrity of the bone system keeps preserved when you animate the bones.

Remember that the primary goal is to move, stretch and bend the character’s mesh such that it appears to act just like a person (or animal/creature) moving in real life.

The trick is that in fact all 7500 faces (or more precisely the movement of the vertices!) of the Avatar mesh are only controlled by the bone movements. So, where is the missing link ?

How do the vertices know how to move ?

There must be a relationship between the bones and the vertices of a mesh. More precise:

There must be a relationship between each vertex of the mesh and each animating bone.
And obviously each vertex of a mesh has to be moved by at least one bone.
Possibly a vertex could even be moved by more than one bone.
Note: In practice each vertex can be moved by up to 4 bones at the same time (this is a limitation of SL and compatible worlds).

And indeed, this is the missing link: The relationship between the bones and the mesh are the Bone Weight maps. Actually Blender also supports another method for animating the meshes (Bone envelopes) but we can not use this in the context of Second Life.

Bone Weight Maps

A Bone Weight Map defines how much influence a specific bone has on each vertex of a specific mesh. The influence is typically defined in a range from 0.0 (no influence) to 1.0 (maximum possible influence). So if a vertex shows up in a Bone Weight Map, then it will be controlled by that bone. The amount of weight defines if the vertex only slightly follows the bone (weight ~0.0) or moves as if it where glued to the bone (weight ~1.0)

Note: Bone weight Maps are defined per Mesh (as a set of vertex groups, see next chapter)

Visualizing Weight Maps

Weight maps are often visualized directly on their associated mesh by using a color code (where each weight value between 0 and 1 is mapped to a color in a color band. Blender uses by default a color band that maps a weight of 0.0 to the color blue, and a weight of 1.0 to the color red. In between weight values are mapped to the rainbow colors:

Here is an example for the visualization of the Weight Map of the SL Avatar’s mHead bone:
Note: a vertex can be animated by more than one bone in parallel. So it is possible that a vertex can be referenced in more than one Bone Weight Map (thus providing the potential for very complex movements) This happens typically where 2 bones touch each other. In that case the influence is split between the 2 adjacent bones.

SL Avatar Weight maps

Since a Bone Weight Map is always related to a specific bone, that means for the SL Avatar: We have to provide 26 weight maps (one Map per bone) in each mesh that we want to rig.

So a weight map is always related to one bone. And it contains one weight value for each vertex. Well, this is not 100% correct. Actually there is a rule:

The Rule of Zero weights

If a vertex is NOT mentioned in a weight map, then it is assumed to have a weight of 0.0 for the related bone. This rule helps to keep the bone weight maps reasonably small because now the map only needs to contain those vertices which are actually controlled by the bone.

The next image shows areas with different numbers of “weights per vertex” for the SL Avatar. Indeed most areas of the SL Avatar are assigned to only one bone (areas displayed in light grey), while near the joints we always find 2 bone weights per vertex (areas displayed in light green).

Thus the above rule helps to avoid unnecessary clutter in the Weight Maps. Please note that the SL Avatar uses 2 weights per vertex at most!

Weights per vertex.
Grey:1 weight
Green:2 weights

Note: Remember that each vertex has to show up in at least one weight map, otherwise you get an error “unweighted verts in mesh” when you try to import your mesh to SL or compatible worlds.

What else you should know...

There are 3 important constraint which apply to SL (and similar environments):

Each vertex may be controlled by no more than 4 bones. If the vertex shows up in more than 4 weight maps, then the resulting animation behaviour is not defined!
Each vertex must be controlled by at least one bone. Otherwise the SL importer will reject the import.
Each bone MUST have a weight map, even if it is empty. This is a technical annoyance which forces all meshes to provide weight maps for all bones which take part in the skeletal animation, even if they are empty. However, to make it a bit more complicated even, SL only uses only 21 of its 26 skeletal bones. So, actually you only need to provide weight maps for 21 bones (see below for the details).

The SL Bone Weight Maps

The SL Avatar meshes typically uses following weight Maps:

Mandatory Maps (21):

mPelvis
mTorso
mChest
mNeck
mHead
mEyeleft, mEyeRight
mCollarLeft, mShoulderLeft,
mElbowLeft, mWristLeft
mCollarRight, mShoulderRight,
mElbowRight, mWristRight
mHipLeft, mKneeLeft, mAnkleLeft
mHipRight, mKneeRight, mAnkleRight

Other Maps (5):

mToeLeft
mFootLeft
mToeRight
mFootRight
mSkull

Note: In Blender all Weight Maps are stored in Vertex Groups. You find the list of defined Vertex Groups in the Object Data Properties editor.

Fitted Mesh Maps (26):

PELVIS
BUTT
UPPER_BACK, LOWER_BACK
LEFT_PECK, RIGHT_PECK
LEFT_HANDLE, RIGHT_HANDLE
BELLY
CHEST
NECK
HEAD
L_CLAVICLE, L_UPPER_ARM
L_LOWER_ARM, L_HAND
R_CLAVICLE, R_UPPER_ARM,
R_LOWER_ARM, R_HAND
L_UPPER_LEG, L_LOWER_LEG, L_FOOT
R_UPPER_LEG, R_LOWER_LEG, R_FOOT

Note: The Attachment points can theoretically also have Weight Maps. But the usage of attachment points for rigging is discouraged by Linden Lab. Furthermore The SL Default viewer only supports the Import of weightmaps for those attachment bones that have no Space in their name (like “Chin”, “Mouth”, “Nose” for example)

Weightmaps for attachment bones which contain a space in their name (“Left Shoulder”, “Upper Arm”, … ) can currently only be imported with the Firestorm viewer.

All Mandatory Maps must be defined to convince the SL Importer that this is an animated mesh. Even when they are not used at all in your meshes. However, it is sufficient to define the weight maps and leave them empty.

The Fitted Mesh Maps can be used optionally. We will get back to these in a separate tutorials about fitted mesh.

The Other Maps can be omitted if they are not used. (The SL Avatar does not use them, but you can use them for your own meshes)

Note: Avastar takes care that your collada export contains all necessary weight Maps, i.e. it creates empty maps during export when needed. And you only need to define those Weight maps that you really need in Blender. This helps to keep the vertex group lists small and manageable. And you never need to worry if you have defined the empty maps as needed.

Skeletons

From a technical point of view each Bone that has a weight map in a given mesh, also can take part in the animation of the mesh. We call the set of Deform Bones also a Skeleton. However, in Blender a Bone actually has to be enabled as Deform Bone or its corresponding weight map is ignored:

A bone must be enabled as deform bone in the Bone data properties.

In Avastar all skeleton Bones are displayed in Blue:

The Avatar Skeleton (Bones displayed as sticks)

Armatures

The Avastar Rig has many more bones. In detail we find:

Animation Controll Bones (green).
IK Bones (yellow).
SL Base Bones (Deform Bones, blue).
Attachment Bones (red).(1)
Collision Volumes (orange).(2)
Structure Bones (green).

All Bones together are the “Armature”.

Note: From all these bones, only the SL Base Bones, the Attachment Bones and the Collision Volumes should be used for skeletal animation.

All Avastar Bones at a glance.

(1): The use of the Attachment Bones for skeletal animation is discouraged by Linden Lab. furthermore some of the attachment Bones have spaces in their name which results in issues during uploading.

(2): The Collision Volumes have originally been used only for Avatar physics (collision detection) But they can now officially be used as Deform Bones (This is Fitted Mesh, we get to this in more detail later).

Rigs

A Rig is The Animation Control System for a Model. One special Rig Type is the Armature: a Rig based on Bones and used for animating characters by use of a Skeleton. So we actually can either use the term Rig or the term Armature in the context of the Second Life Avatar (and Avastar).

Sidenote: Rigs can also use different methods for animating.
For example it is possible to animate a mesh only by using Empties and Constraints, so no single bone is involved, yet it is an animation system. However we will not get deeper into this here as it is not of importance for SL Rigs.

In a Nutshell:

Bone: Animates other Bones and/or Meshes.
Control Bone: Animates other Bones.
Deform Bone: Animates areas of meshes(1)
Skeleton: Set of Deform Bones plus constraints.
Armature: Skeleton plus Control Bones.
Rig: Animation Control System for a Model (Armatures are Rigs based on Bones).

(1): Deform Bones can also be control bones, for example in a bone hierarchy the parent bones control the child bones.

Armature modifiers

There is one last ingredient missing here. That is we have to tell a mesh that it actually has to be animated by an armature. And this is done with the aid of an Armature Modifier:

An armature Modifier is always created in the Context of a mesh.
Within the Modifier you specify which Armature Object shall control the mesh. You do this in the Armature modifier’s Object field.
Finally you specify if the modifier shall use the mesh’s Vertex Groups or the Armature’s Bone Envelopes.

Note: In the context of Second Life animation with Bone envelopes is not supported, so we always use Vertex Groups here.

Armatures and rigged Attachments

So far we have been talking about Armatures in relation to Avatars. And it has become clear how the Avatar Meshes get animated in principle (by animating the Avatar Skeleton). But what about attachments ? How do they fit into the overall picture ? Well, it could best be described as:

Attachments are specialised characters

What? That sounds weird… but actually it is a correct picture. See this:

Any rigged attachment needs a rig.
The Rig must be compatible to the SL Avatar’s Armature,
Thus the rig can only contain the Bones which are also defined for the SL Skeleton.
And since the SL Importer only accepts complete skeletons, any mesh attachment needs to be rigged to a complete skeleton as well,
Thus a Mesh attachment is technically a complete rigged character.

Example: Boots rigged to the SL Avatar Rig

The good news is: All that we have learned above also applies fully and without any change to mesh attachments. Hence we can treat our attachments exactly like we treat the SL Avatar.

However: Mesh Attachments never get their own bones when they are later attached to the SL Avatar. They just “bind” to the already existing SL Avatar’s skeleton.

So at any time, regardless how many Meshes an Avatar wears, there is only one single skeleton involved to which all meshes are Bound.

Rigged Mesh & Attachment Points

So, every rigged attachment has to be rigged to the exact same Skeleton as the SL Avatar. So in fact a mesh attachment is handled in exactly the same way as a mesh character. And technically there is no difference between the SL Avatar, a complete Mesh character and a Mesh attachment. All of them get controlled by the same rig in the exact same way.

While the SL Avatar just “exists”, the Mesh attachments and Mesh based Avatars have to be worn “on top of the SL Avatar” by attaching them to an attachment point. Yes, even a mesh character has to be “worn” on an attachment point of the SL Avatar!

The difference of Prims and Rigged mesh

There is one important difference between attaching Prims and attaching rigged mesh. That is: A Rigged mesh actually attaches to the Avatar skeleton as a whole, regardless to which attachment point it has been attached.

So even when you attach your pair of boots to the head attachment point, they will still work as anticipated, because the attachment point’s location is simply not relevant at all for rigged mesh.

And for SL and compatible worlds it is as easy as that: A rigged mesh always uses the pre defined Avatar Rig. Consequently we have to provide the complete set of 21 weight maps for the 21 major bones. Always! ALWAYS! No exception!

Putting all together

So what we have to do next is to combine what Avastar provides (the SL Armature) with your mesh attachment (in our case the demo skirt). In particular we have 2 tasks:

Associate our Mesh to the Avastar Rig so that both know each other.
Create/Modify/Optimize Bone weight maps which define the relation between the skeleton bones and particular areas of your mesh.

This process is named : Skinning And this tutorial is actually about skinning.

Blender: Parent Armature deform

Blender has a tool for half automatic skinning a mesh to a Rig (Parent Armature Deform). This tool basically does 3 tasks (and this is in principle all you need):

It parents the Mesh to the Armature.
It creates an Armature Modifier.
It creates a set of weight maps for the Armature’s deform bones.

Blender’s tool is used as follows:

Ensure you are in Object mode.
Select the Mesh Object that you want to animate.
Shift Select the Armature Object.
Object -> Parent -> Armature deform.

Now you can select between creating empty weight groups, or generating initial weight groups either from Bones or from Bone envelopes. Please check the Blender Documentation for details.

Avastar uses the automatic tools internally but it also adds a few more handy options for your convenience (see further down). I am at the end of the fundamentals of skinning. In the remainder of this tutorial we will get into practice.