Friday, 18 December 2015

Oh happy day!

The news this week of the upcoming new set of extended bones for SL is extremely exciting, made even better by the announcement from Machinimatrix that Avastar 2.0 beta is now available. For existing owners it's a $15 update to Avastar 1.x which, in my opinion, is quite reasonable considering all the new additions. Something this exciting, I was unable to resist...

And I though you might like to see the details of the new facial animation bones:

In this picture I hid all the bones on the right side of the face so you're only seeing the ones that lie on the axis (mouth, tongue, center nose) and the ones on the left side. I also hid the old mHead and mSkull bones so you're only seeing the newly added ones.

I'm glad that this is available already because I can see it's going to take me many, many hours to get all of my weighting done for my avi. Hopefully by the time the viewer support is available from TPVs and whatever needs to be adapted is done at the Opensim end, I'll have my avi ready.

Colour me excited!

Thursday, 10 December 2015

RELEASE: Paramour Eye Controller Posing HUD

I'm happy to announce the release of a little utility HUD for Opensim portrait photographers that allows you to control your subject's eye direction. It doesn't control their viewer's camera, just the in-world direction their eyes are looking.

When you wear the HUD you'll first need to identify who's eyes you want to control by clicking the HUD's "Target" button. It will supply you with a list of the 10 closest avatars or NPCs, (as well as yourself). Simply pick one.

