Unable to Read Animation File Incorrect Root Joint Name Use Hip

The SL Skeleton

Creating the Avatar Workbench and Avastar has given us not bad insight on the SL avatar. The goal of this article is to give yous detailed information about the construction of the Second Life avatar and what y'all tin can do with it.

Nosotros will too talk about some areas where nosotros simply do not know what happens, or where there are inconsistencies and the techniques are highly experimental. Nosotros'll update the page equally we learn more.

This page includes the Bento Bone definitions which will come up to the Second Life main filigree former this year (2016)

In a nutshell…

The 2nd Life Skeleton supports:

Basic Bones

• 26 Basic bones
• 32 Basic Attachment Points
• 26 Collision Volumes

Extended Bones

• 104 Extended Bones
• 13 Extended Zipper Points

The Skeleton is further controlled by a set of 120 Shape parameters (Accessible via the Advent Editor in the SL Viewer) to define the character'south full general Shape (alpine-tiny, fat-slim, muscular-shape, etc…)

Conceptual information

The Base Skeleton

The skeleton uses 26 bones for driving

• the body (split into ii meshes upper and lower),
• the head and hair meshes,
• the skirt mesh,
• the eye meshes.

Notation: v Basic are not used for weighting of the Organization Avatar. The bone names are displayed in Cyan blue in the Listings below.

The 26 Base Bones

The defined Base Bones are:

• mEyeLeft
• mCollarLeft
• mShoulderLeft
• mElbowLeft
• mWristLeft
• mHipLeft
• mKneeLeft
• mAnkleLeft
• mFootLeft
• mToeLeft

• mSkull
• mHead
• mNeck
• mChest
• mTorso
• mPelvis

• mEyeRight
• mCollarRight
• mShoulderRight
• mElbowRight
• mWristRight
• mHipRight
• mKneeRight
• mAnkleRight
• mFootRight
• mToeRight

So simply 21 base bones are effectively used to create animations for the system Avatar, and just these bones are associated with weighting data for the Base Bones of the Avatar. That is, fifty-fifty if yous breathing the remaining five bones, the animation will not contribute any skin movement to the arrangement Avatar.

However, we will run across later that you can employ all 26 bones for weighting and animating your own custom meshes.

Side note: Mesh attachments and complete Mesh characters are handled in exactly the same way, so any is true for Mesh attachments is also valid for consummate characters.

The Extended Skeleton

The Bones Skeleton is just capable to breathing very unproblematic movements. Big portions of the mesh are but left out and can not be animated in particular (at to the lowest degree not directly, see below) Especially non homo creatures tin not be nicely animated simply with the base Skeleton. This gap is filled by the Extended Bones, a set up of 104 extra Bones which are organized into 5 Subsets:

Face up Bones: (44 regular bones + Face Root)

The face up rig is connected to the SL Appearance Sliders. That is the Confront bones motility along with the Appearance sliders. So if your mesh characters are weighted to the Face up bones, then many of the face appearance sliders now also affect your character expect.

Only annotation that the shape sliders touch on bone location (bone translation). So the confront shape may be affected past custom animations as well (see below for details).

Avastar: Face Weight Generator

We have created a Face Weight generator, a tool that is aimed to help creating weights more like shooting fish in a barrel. Withal this tool is a fleck experimental. It might piece of work well or non for your particular mesh creations.

Calling the Face up Map Generator

You find the generator in the Weight Map Control panel within the Toolshelf (You need to open the Avastar vertical Tab first and your mesh must exist in weight paint mode)

Tweaking the Maps

In one case you called the Generator it will operate on the weight maps for the selected bones and when done information technology opens an Operator Redo panel at the bottom of the Tool shelf. At that place you tin tweak the parameters further to optimize your weight maps.

An animation pitfall

The Face bones are used past the appearance slider organization to adjust the facial shape as well for mesh heads. But the bones are besides moved by the Second Life blitheness system. This results in a possible dependency between the Face Shape and facial animations (smile, frown, …).

Rotation Animation

Every bit long equally an animation only uses os rotations the animation plays on summit of the shape and the facial shape volition be more than or less preserved while the animation plays.

Translation Blitheness

The SL blitheness system also allows to use Translation animation. Notwithstanding this interferes strongly with the appearance slider arrangement.

