Automatic hair/fur plane skin weighting

So, been a bit busy of late with work, projects (I'm building a custom e-bike with various bits ordered from China) and also a community farm project that takes up my time. A post on here is way, way overdue... I don't know where the time has gone.

The tool I'm going to cover here automatically skins hair planes based on an underling mesh, and ensures that each vertex in a single hair segment has unified skin weight values to preserve (as much as possible) the shape and volume of each piece as it deforms.
This is definitely aimed more at the games developers that don't have the luxury of using the various hair/fur shaders, but it should be of general interest for anyone looking to write skinCluster related scripts.

Copying skin weight values between vertices

I was writing a new post on an automatic hair plane skinning tool and realised it had a dependency in the form of another tool I use all the time so thought I'd better quickly post up about this one first.

So, this is a procedure that copies skin weight values from one source vertex to one or more targets and it's something I use a huge amount when skinning characters. It will work if the vert selection is across multiple meshes (though they do need to have the same influences so it can assign weight values to them) so it's useful for things like unifying weight values on seams between meshes or, for example, weighting a button mesh so it follows the nearest weighted vertex on a coat.

I know anyone with Maya 2011 will be saying about now "but isn't this kind of unnecessary with the new skinning tools?" and it kind of is is... if you're running 2011 (I think they finally included this in the tool set). Unfortunately, being part of a wider studio I don't get the final say on what version we upgrade to.... so I'm on 2010. Yeah, I'm kind of gutted...

That said, I wrote this script a while back and over time it's become an integral part of my tool set so even if I was on 2011 it would still be a useful.

Anyway, I'm not going to spend a load of time with this as really I'm only posting it up as a precursor to a new post I've mostly written already. Also I've commented the script itself pretty exhaustively and I'll only end up repeating myself.

Setting up a forearm roll joint - method 2

Here is a second method for setting up forearm roll joints. It's a follow on from this post which covered how to set it up using the rotateY attribute of the wrist joint. This second method is the way I implement a forearm roll system, but I wanted to post the other version simply because it's a great way of looking at how different rotation orders can have implications for your overall rig set up, stability and usability.

So, to set up the forearm roll:

The basis for this is a single aim constraint, and is pretty quick to implement.

Setting up a forearm roll joint - method 1 of 2

The problem with roll joints is always one of driving them, and that comes down to being able to separate out the twist rotation from the source joint (upper arm/wrist etc. etc.).
The upper arm is pretty tricky in this respect due to the large range of movement and so requires a more complex set up. The forearm, however, is quite a lot easier because the rotation range of the wrist joint within its local coordinate system (of the elbow) is reasonably small.

There are two ways you could set up the twist system. The first is super-quick and 99% stable (but is completely dependent on your wrist joint rotation order for it to work), the second is just as quick but completely stable and doesn't rely on you having optimal wrist rotation orders set.

Actually, if you want to set up a forearm roll joint system I'd definitely do it this way.
The main aim for this post is that it serves as a really great way of exploring rotation orders and the implications they have for your rig. It's quick-to-make practical example of how different orders can affect stability and useablility of the rig and also your own sanity when building more complex systems.

Adding squash & stretch to the spine control rig

So, to add squash & stretch to the spine rig.

The number of spine joints in this example is pretty low purely to reduce the amount of connection explanations I have to type. It should be fairly easy to take this and construct the it over more joints. Normally I'd be working with at least one extra joint, sometimes more, and this really improves the deformation quality in non-stretchy mode but particularly when it is stretching. There are also some real limitations to how far you can go with squash & stretch setups for a game engine which I'll get to later...

Hey,

I thought I'd do a quick post just to say feel free to get in contact with me if you have questions, if I've not properly explained something or just plain missed something important.

I've made a point of not covering really basic stuff because it's already been done to death and I wanted to cover stuff that's (a) not necessarily out there and (b) a bit more interesting that "here are some utility nodes, this is an ikHandle" etc. etc. The flip side to all this is that I might have skipped over some things in my explanations... in which case give me a shout.

Also, I've got a fairly lengthy list of posts that should keep me busy for some time but if anyone has particular areas of rig set up that they would like me to cover then drop me a line and I'll do my best to put a post together.

Cheers,
Matt.

Spine control rig

Happy New Year! Sorry it's taken a while to get the first post of 2011 out of the door. I started writing this ages ago but work, family and post holiday blues have conspired against me. Anyway...

In this post I'm going to cover how to set up a spine control system. This does include squash & stretch functionality, but in the interests of getting this out I'm going to cover how to add this to it in the next post.


(Update) You can find this here

The core of it consists of a NURBS surface with ik joints controlled via groups attached to the surface using pointOnSurfaceInfo nodes. The surface is deformed by clusters which in turn are driven by controllers. If you're not familiar with uv (texture) coordinates it's worth reading up on this first, I'm not going to go into it here as there is plenty of information kicking around on the subject.