If you pick someone else's avatar they'll receive a pop-up dialog requesting permission for you to take control of their eyes. For yourself or NPCs, permission is automatically granted (but for a NPC that wasn't created by a script you own the controller script may or may not have sufficient permission to animate).

Once you have permission the HUD will be active and respond when you touch the picture of the eyeball, making the subject's eyes look in approximately that direction.

This is done using a set of 55 custom eye position animations that I created, giving you an array of locations that's 11 wide and 5 high to choose from. The subject will continue to look in that direction until you pick a new one (but they will continue to blink once in a while). The animations are priority 5 so they shouldn't be overridden by any other animations you play unless they're also a very high priority and include eye positions.

When you're done, please remember to click the green "ON" button to turn it off again and release animation controls over your subject's eyes. When you remove the HUD it will attempt to do so automatically but depending on region traffic this can occasionally fail so it's best to manually release first. They can also be canceled by the subject using the viewer's Avatar Health control to stop animations.

You can pick a different target at any time during use. This well release control of any existing subject and request permission from the next.

The script uses OSSL functions so you'll need to have permission to use those in the region you're doing the photography in. The functions used are:
  • osGetAvatarList()  used to build the list of possible targets
  • osIsNpc() used to check whether your subject is an NPC who auto-grants permission
  • osAvatarPlayAnimation() and osAvatarStopAnimation() used to control the actual animation
If you have any of my other products these will probably already all be enabled in your region.

You can pick up a copy from my Paramour Shopping region by HGTPing to RefugeGrid.com:8002 then taking the local portal to Paramour Shopping. It's on the wall in the central pyramid where you'll find many of my other utilities (you might want a copy of my photographer's lighting kit too).

As always, it's free.

Enjoy!

Tuesday, 1 December 2015

Hedonism Temporary Closure Dec 7-10

Since there are still quite a few people who go to my Hedonism club to pick up copies of my danceball and other club items I thought I should give a head's up about the region having a planned period of inaccessibility next week.

I'll be hosting my usual Sunday evening party there on Sunday, Dec. 6 then sometime on Monday morning (Dec. 7th) I'll be closing it for several days while the region is replaced with a special Bunker Lounge build for my special "One Night Only Event" and receives some final tweaks. While I'm doing that work there will be no public access to the region and you'll receive a "you aren't authorized to tp here" message if you try to go there, even though it shows as being online.

I expect to re-open the region to the public either late Thursday evening or early Friday morning (Dec. 11th). The big event is in Sunday Dec. 13.

The various products that are normally in the Hedonism Club's lobby will not be included anywhere in the temporary new build but they are all available in my Paramour Shopping region which you can get to by HGTP to RefugeGrid.com:8002 then take the portal to Paramour Shopping. I will also put a portal from the Lounge to the shopping region.

I expect to leave the Bunker Lounge build up in Hedonism region throughout the month of December, then in early January I'll be reverting back to the normal Hedonism Club. At that time I will probably permanently remove the club products from the lobby anyway, keeping Paramour Shopping as the only place I have the boxed "sale" copies.

Sorry for any inconvenience this might cause.

Wednesday, 25 November 2015

FYI: Blender 2.76-2.76b bug for "Weight Transfer: Nearest Face Interpolated" has been fixed in latest nightly build

For those who read my previous tutorial on Weight Transfer and/or my series of tutorials on rigging and weighting, I mentioned I'd been struggling to figure out an issue with the "Nearest Face Interpolated" option for weight transfers.

This method had been my "go to" option under 2.75 because, more than any other method, it produced the best starting points for the majority of my transfers; but after some changes to the way weight transfers work in 2.76 I'd been struggling to get consistent results.

It turns out that this was due to a bug introduced as part of other changes to the function and these have now been corrected in the latest beta build. Any nightly build Nov 25th, 2015 or later should include it, and it will be included whenever the next official public build is released.

If you're doing a lot of rigging and weighting and want to take advantage of the function, you can either revert to 2.75 or work using a recent beta (although the betas may have other new bugs introduced by other code changes).

Saturday, 21 November 2015

TUTORIAL: Principles of Blender Rigging and Weighting - Part VIII

This is the eight and final part of my series of tutorials on rigging and weighting in Blender for objects destined for use in Opensim. You'll find links to Parts I-VII on my main tutorials page. In final installment I'll be talking about tri- or quad-weighting meshes -- why one might wish to do so and what sort of strategies tend to be the most productive.

As you might recall from the end of Part VII, these are terms I use to indicate the number of bone weights involved for an area of vertices and not the face shape of the mesh's polygons. A "tri-weighted" area of a mesh is one where each vertex is assigned to three different bone groups, and a "quad-weighted" one has four.

With the default SL avatar the vast majority of the vertices are weighted to either one or two bones. It might even be all of them since I can't think of any vertex with three weights. Towards the extremities of the armature that makes perfect sense and looks fairly natural in-world (if one ignores the fact that the human body is far more articulated than an avatar).

Using the arm as an example, you'll see that all the vertices of the hand are fully weighted to only the mWrist bone, the majority of the forearm is fully weighted to the mElbow bone, and the upper arms is weighted to the mShoulder bone. Between each, there is a very small region of vertices that have weights for the two bones that meet at the nearby joint.

The same is true of the legs (and the ankle area has no intermediary transition zone at all) as well as the head and neck (when thinking about an armature, the "head and neck" are an extremity because they're the end of a bone chain extending from root).

When you compare the general movement of these areas of the avatar to the way your own body moves, they're not too dissimilar. Your body looks far smoother but, overall, it's not too bad.

Things get ugly in the main part of the body. When you look at the way the shoulder area (mShoulder, mCollar) and torso (mPelvis, mTorso, mChest) move. By looking at the weights, you'll see that the bone group assignments are just like those of the extremities: areas where only a single bone has influence, and very rapid transitions between them.

Because these overlapping regions are very narrow, the mesh movement at those transition zones is fairly extreme resulting in significant texture stretching and very angular, unnatural looking bends.

 Nowhere is this more evident than in the transition from chest to torso to pelvis when your avatar is bending forward or twisting side to side. Not only is the mesh shape utterly in-human, but the textures are stretched to obscene extremes (both for skin and any wearable clothes).

You'll see similar issues and effects with movement that involves the collar and/or shoulder, and some extremely odd -- to put it mildly -- bending and stretching in the area of butt and groin.



Most of these issues are due in large part to the very low poly count of the model which provides minimal topology in the area for weighting transitions to be made. Even so, a basic examination of your own body will tell you that when you move those areas, it's never done in isolation. Sure, some of the in-world ugliness stems from poorly made animations, but at least as much of it comes from the combination of three key factors:
  • limited armature (3 bones to cover the entire back instead of having ten times that many as the human body does) which we can't alter
  • limited geometry of every few vertices available to weight with, which we can change by using mesh
  • limited bone influence by never having a region be influenced by more than two bones and often by only one bone which is also something we can change by using a reweighted mesh
This isn't just about the avatar body, though. The exact same issues arise when making clothing. If you match the weights of the body you'll perpetuate those shortcomings, and two of them aren't entirely necessary.

The strategy for minimizing these problem areas will work for revising or improving a mesh body, and will also work for any mesh clothing you make that's intended to be worn by the normal avatar. You can "double up" on the improvements when using mesh clothing made to match an enhanced mesh body.

Geometry and Topology

The first part of our strategy to have things move more naturally is to address the mesh itself and ideally will involve both geometry and topology. For people new to mesh, those might seem like synonymous terms but there's a subtle distinction (or at least in the way I use them there is). In general:
  • geometry is the pure vertex count...more vertices means more geometry
  • topology looks at the distribution or arrangement of those vertices
For our purposes, if we just wanted to "improve" the geometry we'd be tempted to do something like a simple subsurf modifier which would give us more than 3x as many vertices to work with (Ruth is ~8k verts and ~16k tris and a single subsurf makes her ~26k verts and ~52k triangles). I can already hear the screams...but bear with me.

The interesting thing if you do this is that Ruth doesn't actually become all the much easier to weight. No matter how much work you do to them those transition areas are still pretty ugly -- although better -- and you've almost quadrupled the face count. This is because Ruth's topology -- the way her vertices are arranged to model the shape -- isn't all that great and isn't improved significantly by a simple subsurf.

In comparison, it's possible to create a model with better topology that isn't even double Ruth's geometry and is much easier to work with for weighting. The accompanying picture is Ruth (pink) with 1 level of subsurf standing beside my model (yellow) that has a completely different topology and lower geometry (~14k verts and 13k most-quad faces  that becomes 26k faces after triangulation). Ruth is using the default SL weights, mine uses a mixture of tri-weighting and quad-weighting. Both are in the identical pose.


Admittedly I could spend a day or two improving subsurfed Ruth's weights and get a closer approximation (and my very first mesh avi was done that way) but by by restricting myself to dual-weighting and only working with the SL topology, the results were never satisfactory. The key to improvement was adding geometry only where it was beneficial and ensuring that the topology of the mesh was arranged to support the natural zones of movement for the body.

It's well beyond the scope of this tutorial to go into that side of things in any depth -- it would be a lengthy course of its own -- but if you're making clothing to fit Ruth it's worth bearing these things in mind:
  • Areas of the clothing that will cover parts of Ruth that are static (areas that have 100% weight to a bone) are areas the require only the minimum possible geometry to give the shaping you want
  • Areas of the clothing that near joint locations and will need to bend and stretch a lot are areas where you need extra geometry, and ideally geometry where the loops follow the contour of the pivot zone of the bend
  • Even though a Ruth joint will be bending in a fairly ugly way, if you leave a little clearance for your clothing to bend differently (or use an alpha mask) Ruth won't poke through it so you can give the illusion of a far smoother bending of the body.
The vast majority of the improvement is achieved through the weighting, but before I talk about that -- which is the meat of this tutorial --  let me first address any moaning and wailing about increased geometry.

Yes, an increased poly count will result in an avatar or clothing item that takes longer to load and is a little harder for graphics cards to manage. If you export Ruth (just basic Ruth without the subsurf) as a .dae, her file is slightly under 1MB in size. My alternate model is fractionally over 3MB. In case you're curious, Ruth with subsurf is a little under 5MB. Now let's think about all three of these for a moment.

The original model was designed about 15 years ago to be suitable for the typical internet speeds and graphics capabilities of that time. Hopefully it won't come as a surprise that those specs are slightly different than today's standards. I did a bit of googling and came up with the following fun facts about what was fairly commonplace at the time that Ruth (and the rest of the Second Life stuff) was first being designed.
  • approximately 85% of internet use in North America was still being made using dial-up connections (max 56kbps) and the best available "high speed" connection for commercial users was 1Mbps (which would cost you a small fortune)...only ~5 million Americans were using broadband of any type and only 7 States didn't even yet have access to it. I'm sure numbers in Europe were similar (with obvious regional variations, much as Canada -- where I live -- was a bit ahead of the curve)
  • On the graphics side of things, nVidea had only recently released the GeForce 256 which was the first card to have its own GPU and sported an astounding 256KB of DDR RAM! If you drove a Porsche at the time you might have upgraded it to 512KB.
  • And to look at? Why not one of those insanely expensive new 1280x1024 CRT monitors...
  • Driving the whole thing? Probably one of those fancy new Intel P3 1GHz chips running Win98 (or WinMe). If you were wealthy you might have had as much as 256MB of RAM but it was costing you about $100/64MB to buy it (but only 5 years earlier that same $100 would only buy you 4MB).
Now let's look at those file sizes. Remember that the file only needs to be sent once to each viewer that enters the region. Ruth is hard-coded into the viewer and doesn't need to be sent, but if you wear mesh Ruth -- even if identical -- you'd have to send that data.

According to Akamai Technologies' data, the global average download speed in 2014 was slightly under 4Mbps and the majority of developed nations had speeds in the range of 10Mbs but for convenience let's use 8Mbps since that's the same as 1MBps. At that speed, the Ruth mesh might take a second to deliver to most users, my alternate mesh might take as much as 3 seconds, and even the painfully-high poly subsurfed Ruth would be there in 5 (and as I demonstrated, that's overkill).

You get the point, though..it's probably not pushing people's capabilities or the original design's envelope too much to add a little extra geometry in appropriate places if you're making your own avatar.

Tri-Weighting - Bone Chains

Now let's get to the good stuff, and let's focus just on the main torso for now.

I said earlier that by examining the way your own body moves you'll notice that the major problem area of the avatar's torso is one where your natural movement is never really in isolation. When you bend over to the side, your entire spinal column -- all 30+ vertebrae -- rotates in a smooth, continuous way, as does all the stuff between the bones and skin (and it's actually muscle doing the moving and the bones just go along for the ride), and on the outside your skin stretches and moves along with everything else. It's not three distinct sticks moving separately...it's a whole continuous region moving as one.

To mimic this effect, we need motion of the mChest bone to have a "ripple-down" effect on the mesh that extends far lower than the SL weighting provides. Similarly, when the mTorso bone moves, it should affect the body quite a bit more than the base mesh's weighting does. Further examination of your own body will tell you that the rib cage tends to move as more of a block than the mid abdomen, and that in the region or your hips your pelvic bone is preventing the sides and back from moving and stretching as much as the belly. Your back doesn't move much at all compared to your front, either.

Way back at the beginning of this series we played a bit with a two-bone armature and a cylinder. In doing so we learned about smoothing the transition between two bones and it was quite easy to achieve because our cylinder's geometry was detailed enough to give us enough vertices to play with, and it's topology -- a series of evenly spaced concentric rings -- was ideal.

Your own torso is not all that different. Even without tri-weighting you could simply add some geometry from about the base of the breasts to the crest of the hips, fix the topology, and then make those 2 "joints" (chest-torso and torso-pelvis) have a smoother transition. We don't need any extra geometry above that because the rib cage moves more as a block, and the lower portion of the pelvis wouldn't benefit much from it either (for movement...for anatomy is a different story).

I tried that approach at first with my own avatar and wasn't satisfied with the results because that middle area that was heavily weighted to the mTorso bone would move as a block, and a real body doesn't. After a considerable amount of experimentation I discovered that a far more realistic motion was achieved with weighting as shown here:

The total geometry difference between this model and Ruth is less than double
the total tri count, and a not-inconsiderable amount of that increase comes from
having modeled toes and a few other anatomical improvements..the actual geometry
change for this area alone is less than a 50% increase

As you can see, almost the entire trunk of the body has weights for three bones (ignore the shoulder region for now). The mTorso bone has nowhere that is fully weighted to it...it is always being influenced by both the mChest and mPelvis bones which is more or less exactly the way that part of your body reacts to movement. You'll also notice that the mTorso and mHip bones interact a little across the hip crest and outer butt.

My mesh has just sufficient geometry as well as the topology required to provide loops of vertices that flow smoothly through each of those transition zones. When I make clothing, I give it similar consideration.

This area we've been looking at is only one of the two occasions where tri-weighting can be extremely effective: a case where you have 3 bones in a chain. The other situation -- a "tri-weighted Y-joint" requires a different approach which we've actually already seen Part VI but I'll reiterate again, later in this one.

For tri-weighted chains, the method of doing the weighting is one that takes a while to become comfortable with so hopefully I can give you some decent advice:
  • I find it essential to have auto-normalize enabled to keep the sum of weights equal to 1.0
     
  • Work with the model in T-pose and then only rotate one of the three bones you're working with for that tri-weighted region. When moving a bone, consider whether another of the tri-weighted bones moves with it and also influences the mesh. For example, rotating the mTorso bone is also rotating the mChest, so the only weight that counteracts this movement will be coming from the mPelvis (and mHip) bone. When you rotate the mChest, both mTorso and mPelvis weights will be counteracting the motion of the mesh.
     
  • Any time you either add or subtract weight (rather than blur) think about the "math" being done by the auto-normalize. If you're adding weight to a bone, it proportionally reduces the weight of both of the other bones. If you subtract weight, both other bones will have weight added.
     
  • Auto-normalize does proportional changes. Let's imagine a vertex that has weights of 0.1 for mChest, 0.8 for mTorso, and 0.1 for mPelvis. If you add 0.1 to the mChest weight using your brush, it will rise to 0.2 and the other two bones, combined, need to lose 0.1. They don't each lose 0.05 though, because it's proportional. Instead, the mChest will lose a bit under 0.09 and mPelvis will lose a little over 0.01. It might help to think about relative percentages. It might sound complicated but believe me, it's the way you'll want it to work and makes things much, much easier to balance!
     
  • Always try to work with the "outside" bones. For example, if you rotate the mChest bone you will want to do your weight adjustments by brushing with either the mChest or mPelvis bones and avoid using the mTorso bone. Then zero the chest bone's rotation, rotate the mTorso, then do your adjustments with mChest and mPelvis again.

    In this scenario, the only times you'd paint with mTorso weights is for a region that is affected by mTorso, mPelvis and mHip (and not mChest). You'll also potentially paint with it in the upper chest area when working on movement of mesh that has weights for the collar.

    What you'll find is if you balance the two "outer" bones like this, the "middle" bone will automatically end up with the right weights by virtue of the auto-normalization.
  • When you're smoothing out little bumps and jitters in weights you'll find that you should mostly be working with a bone that has weights in that region that are either very high (red) or very low (blue), and only rarely with a bone that has mid-range (green) weights.
     
  • I would characterize tri-weighting as being about 50% math/anatomy and about 50% "skill." I think there's a real art to it that can only be developed over time and practice. The more you do it, the better you'll gain an "intuitive feel" for the process. Eventually it almost becomes second nature.
     
  • This should probably go without saying, but before making any major weight changes in an area you'll want to save a back-up copy of the file to revert to if you find that it isn't doesn't end up doing what you thought it would. That will happen a lot when you're first learning.
Even though the example I'm using here is for an avatar body, the exact same strategy applies equally to clothing, even if the underlying mesh body that will wear the clothing isn't tri-weighted. This works nicely on the torso of a dress for Ruth where you leave enough clearance between her body and the dress (or alpha-mask any poke-through).

Tri-Weighting - Y-Joints

The other time you'll want to consider tri-weighting is one we looked at in some depth in Part VI when we did the weighting for the skirt portion of the dress. It involves an overlap of weights for two bones that both attach to and pivot at (or near) the same joint position of a third bone. This happens in two places on the body:
  • on the "cross-over" part of a skirt or dress, or the crotch area of saggy pants
  • the shoulder region
For the former, you will find that you almost certainly do not want to do tri-weighting of the underlying body. If you do, you'll find the groin behaves very strangely as the legs move (trust me, or try it yourself if you'd like a chuckle and don't mind wasting some time). For something that "bridges" the gap between the legs, though, it often produces a much more natural looking result.

I gave detailed instructions for that type of weighting in the previous tutorials so there's no need to repeat it here.

The shoulder region (of the human body) is an extremely complex one to model and weight (and animate) to look natural. It's a complicated  area that the armature simply can't do justice to with its Linden Lab structure, and can be thought of as a mirrored pair of Y-joints where on each side there is an interaction between the incoming arm chain bones mShoulder and mCollar with the main mChest bone "trunk" of the body.

Your real life body has some additional influences where the motion of left shoulder affects the right side of the back, and the base of the neck, and even extends (by way of skin stretching) quite a long way down the sides. The collar and shoulder musculature involved are also tied into the pectorals and lats, but only when moving the joint in certain ways; and...well....the purpose here isn't to do an advanced course on anatomy so let's just leave it at the shoulder being a complete mess of interconnected stuff.

To be fair, the 3D animation world has long since resigned itself to the knowledge that a simple armature and set of weights is never going to be sufficient to make shoulder movement look natural so this is definitely not a shortcoming that is unique to our SL-based avatars. Tri-weighting this area can make a rather drastic improvement over Ruth's very strange weights but when you approach it you will need to think of it as a chain, rather than as a Y. The chain is
mChest <> mCollar <> mShoulder
where you ignore the neck and will have to accept some odd creasing/shaping on the top of the shoulder.

I would suggest that you don't try to do any cross-over interaction between the collar bones on the back (or upper chest at the base of the neck) because from experience I can tell you that it will never look right in motion -- or at least I wasn't able to achieve natural-looking mesh responses after devoting 50+ hours of dedicated weighting work in that region. What I was able to do, however, was fix the top of the shoulders (and make minor improvements in the area in general) by....quad-weighting.
In case you're curious, the 3D animation world does have a couple of solutions for the shoulders that work extremely well and can be found (at least in part) in most modeling and animation software. They tend not to be suitable for real-time rendering, but an application like Opensim is a relatively rare one compared to the bread-and-butter work of this software (CGI, frame-rendered animation, still renders, etc. where there is no need for instant on-screen response).

The three most common methods are:
- "shape key counter-morphing" where one or more shape keys are defined and assigned to the necessary vertices, then animations also include the required counter-morph slider settings
- "bi-lateral weighting" where different weights can be assigned to positive and negative transformations of the same bone (if the bone translates in a positive direction from its rest pose it has one set of weights and if it translates in a negative direction it has a different set of weights)
- "vertex target hooking" which works a bit like a cross between the shape key method and a gravity well object to retard mesh motion away from its rest position

Blender fully supports the first, doesn't support the second (yet), and has partial support of the third. For real-time environments the third method is the one most likely to make its way into the mainstream in the not-too-distant future (but not in SL/Opensim).

Quad-Weighting

The quad-weighting method isn't for the faint of heart. It takes a lot longer to balance and smooth the weights because in many areas you can't isolate the effects to the motion of a single bone. Instead, you have to carefully balance it all as you paint.

This is the one time where turning auto-normalize off can be helpful, provided you remember to then later normalize all bones and re-check that everything is moving the way you want it to. Before attempting this method you should also be fairly comfortable with tri-weighting. If you are...
  • Turn auto-normalize on if it isn't already
  • Begin by tri-weighting the region(s) based on nearest appropriate trio of bones. For the outer half of the top of the shoulder this will be the mChest-mCollar-mShoulder bones. For the inner half it will be the mChest, mCollar and mNeck. You may also have a small area where you want mHead, mNeck and mChest
  • Start adding weight for the fourth bone until the general response is roughly appropriate
  • Turn auto-normalize off
  • Move each bone in isolation, using only blur or subtract to balance
  • Any time you subtract, be sure to subtract roughly proportionally to the existing weights for each bone that needs to be reduced (so if you need to subtract neck and chest, subtract them both one at a time and in approximate proportion to their pre-existing weight balance)
  • Once it's more or less correct, click the "Normalize All" toolshelf button and ensure that you you have the options set for "All Groups" and disable the "lock active" toggle.
  • Check the bones again, repeating the process until you no longer need to subtract weights after normalizing and can simply blur
  • Enable auto-normalize again
  • Do one final check of all bones involved, blurring as required (or very, very small additions and subtractions)
  • SL/Opensim doesn't support weighting 5 bones to a vertex so try to avoid it if possible. It won't cause an error on upload but I'm fairly sure that the lowest weight is dropped and the others are normalized again after the drop which can make a mess of all that work you did
Even once it looks pretty good in Blender you'll want to upload and watch the area closely in-world as you play a series of animations that move it through its typical range of motion. Be sure not to base your evaluation on just a single animation or two...there are plenty of animations that are poorly made, particularly for shoulder movement, so your weights may look great for some and horrible for others. There's nothing you can do about this other than make your own custom animations.

In this picture you see the upper body, rear, where most of the shoulder region and areas in the upper body are quad-weighted. This produces a much smoother and more natural reaction in the body for motion of the shoulders and neck. Don't be surprised, when doing this from scratch, if it takes many hours of work on just this one region to achieve a decent balance of weights.

Less Is Often More

I should close out this tutorial -- and final installment of the series -- by saying that one thing I've learned is that less is often more. I will always try to do the majority of my work with only dual-weighting and save any tri-weighted regions for the areas where it's really required. I only considering quad-weighting for special cases and only if it's absolutely necessary. If you do it on your body you'll also have to do it on any piece of clothing that goes over it...

When I do have to tri- or quad-weight, I'll use one of a few prepared weight source meshes I've created that are already weighted to match my body. These source meshes are very high poly (200k+) and perfectly symmetrical (which made them much easier to weight when I created them). I began creating them at low poly, weighted them, then subsurfed and applied, then tweaked the resulting weights until they were best possible (including upload them, cut in pieces, to test on my body).

Using these stored source weight meshes, I generally have extremely close-to-final results after weight-transfer to my target mesh and will only have to do a few minor tweaks. It's worth putting some time and effort into making these since it will save you many hours of weighting work on future items.

I hope this series has been helpful as a starting point for your own work. Don't get frustrated if your first few attempts aren't as good as you'd like them to be...the art of weighting is one that takes time and practice to become comfortable with, and even longer to master (I'm not even sure that I've mastered it yet, for that matter).

Good luck!

Wednesday, 18 November 2015

IMPORTANT NOTICE: Paramour Dancemaster Dance Ball system

Hello everyone

In the last couple of days the Avimerge branch has been dropped into git master branch and has also been pushed out to OSGrid in their latest build. This is largely untested code and it's expected that there will be issues with it.

One of these is that the new code causes the initialization of my very popular dancemaster dance ball to fail due to an event timeout because of changes made to the way the code handles scripts. Under pre-merge code my system typically takes 5-10 seconds to initalize (in my own region it takes 6 seconds). Under the new code in my region it takes an insanely long 75 seconds to initialize.

By default, Opensim will time out any script event (like state_entry) that takes more than 30 seconds to execute, thus this new incredibly long script initialization time will cause state_entry to fail and the danceball will never switch from it's initializing state to its ready state. Thus all of my dance balls will probably fail for anyone using the new code.

Similar failures could easily happen for other scripted items you own (MLP objects being a prime candidate since they take quite a while to start).

There is a temporary fix for this but you will need access to the opensim.ini file for the simulator.

The Temporary Fix

  • Open the file ...\bin\opensim.ini
  • Scroll down to the [XEngine] section
  • Look for the part that says:
        ;# {EventLimit} {} {Amount of time a script can spend in an event handler} {} 30
        ;; Time a script can spend in an event handler before it is interrupted
        ; EventLimit = 30
  • In that final line, remove the semi-colon and change the EventLimit value to a much higher number (120) so now it will look like this:
        ;# {EventLimit} {} {Amount of time a script can spend in an event handler} {} 30
        ;; Time a script can spend in an event handler before it is interrupted
        EventLimit = 120
  • Save the file
  • Restart the simulator
This will now allow an event to take up to 2 minutes to finish processing and will therefore allow enough time under the current code for your dancemaster system to work.

There are no adverse effects to setting a longer time-out value other than it would allow a buggy script with an infinite loop to sit there churning through its loop for a full 2 minutes before killing it instead of doing so after 30 seconds.

If/when the Opensim devs have resolved this issue I will post a notice that it's safe to revert to a lower number again.

I apologize for the inconvenience and can only say that it's out of my control to do anything other than make the developers aware that the problem exists and hope they deem it important enough to address in the not-too-distant future.

Update - Nov 18 @ 6pm

Ubit and I spent most of the afternoon trying to track down the cause of the issue. While we don't yet know for certain, we were able to bring the reset times down to normal again (<5sec) by changing ApDomainLoading from true to false in [XEngine]. Previous strong recommendations from the devs were for Windows users (which I am) to have this set to true vs Linux users should have it false.  Until the issue is resolved from the code end, it would seem Windows users will now need to set it false as well.

Tuesday, 17 November 2015

TUTORIAL: Principles of Blender Rigging and Weighting - Part VII

This is the seventh part of an extensive introduction to rigging and weighting in Blender for use specifically in SL/Opensim. You will find links to Parts I-VI on my main page of links. The subject I'll be addressing in today's installment is mesh avatars.

Sorry, today's is another of those "theory-heavy" ones rather than one with lots of pictures and how-to instructions. In large part this is because the actual skills required to do this are ones I've already covered in this series. Working with custom avatars simply requires applying that knowledge to a different circumstance and being aware of some associated issues and considerations.

A non-standard avatar is one that deviates in any way at all from the default "Ruth/Ron" avatar we're all familiar with and therefore needs to be uploaded in-world as a weighted mesh. This can include:
  • An identical mesh version of a SL avatar, using the same UV mapping, same geometry, and identical rigging and weighting to the in-world one. The "non-standard" deviation is only that it limits some of the items you can wear.
     
  • An identical SL Avatar mesh which can be re-weighted to provide a pretty significant improvement to the way it moves and, in particular, to reduce the major problem areas. The "Ruth topology" can make this a challenge but it's possible (and was my own first foray into the subject).
     
  • A very similar human avatar created by re-working the default avatar's mesh (often increasing the poly count somewhat and/or reworking the topology). If you're extremely careful you can also preserve the original UV layout. I've done this but it can be an exercise in frustration without a significant gain i quality.
     
  • A human figure model that you make from from scratch, or one exported from a software product like MakeHuman, or one that you've downloaded from places such as Blendswap or other open license sources.
     
  • You can also use commercial models, but be very caution about the licensing terms when you purchase it. Game models and most common 3D software models (like DAZ, Poser) have self-use clause which is violated when used in Opensim because the actual model and textures must be stored on an asset server and then also later transmitted to anyone else who sees your avatar, even if you aren't giving copies of it away.

    To stay strictly within the licensing terms you would need to be in a self-hosted standalone which nobody other than yourself is able to access (via login or HG) and which you can never leave while wearing the avatar.

    Many people -- myself included -- bend these rules a little by using commercial self-use-license models and textures in their sim builds but do not distribute those items. With no income being derived from them and with it requiring an illegal act for someone else to extract and use the model or texture, it's somewhat unlikely (but possible) that a commercial vendor would go to the trouble of issuing a DMCA take-down request or initiating legal action.
     
  • Non-human models you've made or obtained with suitable license. The sky is the limit, here. I've seen dogs, cats, dragons, horses, merefolk, cyborgs, and all manner of other things. These present additional challenges but are feasible -- at least to some degree.
All except the very first of the above possibilities results in an avatar that uses different weighting -- and in some cases a modified armature -- than the in-world one, and there area  few things that you need to be aware of before you start considering them because they'll likely determine whether it's even worth your time and effort to do it. First, though, let's quickly cover the basics of wearing a mesh avatar.

Wearing a Mesh Avatar

 To wear a mesh avatar you will need that new mesh and its textures. It will need to be in a SL-compatible .dae file format (not all .dae are suitable for upload) including the full armature details. If it's one you're exporting from Blender it will need to have "include armature" option as part of the export settings.

SL/Opensim requires that you always have a skin, eyes, and hair wearable worn. Those can be replaced but never taken off.

We don't want that base avatar poking through our mesh one so we almost always need to hide it by wearing a complete body alpha mask. Because the mask hides everything, I'll typically use the default Ruth skin, eyes and hair since those will never need to be transmitted by the region (other textures would still be transmitted to other viewers even though they're hidden and there's no point adding to the data transfer load).

You also must always be wearing a shape, and this is something that can cause confusion for beginners.

When a wearable mesh is imported, the importer treats it as a "Ruth shaped" object in T-pose. It doesn't matter if it's the size of a house or the size of a mouse, the in-world system thinks of it as "Ruth" standing in T-pose. This almost always means that for it to display properly you need to wear a Ruth shape. This is true even if you're using a male mesh avatar, or a dragon, or a blob of slime.

The only time where this isn't true is if the software you use to export the .dae is altering the file at the time of export and also supplying you with a XML shape file to import and wear as well; or if you use a product like Avastar where you've dialed in your own shape settings prior to working (and not made any custom adjustments to the armature where you've used its "snap to" function) since it readjusts the mesh to Ruth proportions on export which will then be counter-acted correctly by wearing your shape.

As we discussed earlier in this tutorial series, the imported mesh is deformed by any shape slider settings you're using that affect a bone group the mesh is weighted for. That's how fitted mesh is able to work at all but it's also true for mesh that uses the only the classic armature's mBones set. Any shape slider that changes a mBone length will deform your mesh.

If your mesh avi has weights for the pec bones, butt and belly, you'll also want to be wearing your physics wearable which governs how those react when you move based on their settings.

Because your new avatar is a rigged mesh uploaded with the weights, it will position itself correctly on you no matter what attachment point you put it on so I will usually use a point that is unlikely to ever be used something else you might wear: the left eyeball. Sure, you can wear it on your pelvis or skull or spine or even your left hand if you want, but then if you wear something else there you have to remember to add it rather than replace it on the attachment point -- something that's easy to forget when you're in a hurry.

Once uploaded, you'll also need to apply the matching skin textures to your mesh avatar (exactly the way you'd texture a prim or any other mesh object). None of your existing skin wearables will work unless you have their actual texture files and your new avi uses identical UV-mapping to the SL avatar's maps.

So your base worn avatar set-up will be:
  • skin wearable (usually Ruth skin)
  • eyes wearable (usually default Ruth)
  • hair wearable (usually default Ruth)
  • optionally a physics wearable if your mesh avi is weighted to have bouncy boobs/butt/belly
  • alpha mask wearable with all 5 zones check-marked to be masked which will make the skin, eyes and hair all invisible
  • your mesh avatar, textured with its own skin, usually worn on an attachment point that isn't likely to be used by something else you'll wear.
  • either a Ruth shape or a shape specifically made to be worn with your mesh avatar, depending on how the avatar was created
In theory, you'll now appear the same in-world as you did in your source software. You'll also likely be bald and naked. Your in-world avatar animation is controlled by whatever you're using (default SL animations or AO or other pre-made ones).

Considerations About Using Mesh Avatars


Skin

I've already pointed out one possible consideration that may impact your decision to wear a mesh avi: the skin. You can't use any of your wearable skins so you need to have your own full set of textures to apply to the mesh.

If you're using a mesh avatar that has UV maps that are identical to the default one, and you have the original textures that were used to make a SL-wearable skin, you can apply those textures to your mesh avi (you do this just like texturing a prim or any other mesh).

If you don't have the original skin textures, or you're using a mesh avatar that has a different mapping, you'll need to use the ones supplied to you already from the software used to create the mesh. Hopefully they're good. If not, you'll have to make your own (which can be pretty challenging to do if you aren't fairly expert at Photoshop/GIMP).

I won't go into this in any greater depth since it doesn't really have anything to do with this tutorial's subject.

Hair

For many years, the vast majority of users have been sporting "prim hair" that is usually a mixture of prims, sculpties, and often flexi-prims and is an attachment typically worn on the skull. These existing ones will all work perfectly with a mesh avatar although you'll likely need to size it to fit and/or adjust the position of it a little.

If you've been wearing the "clothing item" type of hair that Ruth does, it will now be hidden by your alpha mask and you'll need to go shopping for prim hair instead.

In the last couple of years, mesh hair has become increasingly popular and this can lead to issues. I'm referring to rigged mesh hair, since unrigged mesh is essentially the same as a prim and is fine. With rigged mesh hair, the hair must be matched to your avatar since you can't scale or position rigged mesh in-world.

If your avatar uses different rigging and weighting, the hair has to have been designed and weighted for that same rigging and weighting or very close to it. In most cases that means you'll need to make your own (or go shopping for prim hair to wear instead).

Clothing

All mesh avatars are attachments and therefore cannot use any of the standard SL/Opensim avatar or clothing items -- the "paint on" ones you wear like skin, tattoo layer, alpha mask layer, shirt, pants, etc. They're all being made invisible by the alpha mask and if you wear one it goes on a sort of phantom Ruth mesh that's under/independent of your worn avatar mesh and will poke through it, etc.

Any clothing you want to wear has to either be part of the mesh avatar's texture, or has to be an additional mesh clothing item (worn as an attachment) that has rigging and weighting made to match those of your mesh avatar.

If you want to use paint-on clothing, there is no "alpha mask" or "clothing item" for mesh avatars...you have to do it as part of the actual texture applied to it. If you've been making your own paint-on SL clothing you shouldn't find this too great of a challenge since you use more or less the same approach for a mesh avatar but any part of the body not covered by your paint-on clothing has to be your avatar's skin texture instead of being transparent.

If you go this route, you'll want to make a template (or set of templates) in Photoshop/GIMP that have your skin texture as their base layer. You'll create your clothing items on higher layers and, at time of export, include the skin as part of the overall clothing texture. Then, in-world, you'll apply that directly to your mesh avatar rather than having it as a separate wearable.

While this isn't hard, in practice it tends to be very inconvenient unless you commonly just make complete outfits. If you like to mix and match pieces of clothing you'll need to do so manually and remember always to unwear, then rewear prior to making any HG teleport (otherwise the changes aren't persisted and people will see whatever the mesh looked like prior to that).

Of course there's an added complication: if you ever later decide to change your skin you'll need to remake and upload all of those clothing items again with the new underlying skin texture.

I very rarely use paint-on clothing and would normally only do so for things like a few commonly worn underwear items or a tattoo.

By far the most flexible approach is to make your own matching mesh clothing. Rather than using Ruth as your mannequin during the modelling and subsequent rigging and weighting, you'll be using your file copy of your avatar model and be transferring its weights when you prepare it.

Of course this all depends on your skill level in Blender. If you have the ability to make your own avatar you'll easily have the required knowledge to make clothes for it. If you're using a model created by someone else, you'll either need to get matching clothing from that same source or be capable of making your own. On import in-world, properly made rigged mesh will fit and move with you like a glove and, with enough care, won't requite any alpha-masking of your underlying mesh avatar.

If it's necessary to alpha mask your mesh avatar you have a new challenge: you'll need to make a new skin texture for it with the appropriate areas masked out and fully transparent on the skin. That's easy enough to do, however you'll either need a bunch of different pre-masked bodies or have to continually replace parts of your body texture (which rather kills the quick mix & match wear convenience).

A further complication with masking parts of your mesh avatar is that anything mesh worn over that texture and using an alpha channel in its texture(s) will usually alpha-glitch with your masked skin and will do so very unpredictably, Sometimes your clothing will look right, sometimes it will become invisible and show the skin texture underneath it instead; and it won't do so in a predictable and repeatable way. You might look fine in your viewer but be a mess in someone else's. It's far better to spend the time doing your weighting properly and not requiring a mask.

Animations

You'll also need to pay very careful attention to any impact your work has on the way your avatar plays animations. If you alter the armature at all by scaling or re-positioning bones it will change the way any of the in-world animations appear when you play them. The changes to a joint's axis of rotation and pivot point can make a "stock" animation appear very, very odd in world.

There are two solutions:

  • ensure that any changes you make to the armature of your avatar are small enough that the difference between it and a normal avatar are small enough that it doesn't make in-world animations look too bad, or
  • make a complete set of your own animations and use those in-world instead
Even if you're an expert at Blender animation (which is a loooooooooooooooooong subject of its own) and don't consider the idea of making a completely new set of custom animations as being a challenge, it's worth remembering that for a lot of common activities you probably don't use your own animations. You might want to...
  • sit on something that has its own built-in animations that won't work correctly for you
  • go to a dance somewhere and of course their danceball probably isn't going to have your custom animations in it so you'll need to make and play your own
  • you'll need to use a built-in viewer AO for all of your animations since any script-based system will frequently (usually!) fail when you're HGed and there are many regions where scripts are disabled
  • anything that uses animations to have to interact with someone else (couples dances, cuddle/sex beds, etc) won't work for you -- you'd have to make and only use your own

General Bugginess

Above everything else is yet another consideration: various bugs/glitches/limitations of the viewer and simulator software.

There are still a surprising number of people who are married to viewers that don't support mesh. They simply won't see you at all or will see a simple sphere instead.

There was (is?) a bug with the ATI graphics card driver that causes it to fail to render rigged mesh, when worn, unless you disable hardware skinning in your viewer's graphics preferences. Doing so has a rather serious negative effect on graphics performance and a hit to CPU requirements so many people simply refuse to do so. Any rigged mesh you wear will be invisible to anyone with that issue. Neither nVidea nor Intel drivers have that issue (that I'm aware of) and I'm sure ATI will eventually fix theirs if they haven't already done so.

Another common bug, currently, is an issue I experience most often in Opensim although I'm told that it can happen in SL as well: when you TP into a busy region (one with many avatars in it already) the subsequent sending of your mesh data to all of those viewers can somehow become glitched. The data is sent, but some of the people's viewers won't be aware that the data has arrived and will fail to display some of your worn items.

This means if you wear a mesh body and mesh clothing and tp into a party you should expect that:
  • some people will see you perfectly
  • some people won't see you at all
  • some people will see your body but not one or more of your clothing items  so be prepared to be told you're naked even if you aren't
  • some people will see your clothing item but not your body -- so you'll be a corpseless dancing dress and hair
Currently there is no "fix" for this but the bug is one that has been reported to both the Opensim and the viewer developers. Maybe one day they'll consider it worth their time to look at it (probably when it directly affects one of them personally or when enough users start to complain about it often enough that they finally get around to it).

When this bug happens, a rebake will NOT fix it. Nor will it be fixed if you relog. Nor will it be fixed if you tp out of the region and back. Nor will it be fixed by the region operator executing any console commands. Nor will it be fixed if they toggle into wireframe view and back.

If you're extremely lucky, you can change your group tag and this might be sufficient to trigger a resend of all data and the other people's viewers will suddenly see you correctly but this doesn't appear to be a reliable, repeatable solution. Occasionally it will work. More often it won't.

The only way that someone will reliably see the missing piece(s) is if they relog, and unfortunately that's not often going to be something they're all that eager to do.

We can hope that as the software matures they will put some time and effort into resolving bugs of this nature (and while we're at it, let's hope for world peace too). In the meantime, be aware of the issue and dress accordingly if you're worried about it (a body that uses paint-on underwear textures is a good back-up plan for attending parties).

Summary

All these caveats might seem a little daunting (and they can be!) but my intention isn't to discourage people from using mesh avatars. It's simply to forewarn you that there's more involved than a quick body upload.

Working With Avatar Models

Assuming the above section hasn't scared you away, let's look at how you approach working with an avatar model to prepare it for use in-world.

Basic - T-Pose Models

If you're lucky, your avatar model will closely resemble the SL avatar in overall, shape and proportion. If you're even luckier it will fall into the "Basic" class of model where it's already in a SL-like T-pose shape. These are by far the easiest to work with and existing in-world animations will often look pretty good with them.

The actual process of rigging and weighting a custom avatar mesh like this are identical to the methods I've already covered in previous parts of this tutorial series. The greatest challenge will be doing the weighting since you may not have a source object you can use to give you a decent starting point for your weights.

If that's the case you can try the method we used for our mesh cylinder and transfer weights from the bones themselves, or on rare (!) occasions you might find the bone envelope gives you a better starting point. If all else fails, you'll have to manually add them from scratch as we did in our very first experiment with the cylinder. This is a lengthy process but the mechanics and techniques are all the same as the ones we've already discussed.

It may be necessary for some models to make some small adjustments to the armature by actually editing the lengths and positions of bones. You are allowed to do this provided you don't alter the structure of the SL armature. You cannot change the hierarchy of bones in the armature but you can move around the joint locations.

It will take some trial and error and experience to get a feel for just how far you can deviate from the built-in armature in your edits before it forces you to make custom animations and what's "acceptable" in terms of how an avatar looks when an animation is being played will differ from person to person. Something I consider "okay" might not be to someone else -- and visa versa.

Humanoid Models That Aren't Already in a SL T-Pose

If your source model is a human figure, must as above, except that it isn't already in a SL-type T-pose -- and many aren't -- you can still potentially use it. The basic approach is to first adapt this model into a new one that is posed in the SL T-Pose (doing that deserves its own section, below) and then you can proceed with rigging and weighting it just as you would with a basic model.

Non-Humanoid Models

You can use a model that has a very non-human shape like a cat, dog, horse, bear, or other such animal. Or any other shape, for that matter. This will involve making direct edits to the SL armature and you will subsequently have to make all of your own custom animations for it.

I am not an expert in non-human model rigging although I have a theoretical understanding of it. My testing and experience is with "animals" that conform to the same approximate anatomical structure of a human model, where there is a central torso/spine, attached neck and head, and then four limbs where two "attach" at the pelvis and two "attach" at the shoulder/collar.

Models that deviate significantly from that by being more simplistic are "easy" in that you simply omit weights for the bones that need to be ignored. A mermaid, for instance, would have its tail weighted only to the left (or right) leg bones and have no weights at all for the other. With a matching set of custom animations this is handled just like a regular avatar.

It is not possible to add new bones to the SL armature or to alter the hierarchy. This means you can't create a new chain of bones to handle animation of a tail -- which is a tragedy since dogs and cats in particular really need properly animated tails. You will either need to put up with static tails, or prim attachment ones moved via script, or texture/alpha swapping scripts to selectively hide variations of it, or use a flexi-prim attachment.

I have been told of centaur avatars in SL (but haven't seen one in action) where all four horse legs and two arms are independently animated, and where each of the horse legs is two bones. This leads me to think that it's possible to detach the foot bone from the ankle bone in the armature and relink it somehow to the pelvis but I have not attempted surgery of that nature on an SL armature so I can't give any instruction on how to do it.

Unused Bones

In the tutorial installment where we looked at the SL armature, we learned that there are five unused bones in the standard armature: the left and right feet and toe bones, and the skull. Although they aren't used in any animations, you can include weight for them in your mesh and then make custom animations to move them -- including ones are are keyframed only to them.

One application for this -- which I now use personally -- is to partially weight the eyelids and upper eyelashes to the mSkull bone, then rotate the skull using an animation (I trigger that using a HUD). Since no other part of the avatar is weighted to it, the rotation will let the avatar blink without affecting any other part of the mesh.

The same can be done by weighting the lower jaw to the skull instead, allowing you to open and close a mesh avatar's mouth. You can't independently do both, though.

For the feet and toes there are fewer applications, although it is possible to use them to alter your feet into a natural "high heel" pose this way instead of making a separate model that is pre-posed that way.

Be aware that any script that stop currently playing animations -- as many do -- will also stop those custom ones so you will need to be able to trigger playing them again.

Attachment Armature Weighting

I have recently been doing some experimentation with weighting portions of an avatar to the attachment armature's bones but my results have been highly unpredictable and this is not something that is either encouraged or supported by the environment.

The attachment armature is another one that is part of the "hidden" structure of the SL rig -- much as collision bones used to be -- and its purpose is to control the location on the body used when you attach something. Many of that armature's bone names violate the .dae naming requirement (of no spaces in bone names) and thus those weights cannot be imported at all. (A year or two ago a TPV added unofficial support for handling this by allowing you to replace the spaces in the names with underscores in the .dae and then having the viewer convert them back to the correct bone name at import...this was later removed).

For the handful of attachment bones with valid names, I've had exceedingly unpredictable results that, most frustratingly, are not consistent and repeatable. If I'm ever able to reliably figure out what does and doesn't work I'll write a separate tutorial for it.

Adapting Non-T-Pose Models


If your source model is humanoid but isn't already in a SL-type T-pose you will need to convert it into one that is before you can begin to work with it.

Remember that this is only necessary if your goal is to allow the avatar to look reasonably good when playing in-world animations that were originally designed for the SL avatar. If you're making all of your own animations you can simply edit the armature to fit the model (as long as the structure/hierarchy remains unchanged).

There are several strategies you can use, and you may sometimes need to use a combination of them.

The first two I list here involve changing the SL armature and are not what I'd recommend unless the alterations are very small. The preferred approach is to alter the original mesh to get it to conform very closely to SL T-Pose shape and there are a few methods for achieving that.

Repose and Apply to Armature


You can leave your model in its original pose and alter your armature to fit it by posing the armature and then making this the new T-pose for it. While probably the easiest approach, and one that preserves the original model's geometry, it's also the one that's least likely to give you satisfactory results with existing animations. I would only do this if the pose of your model is very close to being a T-pose.

Make sure you're adjusting your armature's pose rather than editing it, then while still in pose mode you can use the menu option Pose > Apply >  Apply Pose As Rest Pose which will now make the armature consider this to be the T-Pose for upload. All animations rotate the joints based on the T-pose orientation of the bones so if this new pose is a significant departure from the standard one your in-world results are going to be pretty scary. :p

 Edit The Armature to Fit

You can exert a little more control over rotation orientations by editing the armature instead of reposing it. This will result in the same general net effect as the above method except that you can alter bone lengths, joint positions and rotations; but comes with the same caveat about how it's likely to look in-world. For how to do this see the "Armature Edits" section below but I'd try to avoid doing this unless they're minor edits.

Pre-Pose And Apply Using Alternate Armature

If your original source model has an armature of its own (even if very different from the SL one) it's worth starting with its native armature and spending time posing that to make it resemble a SL T-pose. Then you'll lock it into this new pose as its native shape and proceed with regular rigging and weighting. Depending on the source, you can do this in that model's native software environment or you can import it into Blender with its armature and do it there.


The advantage of using a preexisting armature to pose a model is that it will probably be weighted to its native rig to give the best possible geometry under the pose's transformations. Any other method we try is also going to involve changing the mesh's geometry and won't be doing so using something that's optimized for that purpose and can therefore cause undesirable changes to the mesh.

If you use the source software for posing, you'll need to consult its instructions on how to export the model frozen in pose (typically exporting it as .obj will do that, but it depends on the software). When you then import the file into Blender it should be in T-pose and ready to be rigged and weighted.

Your other approach is to export the model complete with armature in a format that Blender can read and then pose your model using its own armature in Blender. Once you have it in T-pose, go to the Properties Pane's Modifiers tab and click the "Apply" button for the armature modifier. This locks the mesh in this new pose and you can then delete its old armature and begin work with the SL one.

Reverse-Posing

If your source model doesn't have the ability to be posed your next most productive approach will be to try the reverse: pose (not edit!) the SL armature to get it to be the best approximation of a pose that would mimic your source mesh's pose. You can then do a series of steps to use the SL armature to reshape it back to a T-pose.


If you have Avastar, this is extremely easy because it's a built-in feature. You simply pose the Avastar model to closely match your desired model, then use Avatar's one-click parenting utility to do the rest. This will use Avastar's build-in weight transfer to give you reasonable starting weights and it will alter your new avatar's mesh to be in T-pose. Then tweak the weights further as required.


If you don't have Avastar you'll need to do it the hard way and it has been a long time since I last did this so I hope I am remembering the correct order of steps.

  • open the SL armature (I strongly recommend using the standard one we looked at in Part IV of this series but it you want to you could also use the fitted one we used in Part V as long as it will require no edits)
  • import your desired avatar model (usually onto a different layer) which I'll call the "target" model
  • pose Ruth to closely match your target model's pose keeping a careful record of the exact bone translations you used for each and every bone
  • while still in pose mode, apply this pose as the rest pose to the armature (Pose > Apply > Apply Pose as Rest Pose)
  • add the armature modifier to your target model
  • do a weight transfer from Ruth to your target and then delete Ruth
  • optimize these weights (ie do all of your main weighting work using this modified T-pose) to have the target respond to the armature with the best overall movement and cleanest mesh transformations possible
  • refer back to your list of the bone transformations you made to go from the original SL T-pose to this adjusted one, and pose the model by reversing them...this will bring the model back into a Ruth T-pose shape
  • select your target model, go to the Modifiers tab, and click the "Apply" button to apply this reversed pose to your model
  • select the armature and apply the pose as the new rest pose (or delete this one and reload another copy of the original armature instead)
  • select the target model and add a new armature modifier to it for this armature
  • since your target already has weights for the bones it should now respond correctly to the armature although it might need some additional tweaking
Whether you have Avastar or do it the "hard" way, you should expect this to require a certain amount of fixing of your mesh since it will be deformed and stretched and probably won't have optimum topology once in its new pose.

The Even More Painful Way

If worst comes to worst, you'll have to use other mesh editing and sculpting methods to edit your original model into a SL T-pose shape but this can be an extremely frustrating and time-consuming process. I'd consider it a last resort, at best, and more likely a clear indication that you might want to remake the model from scratch or find an alternate one to work with.

If you're good at working with lattices, curves and other deformation modifiers you can give it a try, or potentially just make a custom armature for it, then use that armature to repose it as per the Pre-Pose method above. Don't expect it to be an easy or quick exercise, though.

Armature Edits

Many models will not match the SL avatar in terms of proportions, even after global scaling of them (remember to apply that scaling). This shouldn't be too surprising since the SL avatar has a rather glaring number of non-human proportions that makes one wonder if the original designer was in any way familiar with human anatomy. You can improve the physical appearance by using a more human model, but this will often require adjustments to the armature by editing it.

If you make edits to the traditional SL armature, the collision volumes and attachment points will self-adjust in response to this once in-world and with avatar weights assigned only to the standard bones this won't cause any problems at all. As long as the edits are fairly minor, most animations will continue to look reasonably good in world.

While I haven't done extensive testing of it, my initial attempts to edit the fitted mesh armature bones produced highly unsatisfactory results, making me suspect that the import mechanism doesn't faithfully respect edits to any bone other than the traditional set. This isn't really all that big an issue, though, since fitted mesh armature edits would give you no advantage at all (since you'll have to make custom clothing anyway). For a custom avatar I would stick with the standard armature unless you absolutely have to have bouncing body parts that you can't accurately preview while working in Blender.

Remember that any time you edit the armature you will need to test the range of movement response of your mesh for any parts of it that are already weighted to the affected bones. Their deforms will change if the center of bone mass or joint position changes and will need to be adjusted to reflect the new shape and behaviour of the bone.

Scaling: Giants and Tinies

You can make enormous or tiny avatars simply by scaling both the mesh and armature in Blender and applying the transformations prior to export. When you import these in-world you'll need to use a z-offset in your upload settings to get your feet back on the ground again. It's possible that someone has figured out a formula to calculate the exact necessary offset value but I haven't done enough work of this type to go looking for it so I used the good old "trial and error" method.

AO animations, dances, and other animations based on your standing position should continue to work properly in terms of bone rotations; but any that require a specific non-root avatar location (sit target) should be expected to produce highly undesirable results that find you high above (or deep below) where you're expecting to be.

As I say, this isn't an area that I work with, personally, so you might want to consult another source for more specific (and helpful and accurately tested) information if this is something that interests you.

Avatar Weighting Methodology

The standard SL avatar is a somewhat unusual one -- in industry terms -- because almost no vertices have more than two bone weights (I was tempted to write "none do" but I haven't checked each and every single one to confirm that). I refer to this as a "dual-weighted" mesh.

The fitted mesh avatar gives the illusion of having multiple bone weights -- and technically it does since you're assigning fitted mesh bone groups -- but from a practical viewpoint that still remains a simple dual-weighted mesh since the response to the bones that actually affect movement through animation continues to be almost entirely dual. The extra weights are only affected independently by shape sliders, not by animation.

Dual-weighting is extremely easy and very fast to work with. Unfortunately it doesn't result in body movement that is very natural. The real human body responds (stretches and bends) automatically to a whole series of interconnected tissue and muscle motion where no single bone or pair of bones is responded to in isolation.

It is possible to re-weight an avatar mesh to far more closely mimic real human motion by using what I call "tri-weighting" and "quad-weighting" methodologies. In this usage, "tri" and "quad" don't refer to the number of sides of a poly; instead, they refer to how many bones affect most vertices' movement.

A "tri-weighted" mesh will have a large number of vertices that react to three different bones, and only a small number at the extremities that only pay attention to a single bone or two. This can give far more realistic motion for the shoulders, neck, and torso but is a more difficult weighting method to work with since it requires balancing three weights on those vertices instead of two.

A "quad-weighted" mesh is much the same idea except some regions will be weighted to react to four bones. The areas that benefit most from this are the shoulders and hip area but it is considerably harder to balance four overlapping sets of weights than it is to manage three (and dual-weighted is infinitely easier).

In my next -- and final -- installment of this series I will give some practical guidelines for tri-weighting and quad-weighting. While those are of primary interest to people using custom avatars, the technique involved can also apply to mesh clothing for both the traditional and fitted mesh armatures.

Saturday, 14 November 2015

TUTORIAL: Principles of Blender Rigging and Weighting - Part VI

This is a continuation of my series of tutorials on the principles of Blender rigging and weighting for use in the SL/Opensim environment. You'll find links to parts I-V on my list of tutorials page in the "moderate" section.

Today we'll be looking at an extremely basic clothing item and learning how to rig and weight it to the collision ("fitted mesh") armature we explored in Part V, so load up your saved copy of that. While you're at it, you might want to brew a fresh pot of coffee or tea since this is going to be a very long installment.

Note: for this tutorial I'll be assuming that you haven't purchased the Avastar add-on for Blender and need to do it using the base SL-Wiki file instead. Avastar has full instructions and both text and video tutorials to explain how to work with its built-in aides. I still strongly suggest using the method for initial weighting that I describe here since it usually gives better starting weights than the method that Avastar uses (their method pre-dates the latest upgrade in Blender 2.74+).

Remember that if you're directly loading the .blend file from the SL Wiki, you'll want to rotate both avatar and armature by 90 degrees on the z-axis to ensure that it's symmetrical on the x-axis and facing in the negative-y-axis direction (Ruth will be facing you in Blender's front view - numpad1).

To avoid making this any longer than necessary we'll work with a clothing item that's extremely quick and easy to make: a strapless dress that hangs to the mid thigh. When following my instructions for this, don't spend very much time making it look pretty...we're just making something very basic to use as a test object for our work.

Model the Clothing Item

If you prefer to use a somewhat different modeling method to make your dress object, by all means do so. Just ensure that your dress remains symmetrical on the x-axis and that it extends to somewhere around mid-thigh. My very quick step-by-step for making our clothing item:

Skirt step:
  1. Add a mesh cylinder to the scene with a 48-vertex circumference, radius of 0.20, and no end-caps.
  2. Set shading to smooth and give it the name "skirt"
  3. Switch into edit mode and turn on the x-mirror option so we remain symmetrical on the x-axis (which will make things a lot easier for us later).
  4.  Adjust the upper edge to be approximately on the line of Ruth's hip crest and the lower edge to be about mid-thigh.
  5. Scale on the y-axis to compress it closer to the abdomen and butt. If a little bit of Ruth's body pokes through slightly, that's fine for now.
  6. Loop-cut approximately 12 times...I generally start with a little too much geometry and remove the excess later.
  7. Switch back to Object mode
Blouse step:
  1. Add a new mesh cylinder object to the scene with the same settings you used for the skirt
  2. Set shading to smooth and name it "blouse"
  3. Switch into Edit mode and enable x-mirror
  4. Adjust the bottom edge to be slightly below the narrowest part of Ruth's waist
  5. Adjust the upper edge to be at about the top of the hip, leaving gap between it and the top of your skirt model. At the rear it will be roughly where the line of the left and right butt cheeks meet at the spine.
  6. Rotate the upper edge on the x-axis to make it higher at the front and lower at the back
  7. Do a single loop-cut and slide so the cut is just slightly below the line of the bottom of the breast
  8. Loop-cut the resulting lower section by about 6 to make each quad roughly square
  9. Loop-cut the upper section by about 8-10 to give us some extra geometry to work with for the curve of the breast
  10. Switch back into Object mode.
  11. Add a shrinkwrap modifier with
    • target set to "BaseFemale"
    • offset 0.005
    • mode set to "Project"
    • both positive and negative direction enabled
  12. Optional
    • turn off the modifier preview for the shrinkwrap
    • add a lattice to the scene, scaled to enclose your cylinder
    • and a lattice modifier to the blouse, assign the lattice as its object and move it above the shrinkwrap modifier in the stack
    • turn the shrinkwrap modfier's preview back on
    • use the lattice to do further shaping adjustments for the upper portion of the blouse to get a more natural line -- you can only control the vertical positioning/line this way since shrinkwrap will have it hug the body. Don't worry at all about the bottom line.
  13. Again, don't worry if there's a little poke-through of Ruth's body
  14. Apply the modifier(s) and delete the lattice if you did the optional extra shaping
Dress step:
  1. Select the blouse and skirt objects and join them into a single mesh, renaming it to "dress"
  2. Switch into edit mode
  3.  Select the bottom loop of the blouse section and top loop of the skirt section then use Mesh>Edges>Bridge Edge Loops to fill in the gap between the two
  4. Loop-cut that newly-created set of faces to give them roughly square faces
  5. Use any combination of techniques you prefer to smooth the transition between our two portions such as:
    • smooth vertices in Edit mode with gradually expanding selection area
    • manual edits with proportional editing enabled (hotkey o)
    • switching to Sculpt mode (remember to enable x-axis symmetry) and use those tools
    • smooth modifier
    • manipulate using lattice & lattice modifier
  6. While you're doing that, also fix any poke-through areas and if want to you can do some quick additional shaping.
  7. When you're finished and after applying all modifiers, switch into edit mode
  8. Select all and use the menu option "Mesh > Snap to Symmetry" just to be sure that the dress is perfectly symmetrical.
Remember that we're just looking for a quick & dirty dress model to work with for our weighting exercise so you don't need to make it even remotely perfect. The total time I spent to make mine was less than 15 minutes.

Needless to say, clothing items don't need to be symmetrical and often aren't. I can promise you, however, that weighting with a symmetrical item is much, much easier -- particularly a dress or skirt where the mesh bridges the space between left and right legs.

I strongly recommend that your first attempts at weighting be done with symmetrical clothing and that you branch out to asymmetrical objects later once you've developed a feel for it. Even then, you'll almost certainly want to take my suggestion from an earlier tutorial and have a fully symmetric weight source blank to work with. It will save you a lot of time and effort.

Rigging the Dress

When you speak to people in-world who work with rigged mesh it can often sound like the "rigging" part of rigging and weighting is some difficult chore. It isn't (unless you're doing extremely advanced work or rigging for non-SL/Opensim projects).

Select your dress and add an armature modifier to it exactly the way we did way back in Part II of this series. The object we assign to it is "armature" (that's the name it has in the SL file) and we will only be binding it to Vertex Groups.

Ta-da! Rigging is done.

If you want to, you could temporarily enable the "Bone Envelopes" binding option of the modifier and play with the armature (in Pose mode) just to get a sense of how poorly it works as a binding for this sort of object. Just remember to disable that again and zero any changes to your armature before proceeding.

Although unnecessary, it's common practice to parent the dress (and body and anything else) to the armature so they appear as hierarchical children of the armature. For purely SL/Opensim purposes it's not necessary although it does help you keep track of what has and hasn't yet been bound to an armature. If you're working with complex scenes for subsequent Blender rendering it can be extremely useful.

Initial Weighting of the Dress

In Part III of this series we used Blender's "Assign Automatic from Bones" capability to generate our initial set of bone weights for a simple cylinder mesh. While that is usually the method to use when working from scratch, that isn't the case here and won't be for any clothing (or jewellery) item you make.

The distinction is our main goal isn't to make the dress move nicely based on bone movements. Instead, it's to make the dress move as nicely as possible with the avatar's movement. To achieve this, we need the weights of our dress's vertices to match, as closely as possible, the weights of the nearest underlying part of the avatar's mesh. The bones move the avatar and we want the dress to mirror that.

Areas where these are different will become problem areas when the avatar moves and will almost always require alpha-masking of the body to hide poke-through. We want (usually) to minimize or even eliminate the need for a custom alpha mask, so of prime importance to us is how the dress weights relate to the nearest avatar weights. We don't have the ability to change any weights in the avatar (unless you use a custom mesh one) so that means the onus is on us getting the weights right on the dress.

In essence, then, our objective is really to "transfer" the weights from our avatar to our dress as best we can, then fix or improve any problem areas.

As you'll undoubtedly know if you've worked with Blender for any length of time, there are frequently multiple different ways to do something and often more than one way to do the same thing. Weight transfer is one of those things.

The particular thing we're doing is a part of Blender that has changed rather dramatically in the last year or two and I don't remember precisely which changes were introduced with which version although, if memory serves, there was a major overhaul with Blender 2.74, some tweaks in 2.75, and even further tweaks with 2.76. Since this is an active area of development, it may continue to change or be refined in future versions.

My pictures/observations/instructions are based on Blender 2.76 (current as of the date this was written) so if you're using any earlier version the options will be a little different.

Blender's weight transfer can be done in two ways:
  • as a "Data Transfer" modifier applied to the target object, or
  • by selecting the source object first, then shift-selecting the target object, then entering Weight Paint mode, then using "transfer weights" (either from the toolshelf or the Weights menu)
It doesn't matter which method you use since the results are the same. If you use the modifier approach you can pre-pose the armature into a non-zeroed pose, then add the modifier and move it above the armature modifier in the stack, select the method and options, then apply it (you must apply before you can do any subsequent tweaking). If you use the Weight Paint mode transfer approach, you must ensure that your armature is zeroed before you use it (there are actually a few exceptions to that rule, but that's a more advanced subject for another time).

Most of the time I personally use the Weight Paint mode transfer method but that's probably as much a result of habit as anything else (and I think when I began working with weighting, weight transfer as a modifier either didn't exist or has drastically changed since then). That's the method we'll use today.