An blitheness that modifies bone location while playing volition ever destroy the confront shape while playing.

We recommend that you employ only rotation blitheness when you attempt to create reusable (shape independent) animations.

Note for Avastar users

You tin enforce to export only rotation channels when you lot use the Avastar .anim (or .bvh) exporter (run into image):

When you disable the Option "Apply Translations" then the exporter merely exports rotation information. But note, this tin potentially stop up with unexpected results when y'all later play the animation on your character.

side note: We may need to add some work into the exporter to map transition changes into bone rotation changes (which can be washed if the local root bones are not moved)

Confront Bones (46)

• mFaceEyeAltLeft
• mFaceForeheadLeft
• mFaceEyebrowOuterLeft
• mFaceEyebrowCenterLeft
• mFaceEyebrowInnerLeft
• mFaceEyeLidUpperLeft
• mFaceEyeLidLowerLeft
• mFaceEyecornerInnerLeft
• mFaceEar1Left
• mFaceEar2Left
• mFaceNoseLeft
• mFaceCheekLowerLeft
• mFaceCheekUpperLeft
• mFaceLipUpperLeft
• mFaceLipCornerLeft
• mFaceLipLowerLeft

• mFaceRoot
• mFaceForeheadCenter
• mFaceNoseCenter
• mFaceNoseBridge
• mFaceNoseBase
• mFaceLipLowerCenter
• mFaceLipUpperCenter
• mFaceJaw
• mFaceJawShaper
• mFaceChin
• mFaceTeethLower
• mFaceTeethUpper
• mFaceTongueBase
• mFaceTongueTip

• mFaceEyeAltRight
• mFaceForeheadRight
• mFaceEyebrowOuterRight
• mFaceEyebrowCenterRight
• mFaceEyebrowInnerRight
• mFaceEyeLidUpperRight
• mFaceEyeLidLowerRight
• mFaceEyecornerInnerRight
• mFaceEar1Right
• mFaceEar2Right
• mFaceNoseRight
• mFaceCheekLowerRight
• mFaceCheekUpperRight
• mFaceLipUpperRight
• mFaceLipCornerRight
• mFaceLipLowerRight

Hand Basic (15 per Mitt)

The mitt basic are very closely adapted to the System graphic symbol hands. This will let to create animations for mitt gestures very similar to what the System character can do. But since animations are completely costless, you can breathing the hands to practise whatever you lot similar.

Avastar: Constrained FK and IK Rig

When you use Avastar and so you get 2 extra features for easy hand animation cosmos, that is:

• Constrained FK: Allows you to curl fingers in a natural style by grabbing the finger root bone and rotate it along the bone's local X axis
• IK: Allows to place IK targets to which the finger tips approach (and keep glued to)

The paw Basic are:

• mHandMiddle1Left
• mHandMiddle2Left
• mHandMiddle3Left
• mHandIndex1Left
• mHandIndex2Left
• mHandIndex3Left
• mHandRing1Left
• mHandRing2Left
• mHandRing3Left
• mHandPinky1Left
• mHandPinky2Left
• mHandPinky3Left
• mHandThumb1Left
• mHandThumb2Left
• mHandThumb3Left

• mHandMiddle1Right
• mHandMiddle2Right
• mHandMiddle3Right
• mHandIndex1Right
• mHandIndex2Right
• mHandIndex3Right
• mHandRing1Right
• mHandRing2Right
• mHandRing3Right
• mHandPinky1Right
• mHandPinky2Right
• mHandPinky3Right
• mHandThumb1Right
• mHandThumb2Right
• mHandThumb3Right

Tail Basic (6)

Not much to say here.

Avastar: IK Rig

When you utilize Avastar then you besides get an IK Meta rig for the tail: But grab and motion the tip around and the other bones follow nicely.

The tail Basic are:

• mTail1
• mTail2
• mTail3
• mTail4
• mTail5
• mTail6

Hind Bones (2*4 plus Hind Root Bone)

Not sure how we will support this inside Avastar (We need to practise some experiments first, mayhap add IK Targets for the hind feet?)

• mHindLimb1Left
• mHindLimb2Left
• mHindLimb3Left
• mHindLimb4Left

• mHindLimbsRoot

