Joint Skeleton-mover Script

You can temporarily download it here until I get it on Creative Crash.
Or click Read More to show the full script at the bottom of the post.

This is a script I started late last year, and I've recently come back and cleaned it up.  It allows you to grab the root joint of a joint chain to rotate and move it relative to the origin.  It creates a locator on your joint, bakes the animation onto that, and then allows you to interact with a shape on the origin to play with your joint chain.  After deleting, it bakes it all back onto the root joint.  Though it's fairly simple, and not entirely original, it has been one of my most-used scripts for exported joint chains (and also mocap cleanup).

It's pretty straightforward; you run the JHH_skeletonMover script to create or delete the skeleton mover.  It will intelligently put it on the object selected, then delete it off when you're done.  There's also a JHH_skeletonMover_originOffset procedure which will center the joint onto the origin; good for zeroing out your animation.  I'll be making a video pretty soon, but feel free to ask if you have questions.

I'll probably rewrite this in Python at some point, just to get some practice in.

Grapple - Heavy Mocap Cleanup - run cycle and Amina actions

One nice thing about motion capture is how fast you can turn around animations, or you'd think.  The idea is that you start your animation past the blocking stage; mocap sort of gives that to you.  There is a lot of work involved in making it loop properly, but the cleanup stage feels an awful like blocking, just with a whole lot of keys.  But occasionally you'll come across an animation that needs heavier keying.  This is an example where mocap didn't give me what I wanted.



To start off, I was never really happy with the original data we recorded.  The actor didn't quite embody the character I was going for, and I didn't actively realize it until late in the process.  We eventually re-recorded the data, this time with myself as the actor, and got a better performance for the character, which helped.  But then there was the problem with movement speed.  We chose to use root motion on the project, instead of having motion controlled programatically.  This means the way the character feels is controlled by the animators, not the designers; that means animation cycles are spent exporting over and over for the design team.  Mistake number two.

I ended up spending a week tweaking all of the 4 run cycles (each direction) to increase the speed as much as possible without breaking the rig.  And in-between all of that, I was constantly checking it in UDK to see how it worked out.  By the end of it, I essentially doubled the move-speed in each direction by dropping the character's hips and increasing stride length across the board.

After all of that, I can't tell what would have taken longer, motion capture or keyframe animation.  I'd like to think that mocap was still a bit quicker, because we may have run into the same problems with in-game speed; though it would have been really easy to check early on with keyframe animation.

For good measure, here are a few more mixed animations.  The first video is completely keyed, except for the idle.  The second video uses mocap data at the beginning and end.

Nassa the Gnome Animation and Mocap

We had an assignment to take some mocap data, and make 5 animations from it.  I decided to make it into a personal project, by running and directing my own mocap shoot to get exactly the shots I wanted.  And then, I proceeded to make thirty-some animations from that.  I modeled and rigged the character myself, and designed her to be in the style of a low-poly mobile game or a third person action game.

The attacks and attitude were based off of my DnD character (a naive dagger-wielding sorceress.)

I recently rendered them out, and I've included some of my favorites from that collection in the video below.  They are a mix of mocap cleanup and liberal keyframing.