Optional but recommended: select the armature and switch it into Pose mode. Then select all bones. This will allow you to use one of the transfer methods which happens to be the one I prefer since it generally produces the best starting point for this type of work. Leave the armature in pose mode.

Select your BaseFemale mesh (the "source" of our weights) then shift-select your dress (the "target" for the weights) then switch into Weight Paint mode.

If you haven't already done so, once you're in weight paint mode:
  • in the toolshelf's "Tools" tab turn the "auto-normalize" brush option on (SL/Opensim requires this)
  • in the "Options" tab enable X Mirror and ensure that Topology mirror is off
  • in the same tab set "Show Zero Weights" for "Active" (your dress will go black)
  • if you preferred "spray" to be enabled when you were playing with weights in the earlier parts of this tutorial, enable it too...that's purely a matter of personal preference
  • I also like to enable the "restrict" option which prevents you from accidentally brushing weights to any vertex that doesn't already have that bone group assigned to it. When I need to do so, I briefly disable it again, do my brushing (carefully!), then re-enable it so I don't forget.
  • enable face selection masking so I can watch the effect of movement on my topology when I'm tweaking it later...you can always wait until you begin tweaking before you do so
  • in the Properties Pane, select the Data Objects tab (upside down triangle)
Now click the "Transfer Weights" button on the toolshelf's "Tools" tab (Weights section) or use the menu option Weights > Transfer Weights.