• mHindLimb1Right
• mHindLimb2Right
• mHindLimb3Right
• mHindLimb4Right

Fly Bones (2*five plus Wing Root Bone)

Not much to say here.

Avastar: IK Rig

When yous use Avastar then you an IK Meta rig for the Wings: Just grab and move the tips around and the other bones follow nicely.

The Fly Bones are:

• mWing1Left
• mWing2Left
• mWing3Left
• mWing4Left
• mWing4FanLeft

• mWingsRoot

• mWing1Right
• mWing2Right
• mWing3Right
• mWing4Right
• mWing4FanRight

Spine & Groin (4+1)

Note: The Spine bones are folded into the legacy Skeleton and tin be unfolded for custom rigs (you need to upload with Joint Positions enabled in that case)

The Extra Spine and Groin bones are:

• mGroin
• mSpine1
• mspine2
• mSpine3
• mSpine4

120 Advent parameters

The character can be shaped to a big extent by using the SL appearance editor. The shape parameters can be changed by use of shape sliders.

Inside the appearance editor y'all find 3 sections with 23 shape parameters for the trunk, trunk, and legs. Some other 6 sections with 55 shape parameters for eyes, ears, and rima oris, as well as for the olfactory organ, chin, and the head course. In add-on at that place are 42 controls for the clothes morphs.

Body	3	Shirt	7
Body	12	Pants	6
Legs	8	Socks	1
		Shoes	seven
Head	11	Jacket	6
Optics	11	Skirt	seven
Ears	iv	Gloves	2
Nose	xi	Undershirt	4
Mouth	nine	Underpants	2
Chin	9

When y'all just work with the default avatar, so you can create pocket-size and fat avatars as well as large and slim characters but by adjusting the shape parameters according to your taste. You can practise all of that in your Viewer without need to utilize an external 3D tool.

However, when you use Custom Meshes then some different rules employ…

Mesh and Appearance Sliders

If your 3D world supports mesh items (like Second Life, OpenSim, RealExtend, inWorldz and others…), yous also tin create your ain grapheme meshes. You lot can create mesh based attachments for either the standard character or for your own mesh based characters.

Simply keep in mind that your own mesh creations react differently to the Shape keys.

In fact only the bone changing shape parameters influence the mesh based attachments and characters. That is, mesh attachments can not exist fully customized by using the Shape sliders. This restriction can be a major problem with mesh attachments.

Shape and Skeleton matching

It is important to ever remind that your Avatar Shape settings in your viewer effectively modify your skeleton'southward joint positions and Os Scales. This is controlled via 20 of the available shape parameters (appearance sliders) for the Legacy Skeleton and 40 boosted parameters for the Extended Skeleton (mostly for the Face expressions and Hands).

And then if yous want to create a specific mesh attachment for a specific shape then you need to know exactly how the shape values are related to the articulation positions (and bone scales) of your item shape. But this information is normally non available outside of Second Life.

Fortunately you can get around this problem by using the SL Restpose for your work in your 3D Editor. Yet this ways yous create your content by using the Second Life Restpose which does never match the actual Shape that you utilise in Second Life.

Really nosotros want to create attachments which can exist adjusted (fitted) to any shape. This is where the Fitted Mesh add-on steps in. The basic thought is to allow more Appearance sliders control the mesh. This is done by using the Fitted Mesh bones, or more precisely the Collision Book Bones to the mesh.

Shape parameters influencing the Base skeleton

The listing of os length irresolute Shape keys. Please annotation, the shape keys marked in orange do as well influence the Collision Volumes (see next chapter)

Department	Shape parameters
Body	Acme, Body thickness
Head	Caput Size, Head Shape, Head Length, Face Shear
Eyes	Eye Size, Middle Spacing, Eye depth
Torso	Neck Thickness, Neck Length, Shoulders, Arm Length, Hand Size, Body Length
Legs	Leg Length, Hip Width, Hip Length
Shoes	Heel Height, Platform Height

Collision Volumes (Fitted Mesh)

The default avatar uses 24 additional and then called Standoff Volumes. These are simplified mesh volumes for calculating when an object or some other avatar is bumping into a graphic symbol. In fact the Collision Volumes are a set of 24 Octahedrons which get influenced by diverse shape sliders.