In the toolshelf's most recent actions section are all of the options for weight transfer (see below). Remember that when using this method you have to select any options now because as soon as you do anything else the most recent action will cease to be the transfer. With the modifier approach you don't have to worry about that and the modifier has the identical set of options. With this method you can always just re-do the transfer, though.

There are a few things you're allowed to do that won't count as an "action" to prevent you from changing the transfer options. You can toggle face selection masking on and off, and you can select any of the newly-populated bone group names from the vertex group list in the Data Object pane. This lets you easily see the effect of the options on the mesh without making it impossible to change to a different one. Do not select a bone group using the ctrl-select method. It will work but it will also
be considered a new action, preventing you from making any changes.

Weight transfers work by looking at each and every vertex on the target mesh, one by one, then assigning each one a weight (or multiple weights) based on the options you select. Each time you change a transfer option, the transfer is recalculated to reflect that change for each vertex of the target.

UPDATE 2016-08-02: This has changed a little under Blender 2.77. Please see this follow-up post for the settings suitable for 2.77 and later, then return to this post to continue reading.

The weight transfer options and my recommendations are:
  • Freeze Operator: Disabled
    You should never need to enable this since all it does is stop any changes you make to any of the other settings from being recalculated immediately and the only time this will have any significant speed benefit is if your clothing mesh has an insanely high poly count which means it's completely unsuitable to Opensim anyway.
     
  • Data Type: Vertex Groups
    There are other types of data that can be transferred but the one we want is the vertex (bone) groups. You might want to have a look at the full list just to see what other nifty time-saving options are here for other data types.
     
  • Create Data: Enabled
    This lets new vertex groups be added if they don't already exist which, in our case, is all of them. For weight transfer (vertex group data) I can't think of any case where you wouldn't enable it.
     
  • Vertex Mapping: (various)
    The method of vertex mapping you select has a huge impact on how much subsequent tweaking you're likely to need to do and the choice will depend a little on the type of object you're working with. It also affects (slightly) the other options you'll need to choose.

    This deserves its own separate "discussion" which you'll find immediately following this section (see below).
     
  • Auto Transform: Disabled
    Because both our source and target objects are in their "zero" positions with all transformations applied, this isn't needed. It would only be in rare (and advanced) situations that you might benefit from enabling it.
     
  • Object Transform: Enabled
    Again, this isn't required because we're working with zeroed objects where all transformations have been applied. By default it is enabled which is fine, too, so you can just leave it at its default.
     
  • Only Neighbor Geometry / Ray Radius: Disabled / 0.0
    This is a pair of options that go together. If you leave it disabled, as I recommend, the ray radius is ignored. Enabling it limits how far away the transfer will look when it tries to find a source for each target vertex. The distance is determined by the ray radius setting and if there's no part of the source mesh within that radius it doesn't assign any weights to the target vertex. Since SL/Opensim requires that all vertices have at least one weight, disabling this option ensures that (even if we have to go and tweak them later).
     
  • Source Layers: By Name
    For our purposes always select "By Name" although in most cases either will work equally well. Describing exactly what this means is beyond the scope of this tutorial.
     
  • Destination Layer Matching: (various)
    Your best choice here depends on the method you select for vertex mapping which we'll talk about in the next section of this tutorial. For our purposes it will usually be either "Selected Pose Bones" (but only if you've selected all bones in the armature while in pose mode as I suggested above) or "All Layers". (see below)
     
  • Mix Mode / Mix Factor: Replace / 1.0
    This is another pair of related options. The mix mode determines how the source weights are applied to the the vertices of target mesh and the various options only become relevant when you want to combine weights from various sources or only selectively adjust or replace weights. The factor determines what percentage of the weight to apply.

    In our case we don't have any preexisting weights so the default "replace" option and mix factor of 1.0 (100%) is perfect. If you begin doing advanced work there may be occasions where you'll consider using the mix option (and a weight <1.0) or one of the thresholds (the mix factor then becomes the threshold value).
Any time you change an option everything is recalculated which also means that if you're selecting bones from the list of vertex groups you'll need to keep re-selecting them (which is a bit of a nuisance) each time you change something.

As I mentioned above, the vertex mapping method and corresponding destination layer matching choice are the two most important settings in determining how the transfer works and deserve their own separate section in this tutorial.

Vertex Mapping Options

I'll try to give you general guidelines for each mapping option but until you've worked with it for a while you'll find it very difficult to tell which one you'll want just by looking at the weight colours on the mesh. It's something you need to develop an eye for based on experience.

My personal order of preference for the vertex mapping and destination layer matching options:
  • Nearest Face Interpolated : Selected Pose Bones
    This looks at each vertex on the target mesh and determines what the nearest face of the source mesh is (nearest in terms of global space). It then considers the weights of the vertices of that source face and assigns a weight to the target vertex based on that.

    This option has changed with Blender 2.76 (which is brand new at this time so possibly this is a bug?) and to get sensible results now seems to require that you have first put the armature into pose mode and selected all bones; and then when doing the transfer you need to use "Selected Pose Bones" as your destination layer matching. I'm not entirely certain why this has changed or why this matching method is the only one that provides the expected results...I just figured it out through trial and error. If someone happens to know, I'd love to be enlightened.

    EDIT: Versions 2.76-2.76b have a bug for this method which cause it to behave unpredictably in many cases. I'm current using a beta build (nightly Nov 25th) where this has been fixed, works reliably, and no longer requires the full armature to be pre-selected.

    This has been my go-to method since its introduction and has almost always given me the best resulting starting point for weights, provided the distances between the source faces and corresponding target faces aren't too great. This is the method I used this time and show in the accompanying picture.
     
  • Projected Face Interpolated : All Layers
    This is a very similar method except it limits where the transfer will look for a source by only projecting the search along the target vertex's normal until it intersects the source mesh. This will result in it ignoring source faces that nearby but not in the right direction. You'll usually want to use "All Layers" for your destination layer matching.

    In many cases this won't give you the best starting point weights and will result in a lot of areas you'll need to fix (under the breasts, armpits, or portions of the mesh that might be folded) however it's extremely useful for something like a pair of pants/shorts where you want to ensure that the left leg of the object gets weighted to Ruth's left leg even though her right leg is slightly closer in global space.

    Also beware: unlike all other methods, this method will not assign any weight if it doesn't encounter a source face when it does the search projection. For something like our dress you would find a set of vertices between the legs where that happens and which must be fixed before the mesh can be uploaded. You'll almost always need to fix them anyway, no matter what mapping method you use, so that isn't quite as problematic as it might seem.
     
  • Nearest Vertex : All Layers
    My third go-to choice is similar to the nearest face option except it simply looks for the nearest vertex (in global space) on the source mesh and uses its exact values.

    This works beautifully if your clothing item was made by taking the source mesh and scaling it slightly along its normals since the nearest vertex will almost always have the exact weight you want your clothing to use (assuming your source was Ruth or something already perfectly weighted to Ruth). If you've scaled it significantly relative to the source it might not be quite as good an option.

    The key thing to remember with this method is it doesn't take into account how the nearest part of Ruth's mesh will move, so if your target vertex is directly above the middle of a source face that deforms a lot, you'll almost always have to do some weight readjustments later.
     
  • Nearest Edge Interpolated: All Layers
    This does almost the same thing as the nearest face interpolated option except it looks for the nearest edge on the source layer and then considers the vertices at either end of it to determine the weight for the target vertex.

    For mysterious reasons that I still haven't figured out, this appears to work perfectly with the All Layers choice for destination mapping whereas the face version of it requires the selected pose bones. One day I hope to understand why (or find out that it's a bug).

    This choice tends to provide better results than the interpolated face version if the topology of your target is a lot finer than that of your source (ie you have a lot more vertices in your target than you do in your source). Normally this won't be the case for basic clothing items but it could be if you're doing delicately modeled draping (but watch your poly counts!).
     
  • Everything Else
    There are other options for the vertex mapping and destination layer matching but in my experience they almost never give better starting point results as one of the above four.

    Many of these options are very new (Blender 2.74+) so I must confess to having a certain bias for my tried-and-true ones that have been around in earlier versions and that I'm accustomed to working with. You might find it a worthwhile exercise to experiment with them and you may discover some other combination that works well for you.