Interestingly these volumes are also counted as full basic, and they can exist blithe and weighted just similar the standard basic. The most interesting belongings of these bones is that they become moved and scaled by some of the shape keys. Weighting mesh apparel or avatars to these bones means they volition respond to the Shape keys, for example Trunk muscles.

Just annotation that simply a very small fraction of the Shape sliders actually does influence the Collision Volumes. thus you can non expect to become a full command over your mesh object past using the Standoff volumes. For example irresolute the breast shape is not at all mapped to standoff volumes. Likewise as facial expressions are not supported.

All 24 available collision volumes:

PELVIS, BELLY, BUTT, LEFT_PEC, RIGHT_PEC, CHEST, LEFT_HANDLE, RIGHT_HANDLE, 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, L_FOOT

Shape keys and the Collision Volumes

This is the list of Shape keys which exercise affect the Standoff Volumes. Please annotation, the shape keys marked in orange do also influence the Os length (see previous chapter)

Torso	Meridian, Trunk Thickness, Body fat
Caput	Head Size, Head Stretch, Head Length
Torso	Torso Muscles, Neck Thickness, Neck Length, Shoulders, Arm Length, Paw Size, Body Length, Love handles, Abdomen Size
Legs	Leg Muscles, Leg Length, Hip width, Hip Length, Butt Size, Saddle Bags, Knee Angle, Foot Size

Modifying the Skeleton

We already know that we can modify the Second Life default Skeleton by using the Appearance Sliders. But this is not all we can practise. In fact it is possible to rearrange the Skeleton in any manner nosotros desire. There are only 3 basic rules:

• We can only use the existing gear up of Joints (bones).
  We can non add together new joints to the Skeleton.
• We must keep the hierarchical Articulation construction as it is.
  We can not rearrange the articulation bureaucracy of the Skeleton.
• Nosotros are free to move the existing Joints wherever we desire.

In outset identify this might audio like a strong limitation. Simply you quickly see that you lot can create a wide diversity of creatures just by rearranging the existing bones. However there are a few things you need to know earlier you lot leap into the deep waters…

Joint Offsets

As mentioned before we only tin can rearrange the location of Joints but not their relationship. Because of this we always tin define a modified skeleton only by recording how far each Articulation has been moved away from its original location. This distance is the Joint Offset

So one way to define the modifications of the Skeleton is past recording the Articulation offsets for all Joints (the small dots in the paradigm on the right side).

The image shows the default SL Skeleton in its T-Restpose (the orangish skeleton). And a modified Horse Skeleton (the grey Skeleton). The blue lines marking the offsets from original joints to the modified joints.

For Blender users:

Blender uses Bones with a Head and a Tail. the Head is very similar to what other programs name Joint. The Tail is not supported by other programs. The dots at the finish of a bone chain are always bone tails, then those terminal dots are not Joints!

Defining Joint Offsets

The good news is: You only need to motility the joints of your Skeleton into place. For Blender users: Y'all can do this by selecting your Skeleton (the Armature) in EDIT mode and then move the basic one by one.

So, how does Second Life know if a Skeleton uses joint offsets? The 2nd Life importer decides this for each joint by checking if its location is close to the default joint location of the SL Skeleton in Rest pose. As soon as a joint is offset by more than 0.1 millimeter it is counted as a joint with first.

Annotation: The joint offsets are simply checked when you enable "with joint positions" in the SL Importer's Option tab.

Create your modified Skeleton by moving the joints 1 past one into identify.

Checking your joints in the Viewer

The SL Viewer allows you to display the Skeleton Bones. Yous enable the bone brandish in the Develop bill of fare under:

Develop -> Avatar -> Prove Bones

• Joints are displayed as minor dots (pink in the image for ameliorate visibility)
• Weighted Joints without Joint offset are displayed in Cyan
• Weighted Joints With Joint outset are displayed in Reddish

The SL Viewer shows the Joints at their expected locations. Merely the bone orientation (the colored lines) are ever taken from the Restpose Skeleton.

The model shown in the image higher up has only its right arm edited into an A Residuum Pose. You lot can see the joint locations are displayed where we expect them to be. But the Bone orientation (the lines) are not rotated as you might wait.