For more information on all of the options you can check the latest updates to the Blender Reference Manual.

Now What?

I now disable selection of the Ruth mesh by clicking on its selection control icon in the outliner. This will make it much easier to use the ctrl-select method to select armature bones for subsequent posing. If for some reason you need to select her again later, you can always enabled it again.

For fitted mesh weighting, the next step is to go to your vertex groups list in the Data Object pane and delete all mBone grops from the list by selecting each and clicking the "-" button immediately to the right of the list.

While you're doing that, also delete any of the fitted mesh bone groups that don't have anywhere on the dress that ought to have any weights for it. In this example that's the bones for the arms, lower legs, and head and neck. You may see slight weights for the L_UPPER_ARM and R_UPPER_ARM but most likely they're so minute that they can safely be removed. You'll almost certainly need to keep the two clavicle bones. Unless your dress goes down to the knees, remove the lower leg bones too since the weights will be minimal and their motion shouldn't cause the dress to move.

Most likely you'll be left with only a dozen or so bones in the list (see picture). This is a lot easier to work with than a very lengthy list that's cluttered up with bones that aren't being used. Obviously the bones that are "safe" to remove depends entirely on the object you're weighting. The list for a full length dress with a high collar and sleeves will need to keep almost all of the fitted bones. A necklace or bracelet might only have 2 or 3.