If you accept a closer look into this then you notice the Bones orientation is ever taken from the Restpose orientation. Because of this the basic of the correct arm practice non line upward as expected only signal to the right (left from your point of view).

here you lot come across how the "basic" are just translated (moved) from their original locations to the offsets.

A surprising behavior

The Appearance slider behavior depends on whether a joint has offsets defined or non:

• For regular joints (without offsets) the advent sliders can influence the joint location (Translation) and the Calibration
• Equally soon equally a joint has an offset, the Translation function is disabled

Merely you also must know that the orientation of the Joint scaling does not alter. This is of import every bit you lot can see in the image aside. In this case the right arm has been edited to point straight downwards. While the left arm remains unchanged.

This results in desperate differences how sliders influence the arm length.

The scaling orientation does not change for joints with objects. This can outcome in very unexpected behavior. Here you lot see how the arm length slider changes the length of the correct arm and the thickness of the left arm.

You tin verify the arm length slider changes the length of the left arm (every bit earlier) but the thickness of the correct arm (very unexpected, but works as designed).

And a nasty Pitfall

Now lets turn dorsum to the horse from our initial case (see above). Lets say the mChest Bone of this horse has not been used for weighting the mesh (only equally an example). The mChest bone lies in the middle of the Bone chain that starts at the mPelvis and ends at the mHead

Since Bento it is possible to only import partial skeletons. Particularly you lot can decide to only export the weighted basic of your character (because unweighted bones are non used for deforming your mesh). So, when you import this horse with the Bento Viewer, so the mChest bone is not imported. Merely…

During importing your character all "missing" bones are taken from the original skeleton. Only the SL Importer has no way to observe out where the mChest bone has been placed in the original model. And so it simply keeps the mChest os at its default location . And this results in a skeleton where no joint position is divers for the mChest.

And this is evil! The trouble is with the Appearance sliders: In that instance whatsoever articulation translations (location moves) divers in the appearance sliders are not practical to bones with articulation positions.

So fifty-fifty if the mChest bone plays no role in the grapheme weighting (in our case) it notwithstanding affects all its children as far equally advent sliders are concerned, because information technology reacts unlike to the appearance sliders when information technology has no joint beginning defined.

Now you wonder why this is of import fifty-fifty if you do non at all employ the appearance sliders? In fact the appearance sliders take effect fifty-fifty when yous vesture a default shape. Simply this is another story.

What about Pin and POS

You may have seen that Avastar supports two Joint Types, namely PIVOT and POS. But what is that and how practise nosotros piece of work with this? In fact this is 1 other source of misunderstanding, misbehavior and its quiet badly understood by everybody, fifty-fifty past LindenLab them self (i believe).

In curt POS and Pivot are 2 definitions of the Secondlife Rig which are virtually identical only differ a tiny bit from each other. The reason for why those 2 rig definitions exist is unclear and cached somewhere in aboriginal history of Secondlife. Beneath you find an extract of the Rig definitions. The values are iii dimensional vectors. Each vector defines the distance to the parent joint:

              Bone                mCollarRight                mShoulderRight                            mElbowRight              mWristRig            

                              Pivot-Rig location offsets                -0.020927                            -0.085000                              0.165396                            0.000000                                  -0.079418                                -0.000000                              0.000000 -0.248000 -0.000000              -0.000000 -0.205000 -0.00000                          

               Pos-Rig location offsets                -0.021                            -0.085                              0.165                            0.000                                  -0.079                                -0.000              0.000 -0.248 -0.000              0.000 -0.205 -0.00            

For example the mElbowRight articulation is exactly 0.248 g (24.eight cm ) away from the mShoulderRight joint in both Rigs (see image)

But  the joints mCollarRight and mShoulderRight are placed at slightly unlike locations in both rigs (meet the numbers in the table)

I take marked the differing numbers in orange boldface.

So what?

First of all the 2 Rigs are actually used for different purposes:

POS Rigs

Are only used by the Secondlife System character. The POS Rig is declared as the one Rig that has no Joint Offsets.

And so when you import a mesh that was rigged to a clean POS Skeleton then even if you Import with Joint Positions the SL Import willl correctly see that at that place are no Articulation offsets at all defined in the rig.

Pivot Rigs

Are simply used by the Custom Mesh attachments and Custom Mesh characters.

And so when y'all import a mesh that was rigged to a clean Pivot Skeleton so the SL Importer detects falsely that some bones accept Articulation offsets.

The following 2 rigs both have been created with default Rig values and imported with Articulation Positions. Bones with Joint Offsets are marked in Red.  Y'all see the POS Rig imports cleanly but the Pin Rig exposes Articulation offsets although its a perfect clean PIVOT Rig:

A POS Rig imported with Joint Positions

A PIVOT Rig imported with Joint Positions

And hither is the Double Salto Mortale

Remember what i said about when is which rigtype used? Here is it again:

• POS Rigs are only used for the Arrangement Character
• Pin Rigs are merely used for the custom Mesh Characters

And then as a consequence here is the starting time Salto:

When you lot use a clean POS Rig for your mesh grapheme then an import with Articulation offsets works just fine and correctly detects there are no joint offsets in the rig. But the Mesh gets bound to a PIVOT Rig and so you will see mismatches when you compare to the System Grapheme.

When y'all utilize a clean Pivot Rig for your mesh character then an import with Articulation offsets uncorrectly detects joint offsets for some basic. Just the Mesh gets spring to a PIVOT Rig then it will match better when you compare it to the System Graphic symbol. Just in that location are nevertheless mismatches… why?

And here is the 2d Salto:

When a Bone has a Joint Offset then it gets treated slightly dissimilar by the Appearance system. Technically it loses the ability to follow translations.

That means for the Collar bones and Shoulder bones: When y'all move the  Torso Shoulders Slider and so it just does non work any more. And this has major consequences and y'all terminate upwardly with a shape that no longer matches to the System grapheme mesh, even when the mesh itself does lucifer perfectly on vertex level.

Summary

2d Life uses 2 slightly different Rig definitions for the System character and for your Custom meshes. Also Bones with Joint Offsets bear different from Bones without Joint Offsets. Then …

• Forget to make Mesh characters by using the POS Rig. Otherwise you lose precision in the meshes.
• Forget to import clean PIVOT Rigs with joint offsets. Otherwise you loose precision in the meshes.
• The simply reliable way to get good results: Utilise clean Pin Rigs and avert using Articulation offsets when you try to lucifer items to the system character

Zipper Points

Likewise the 26 standard bones and the 19 Collision Volumes we have attachment points. An attachment point is but a location where yous can attach (wearable) other objects. The locations of the attachment points are fixed relative to a particular bone in the skeleton. Thus you might believe that at that place is non much to say nigh these points, but technically the attachment points are just another set of basic in the skeleton.Indeed it is possible to animate zipper points in the same way every bit yous can animate the skeleton bones, and anything you've attached to those points will go on for the ride with the animation itself. These bones tin can as well be used for weighting custom meshes just like the standard fix of bones.

Limitations alee!

By experimenting with these bones nosotros found some undesirable side furnishings, which may be due to the fact that weighting and animating these basic has never been seen as a valid option.

The main limitations we've discovered are:

1. Some attachment points have spaces in their name. Collada 1.4 doesn't support bone names like this consequently a bone like "Left Shoulder" is interpreted by the Collada Importer as 2 basic with the names "Left" and "Shoulder" respectively, thus the Collada information will be invalid.
2. There is no rotation reset. Unlike the normal basic, stopping an attachment os animation will leave the bone in the final rotated position. To fix you need to run an animation which rotates the bone to zero once again.
3. Again unlike normal bones it doesn't announced possible to modify the location of the bone with a custom mesh import (Adding joint offsets to zipper bones). Either it gets ignored or the unabridged armature gets distorted.

We believe that your viewer should be able to use the attachment points exactly like all the other bones, and thus give us 32 extra possibilities for weighting and animating our meshes, and that the existing limitations should exist viewed as bugs. Just currently information technology is not possible to weight attachment points in a reasonable (safe) style.

What we have so far

So we have effectively 77 bones bachelor for animation and rigging. Furthermore 20 Shape keys do influence bone lengths, and 23 shape keys do influence the Collision Volumes. All together (when combining the os shape keys and collision volume shape keys) we notice that xxx Shape keys do influence the mesh and its skeleton provided it is correctly rigged and weighted.So far this is what we institute by inspection and experimentation and this reflects our current cognition almost the Skeleton. In the following chapter we will accept a closer await on applied issues.