Next, we want to normalize all of the remaining weights. Fitted mesh doesn't demand this (the traditional armature does) but it's a good idea to do so anyway. Click the "Normalize All" button on the toolshelf. Immediately after doing so, in the most recent actions section make sure you select the option to do it for "All Groups" (default) and disable the "Lock Active" option (which is enabled by default).

What this does is ensure that for each vertex, the sum of its weights equals 1.0 and by disabling the lock active we ensure that any weights that have to be adjusted are done proportionally to all bones, including whichever one happens to be currently selected. When that option is enabled, no weights for that bone will be changed and normalization is done for all other bones. There are occasions when you may want to do that but this isn't one of them.

One more preliminary step: click the "Clean" button and then in the most recent actions section change the Subset from the default setting to "All Groups" and leave the Keep Single option un-checked.

When the weight transfer is initially made each bone group is assigned to every vertex on the target mesh with a weight of 0.0, then the values are calculated. This will leave each vertex with large numbers of 0.0-weight bone assignments that subsequently makes it a little harder to work with and can lead to some unusual results when you're tweaking the weights. It also defeats the purpose of the "restrict" option because that only prevents new bones weights from being added by accident, but not from weight being given to a bone that is assigned to the vertex but currently has no weight.

If you're working with the traditional armature instead of the fitted one, there's a catch: SL/Opensim requires that all vertices have weights assigned for all bones, so cleaning will make the mesh invalid for upload. If you have the Avastar add-on it will automatically assign them for you at the time of export (with 0 weight for the ones added). If you don't, you'll need to finish by doing another weight transfer when you're finished, with the mix mode set to "mix" and the factor set to 0.0. That will put the "missing" zero-weight bone groups back for each vertex.


This is a very good time to pray, if you believe in that sort of thing.

Identify Problem Areas


If you're very lucky the transferred weights will be perfect and you won't need to do any tweaking at all. That won't be the case for us because even if the majority of the mesh is pretty good, the portion of skirt that bridges the gap between the legs will be a very abrupt, sharp transition.

If you were using a pre-made dress blank as your source (as I mentioned earlier when I linked to another of my tutorials) you'll have already gone through our next chore and the transfer might be close enough to perfect to need almost no further tweaking.

What we want to do now is identify problem areas of our dress mesh weighting. These are areas that either allow Ruth's body to poke through when a bone is moved or where the way the dress moves is "wrong" relative to the way it you want it to move.

Start ctrl-selecting mBones of the armature and rotate them through a range of motion that would be typical for that bone in-world. As you're doing so, be careful not to accidentally paint with your weight brush or it will add that bone back into our vertex group list (though you can immediately remove it again if it happens).

In our SL/Opensim world we have a very low poly (and in my opinion extremely poorly modeled and weighted) avatar and an extremely simplistic armature (again in my opinion, very poorly designed) so there are a lot of limits on what can reasonably be achieved.

In particular, the way the torso bends is going to be a constant source of problems when the motion is at all towards the extremes. You'll also find that armpits, elbows, groin, knees, and ankles will be frequent areas with issues. With dresses where the starting weights are taken from Ruth instead of a dress blank, you'll always have a very sharp, ugly transition between the legs at this point.

Each time you identify a problem spot, you'll need to decide whether to:
  • try editing/sculpting the mesh out away from the body a little so poke-through no longer happens, or
  • try to tweak the weights to improve it, or
  • make an alpha mask for the avatar to wear to make the poke-through invisible there
I'll assume that if you're even thinking about working with rigged mesh clothing you're already familiar with all but the second option so let's look at that.

Mesh poke-through typically results from 2 causes:
  • weighting in that area that doesn't match the underlying mesh's weights accurately enough, or
  • a mismatch of the topology resolution of the clothing mesh when compared to the underlying avatar mesh -- or what I think of as the "truck turning a corner" issue*
* The truck turning a corner issue is where one fixed face rotates and the underlying avatar mesh in that area has a pivot point that's somewhere in the middle of that face. Since the pivot points are different, they'll overlap just like the problem you'd see trying to get a semi-trailer to turn a tight corner on the road. It can't be done.

If it's the former, it's simply a matter of tweaking the weights until they're correct. In the case of the latter there are several possible solutions (often requiring more than one):
  • you can try remodeling that area of the mesh by adding/removing topology to make it far more closely match the topology of the body mesh in that area...ideally the clothing item's vertices and edges will very closely match those of the adjacent part of the Ruth mesh
  • you can move that area of the clothing mesh it a little further away from the body so it doesn't poke through until the rotation becomes more extreme than a body will normally require
  • try tweaking weights in that area to see if you can get it to go away anyway -- something that you might be able to do if the clothing topology is higher resolution than Ruth's

Weight Tweaking

There are a few basic rules when it come to working with rigged mesh for SL/Opensim:
  • every vertex on the mesh must have at least one non-zero bone weight
  • with the traditional armature all weights must be normalized and, in my opinion, it's a good idea of normalize the fitted bone weights as well
  • you're allowed to mix fitted and traditional bone weights in a mesh's weighting but in my opinion it's a bad idea and often leads to confusion while working with it...I highly recommend using one or the other, not both
  • there has been a certain amount of debate about the maximum number of non-zero bone weights a single vertex can actually have...the documentation says 4 but in practice it is possible to upload a mesh that violates that and still appears to move correctly; however I'd still treat 4 as the limit
  • in the base SL avatar, no vertex has more than 2 traditional bone weights
  • in the fitted mesh avatar file, some vertices have 3 bone weights (a small number have 4)
I make a point of talking about the number of bone weights a vertex can have because your approach to weight tweaking will depend on how many weights you're working with in a given region.

The easy way to check is to tab into edit mode (TAB always toggles back and forth between edit mode and whatever mode you were in prior to that) and select a single vertex. On the 3D View pane's properties panel (hotkey N toggles visibility) is a section called "vertex weights" where you will see a list of all vertex groups assigned to it.

If we hadn't done the tidying up of bone groups and then "cleaned" the mesh earlier, you'd see a list of 60+ bones for every vertex, most of them with values of 0.0. Because we did, you'll now only see the ones that actually have some weight. You might need to drag the panel a little wider to see it in decimal detail.

By selecting a few vertices in that area, one by one, you can see how many bones are commonly being used in that vicinity. Of course you can also check this, visually, by looking at the mesh in weight paint mode and selecting the bones one by one. Both methods are useful.

While we're here, though, it's worth pointing out a few things about weights in edit mode since they can be very handy.
  • If you edit the topology by moving vertices around, their weights will remain unchanged (that's also true when you're in sculpt mode)
  • If you add a new loop-cut, or subdivide an edge, the newly-created topology is automatically assigned weights "intelligently" based on where each new vertex is added relative to the weights of the preexisting vertices nearby. That's a huge time-saver!
  • You can manually change the weight of a bone for a single vertex by selecting it and changing that displayed value.
  • As long as X-Mirror option is enabled for the mesh in edit mode, it will mirror that change on the mirrored vertex and will be aware of the left-right bone mirroring (so changing LEFT_PEC on one vertex will make the identical change to RIGHT_PEC for its mirror). It won't do that if X-Mirror isn't enabled, even if it's enabled in weight paint mode. They're two distinct modes so you have to remember to enable both.
  • Your auto-normalize setting in Weight Paint is ignored in Edit mode so you will need to click the "Normalize" button to do so after making a change.
  • If you select multiple vertices, the value shown here is the weights of the currently active vertex, not the average of them all
  • With multiple vertices selected, you can click the little "copy" symbol to the right of the weight to have that value applied to all of the selected vertices
  • With multiple vertices selected, you can click the "Copy" button at the bottom (beside the Normalize button) to copy all the bone weight values of the active selected vertex to all of the other selected vertices.
  • When using the above two copy methods, if a vertex doesn't already have that bone group assigned to it as a weight the new bone group is NOT created or normalized. You have to add it first. It's easy to forget that...
  • Clicking the "X" button to the right of a weight removes that weight group assignment for the selected vertex (but only for that vertex if you have multiple vertices selected).
  • Any selection you make in edit mode is preserved as a selection when you return to Weight Paint mode. If you have either face selection masking or vertex selection masking enabled in weight paint mode you can only paint changes for vertices that are selected (otherwise you can paint anywhere). This is a great way to avoid accidents
  • Anything you hide while in edit mode will also remain hidden in weight paint mode
  • The assorted hide/unhide hotkeys (H, shift-H, Alt-H) and the global area selection hotkeys (A, C, B, ctrl-I) also work in weight paint mode when either of the masking modes is enabled
  • There are probably a few other nifty things that I do instinctively but am forgetting at the moment
When tweaking weights you should always only rotate one bone at a time, and you should always use the mBones for posing. Once you've tweaked the weights all of those, one by one, you can then come back and check the response to movement of the fitted mesh bones. Normally it's only the bones involved in avatar physics that are likely to cause problems (the pecs, butt, and belly).

Getting every single one of them perfect is (in my opinion) an exercise in frustration so you'll have to decide just how long you're willing to minutely tweak things rather than just alpha-masking or pulling that part of the mesh a little futher away from the body.

The best workflow that I've developed for this process is to always start at the extremities (which will have only 1 or two bones weighted to them) and/or to work outwards from the root (pelvis) bone, leaving the "trouble" areas until last.

With each bone, move it to a natural extreme for x-axis rotation and tweak the weights until that looks right. Then move it to the opposite natural extreme for that rotation and tweak for that. Repeat that with y-axis rotation for each extreme, then repeat for z-axis rotations. If you're able to get all three axes to look good at both extremes, you've got the right weights and it should look perfect no matter what mixture of the 3 you use.

If it's impossible to get both extremes of the same axis' rotation to look good, you're suffering from the "truck turning a corner" issue and will need to adjust the mesh by editing its topology or clearance.

I'll give you some more practical guidelines to tweaking in a moment, but first let's deal with the major issue of the horrid crease of weights on the dress between the legs.

Why Dresses and Skirts Are a PITA

In this case, PITA isn't a middle-eastern type of bread. It's my acronym for "pain in the posterior" except substituting a more vulgar word for posterior.

Whenever you transfer weights from Ruth's legs to something that crosses between them, you'll see a very distinct demarcation line between the vertices that are given weights for the right upper leg and the ones that are given weight for the left upper leg (or mHipLeft and mHipRight if you're using the traditional armature).

This happens in all of the transfer methods and is why I advocate making a dress blank to use in future as your weight source. In many cases, a row of vertices that is precisely in the center between the two will be given no weight at all.

There's a trick to dealing with this area. I'll describe the one for fitted mesh but the same technique works for the classic armature too.
  • If your armature has any translations, zero them
  • Make sure the "Auto-normalize" brush option is enabled
  • Disable the "Restrict" weighting option if it's enabled
  • Make sure the "X Mirror" weighting option is enabled
  • If you ignored my suggestion earlier and your dress mesh isn't modeled symmetrically, enable topology mirror weighting option, pray a lot, and promise yourself to make a dress blank weight source later that is symmetrical...prepare to curse...a lot...(if it is symmetrical, congratulate yourself for having saved yourself a lot of frustration and don't enable topology mirror)
  • Look at the front of the dress and check to see if any vertices have weights for the BUTT bone. If they do, switch to the subtract brush and remove them completely, then click the "Clean" button on the toolshelf (options: All Groups and "Keep Simple" disabled)
  • Select the blur brush and set the strength to 0.001 (keep weight at 1.0)
  • Select the L-UPPER_LEG bone from the vertex groups list in the Data Objects pane
  • Paint this very soft blur to include the vertices on the right side of the dress to about 1/4 to 1/3 of the way across the width of the right leg and all vertices in between (see picture)
  • When you do this, don't be surprised when a sudden row of green appears right up the middle of the dress since that will always happen
  • Select the R_UPPER_LEG bone and make sure that what you just did with the left leg was correctly mirrored (it should have been)
  • If any areas were missed, brush them softly with the blur again
  • Repeat this for the rear of the dress 
It's possible that during the initial weight transfer there will be a vertex on the left side of the dress that received no weights at all or received a weight for the right leg instead of the left. When you do the soft blur it will put an unexpected red dot on the wrong side of the mesh, creating a "problem pair" (see picture). To fix that, tab into edit mode, select one of the two vertices and manually reverse their weight values. As long as you've enabled x-mirror that will also fix the other vertex. Then tab back out.
  • While still looking at the rear of the dress, select the BUTT bone and using the same soft blur brush extend its area of influence down to fill any empty vertices in that center seam
  • Repeat that with the PELVIS bone
  • Look back at the front of the dress and repeat yet again with the PELVIS bone
  • Tab into edit mode
  • For the front of the dress: select the vertex at the very bottom of the central line.
  • Then shift-select the vertex immediate to the right of it
  • If the vertex to the right has any weight for the PELVIS bone, click the little "copy" icon immediately to the right of the weight which will copy that weight back to the center vertex, If it doesn't have a weight, move on to the next. DO NOT CLICK THE NORMALIZE BUTTON.
  • Repeat this, working your way up the seam until you reach the place where the pelvis weight is already about the same in the center as it is at the edge.
  • Repeat this exact same method for the rear of the dress except for each time, copy both the PELVIS and the BUTT bone values
  • Once both front and back are done, tab back to weight paint mode
  • Select the PELVIS bone in the vertex group list (if it isn't already) and click the Normalize All button but this time enable the "Lock Active" option for it in the most recent actions
 At this point if you look at the weights for the butt and the pelvis, they should seem fairly smoothly graduated down the leg (the butt only in the rear, the pelvis in both front and rear). The left and right upper legs should be green up the center lines, front and back, slowly fading as the pelvis (and butt in the rear) gain influence.
  • Re-enable the Restrict option
  • Ctrl-select the mHipLeft bone of the traditional armature and rotate it outwards by about 30 degrees (R Y -30)
  • From the bone group list in the Data Object pane, select the R_UPPER_LEG bone (not the left, the right!)
  • Switch to the add brush and set the strength to about 0.001 or 0.002 (depending on whether you're using spray or not)
  • Start adding weight to the blue portion of the left leg area to even out the spacing of the vertices...you'll notice as you do that a corresponding change occurs on the opposite side. DO NOT change the weights on the line of green vertices that denote the center of the dress, even though they've been dragged to the left by the leg's motion.
  • Once you have it somewhat smooth, zero the y-axis rotation of the mHipLeft bone and move it through about a 45-degree x-axis rotation. You'll likely need to tweak a little to fix poke-through of a thigh. When tweaking, always add thigh weight, don't subtract it (even if this means switching to the opposite UPPER_LEG bone)
  • Repeat all of this on the rear (or the front if you started with the rear)
  • Because everything is being mirrored, anything you do with the left will be identical to anything that would affect right leg movement.
Once you have both front and back done you should have something that looks a bit like the picture above.
  • In the Outliner Pane, select the armature (or switch back into Object mode and select the armature in the 3D View pane.
  • Select the mHipLeft bone, then shift-select the mHipRight bone (unfortunately you can't do this while still in weight paint mode)
  • Zero their rotations (ALT-R)
  • Now rotate both of them forwards by about 45 degrees
  • Keep them both selected and then switch back to your dress in the Outliner Pane (or select the dress and switch it back into weight paint mode)...the two mHip bones will still be selected so you can continue to manipulate their rotations without needing to do that again until you select a different bone
  • Now that our two UPPER_LEG bone weights are correct relative to one another, we need to balance them against the PELVIS bone in the front, and against both PELVIS and BUTT bones in the rear. The front is much easier so let's start there.
  • select the PELVIS bone from the bone groups list then using gentle values of add and subtract and blur brush strokes (~0.001 strength) tweak its weights until the bend in the front looks fairly natural (it's the nature of the this type of system that it will never be completely perfect)
  • Then switch to the BUTT bone and bend both legs backwards by about 30 degrees (as long as they're still selected you can easily do this with hotkeys)
  • Blur the BUTT weights and if necessary add a very small amount but we'll do most of our fixing using the PELVIS bone because it tends to have more influence over thighs
  • Switch to the PELVIS bone and smooth again, and then begin adding weight to push down what will probably be an ugly bulge pushing up from our upper leg weights
  • Again, it will never be perfect but get it to look reasonably natural if you can
  • Do all of your work by adding and subtracting PELVIS weight (and perhaps a little BUTT near the very top of the leg). Avoid adjusting with UPPER_LEG weights...just left them adjust themselves naturally as they're auto-normalized.
  • You'll find that you probably want to add quite a lot of PEVLIS weight as you move lower on the skirt at the rear, but less so at the front. Legs rarely bend backwards more than about 40 degrees but when sitting they'll commonly be rotated forwards by 90 degrees or even more.
Don't be surprised if this takes a while. There's a real art to weight painting and no matter how well I try to describe it, there's no substitute for the feel you get for it through hours and hours of hands-on work. In time, balancing the weights of two bones will become simplistic, for three bones it will be relatively easy, and any day now I'm sure I'll be feeling better about weighting four bones simultaneously (but without a doubt it's tricky).

The unfortunate thing is this part of a dress/skirt moves completely differently on real life where a lot of the movement comes from gravity and cloth physics. Being bound directly to bones prevents any really natural movement from occurring (for instance, when you cross your leg is slips under the fabric without dragging it along for the ride). One day, in our dreams, we'll have real-time cloth draping physics in-world.

When you finish all of this, move each bone individually through its range of motion as well as checking both forward and backward motion of both legs (particularly for sitting) and make any further tweaks necessary. You will always have a little poke-through of the upper thigh whenever you have cross-over weighting like this, but that's a small price to pay in exchange for an overall more natural movement appearance. If it really bothers you, alpha-mask the avatar's upper thighs.

Don't be surprised if this takes you a couple of hours the first time you do it and still doesn't look all that great. Save often, take periodic breaks, brew another pot of something, take the dog for a walk...whatever works for you. It's never fun and always takes time. This is why having a very, very good weight blank or two is worth it. You expend all this time and work once or twice, then you have a weight source to use for all future projects that will drastically reduce how much tweaking is needed (from several hours to as little as 5-10 minutes).

You'll also get a lot better at it the more you work with it. It will become more like second nature and you'll find that you know intuitively which areas will need weight added or subtracted and which bones are best to work with for that zone.

Practical Guidelines for General Tweaking

While this has already become an insanely long tutorial installment, I'll leave you with a few tips that ought to help when tweaking weights in general.

I find that weight-painting is almost as much an art as it is a science. It takes a while to learn and even longer to become proficient. If you're like me, you'll find yourself having a "eureka!" moment where it will also suddenly "click" in your head and make sense, becoming far more predictable and much less scary and time-consuming.

It's really important to be aware at all times how many different bones are affecting the weights of the vertices you're working with. Failing to do so can cause you to waste huge amounts of time.

If an area has only two bones affecting it, it's "easy" in the sense that it doesn't matter if you add or subtract weight from either bone since the net effect is identical.

For areas that have three weights, two of them are usually complementary and overlapping. Never work with the "middle" one unless you absolutely have to. Instead, move and weight based on one of the outer ones, then move and weight based on the other. The net effect of those combined changes in that region will make the middle bone balance itself.

Because working on an area with three or four bones weights is much harder, Linden Lab generally avoided too many zones on the avatar that have that. Those that do usually transfer quite well and will need only minor weight blurring (the dress/skirt being the HUGE exception to that observation).

I've already mentioned working with all bone zeroed and then only changing one bone at a time on the armature, rotating it through x, y and z axis rotations one at a time and through both extremes. If you get each of these balanced, it almost always results in the whole thing being balanced just thanks to auto-normalize.

Even when you've finished working with a bone, go back and check it again if you make any nearby changes that might impact it when you're working on a different bone. It will save uploading something more than once.

If you need to solidify something (like the bottom of a dress so it isn't invisible when you look at the inside of it) DO NOT solidify until AFTER you have completely finished weighting it. Weights are automatically transferred and preserved by the solidify modifier so there's no sense having to waste time trying to match inside and outside weights (which is extremely hard to do). I will almost always leave my solidify modifier in the stack and never apply it until just before I am ready to export.

After you've been working with weighting for a little while, come back and read through this tutorial series again since there are undoubtedly parts of it that won't make a lot of sense when you begin but might become more clear when revisited with a little practice under your belt.

Some weighting issues are simply impossible to resolve due to the nature of the system. It's not uncommon for a quick bit of editing/lattice modifier/sculpting to accomplish a far faster and easier fix. If all else fails, alpha mask...

Finally, I apologize for the extremely long post. I usually try to break things up into smaller, easier -to-digest chunks but there just wasn't a good place to do that with this installment. I hope you find it helpful in spite of its length.