Summary

The Skeleton and the associated Shape key organization provide:

• 26 standard basic
• 32 attachment points
• 24 collision volumes
• 120 Shape keys

thirty of the shape keys influence the Mesh and/or the Skeleton and thus they tin be used for express customization of custom meshes.

Practical observations

Rigging and Weighting

Lets take a look at an instance.

This is a depression poly mesh made for game engines. When nosotros want to prepare this mesh for our 3D globe, so we have to exercise following preparations:

1. First nosotros need to setup the skeleton itself.
   Here nosotros have to take care nigh the os hierarchy and virtually the exact os names. Otherwise the skeleton is rejected by the mesh importer within your viewer. Nosotros believe that you tin observe an advisable rig for each of the major 3D editors.
2. At present nosotros need to find the best fitting Shape for the character.
3. Then we have to add together animation data, that is, we take to weight the mesh confronting the 21 standard basic.
4. Finally we take to become our creation into our online world. This is done by exporting the mesh from your 3D editor to a Collada file. We provide Collada 1.4.i here (This is uniform to 3D worlds which use the skeleton described in this document). The used file extension is ".dae".

There are some caveats in this process, which might lead to more than or less serious issues with your mesh. You lot have to take care nearly:

1. Your mesh must always be weighted to all 21 Skeleton bones. That is, you accept to provide weight data for each bone, regardless whether it is used in your mesh or not. And that means, you accept to provide all appropriate weight groups, although they may exist empty. If but i of the weight groups is missing, and then the mesh will be rejected.
2. Your unabridged mesh must exist weighted. If only one vertex is non independent in whatsoever of the supplied weight groups, and so the mesh volition exist rejected.
3. In nearly 3D editors y'all must ensure that your character looks towards the positive X axes when it gets exported. Otherwise you may end up with massive distortions when you wear the character
4. If you import a mesh with all vertices weighted to nada, then this mesh disappears every bit soon as you wear it in the online earth. However you can rezz it with no problems.

On a special side note: Although the mesh Importer supports the import of textures forth with the mesh, this functionality is currently broken for rigged meshes.

Wearing a rigged mesh

Once yous have successfully uploaded your mesh to your 3D earth, yous can wear information technology simply like whatever other object by attaching it to an attachment betoken. Nevertheless rigged meshes are somewhat special, as you lot can habiliment them at any attachment point you like. If the mesh is properly created (weighted) and then it will self arrange to the skeleton.

Cancel out the Skeleton Shapes

Here is what y'all would need to do in principle if y'all desire to create mesh attachments which fit exactly to your in world Shape (attending, this is mind extraordinary):

1. You have to know which shape configuration you apply in world. Particularly you need to know the values of the 20 Shape parameters which affect the Skeleton.
2. You calculate the skeleton configuration which results when applying the shape parameters and setup your skeleton accordingly. This is your working skeleton.
3. You setup the working skeleton in your 3D editor and use it to create your mesh attachment.
4. When you are done, you have to summate the deviation from your bodily mesh attachment to how it would have looked alike if you had created it for the default skeleton configuration. And you lot have to use that divergence to the mesh. This defacto rebases your work from the working skeleton to the default skeleton. The reason why you take to practise that, is that the skeleton shape parameters are already "practical" to your working skeleton. So if y'all would now just upload your mesh as it is, then these parameters keep practical and when you wear the mesh, your in world shape volition apply the parameters again. And that ways your xx Skeleton shape parameters would be applied twice. Delight besides note that the default skeleton differs for male person shape and female shapes.
5. Now you export the rebased attachment to your 3D earth.
6. Now y'all tin article of clothing the mesh. And if you lot also wear the correct shape (which y'all used in step one above) then the shape parameters become applied to the mesh and it at present fits 100% and looks exactly like you created information technology in your 3D editor.

Nosotros are proud to tell yous that our Avastar product does all of that for yous automatically in the background. And then you practice not need to carp with this at all. Simply it may be skillful to know about that issue when you intend to create your own mesh exporter tool.

kauperwhishor.blogspot.com

Source: https://avalab.org/avastar/279/knowledge/the-sl-skeleton/

Share :