Tagged with " homepost"

Adding mirror functionality to a custom rig

Jan 18, 2011 by     No Comments    Posted under: 3dsMax, Characters, DotNet, Maxscript, Rigging, User Controls

On our last production, I had to find a quick way of implementing a system that would allow me to set up basic mirror functions on any custom rig. Specifically, I needed a toolset that would standardise the main functions of the rig like selection tools for the current side of the body, mirror select, copy, paste and IK/FK switching.

I accomplished this with a simple custom attribute that allowed me to store the nodes of each half of the body as weak references. If you don’t already know, weak references are the golden goose of character rigging. They allow you to store arbitrary nodes within the character so that you can retrieve them at any stage without having to select the node itself.


In the video below, you can see how I set up a full mirror/rig selection system on a puppetshop rig. Puppetshop is great because it already has a load of good stuff already built in, so the GUI I add in the video (which is a custom dotnet interface) can simply expose functions from the puppetshop API.

The selector always knows what the opposite side of the rig is because you store each node’s opposite in the parameter block of the attribute.

So what it does is allows me to set up this feature on any rig within a minute or so. Because you can store the node assignments to XML, it is easy to mirror the nodes onto the other side of the rig for even faster setup.

I hope this video gives some insight into how automated setups can save a wealth of time in production.

If you want to try a max script that uses weak references on a rig, please read my previous post –


I talk about them in a bit more detail and show you how you can control rig visibility using them.

Using HitchHiker – Building a Matte/Shadow material utility

Dec 21, 2010 by     2 Comments    Posted under: 3dsMax, DotNet, Imaging, Maxscript

This post is to show how you can use Hitchhiker to develop maxscript tools in super quick time. Any auto thumbnailer is going to have about a million uses in production in my humble opinion, as most of the development time on a utility is spend building the UI functionality. Whilst on the subject of dotnet controls, I would like to draw attention to another dotnet thumbnail control out there, written by TD Jason Labbe. It’s got a few things that Hitchhiker doesn’t have like multi select, so might be useful if Hitchhiker hasn’t quite got the functionality you need. Nice job Jason! You can read about it here

The Problem

On our last production, we had to consolidate a lot of complex sets into background renders as we were on tight deadlines. Often, the shot would need some form of contact shadow as well as masking so the obvious choice was to use the mental ray matte material. Depending on the type of shot, HD render times could be cut from 10 minutes per frame to around 45 seconds, with no perceptible loss of detail or quality.

The Solution

I wrote a utility that allowed the user to browse for the rendered backgrounds and quickly set the material up as a matte material, ready to be assigned to the background objects and rendered.


This utility is a good example of what you can use HitchHiker for. The browsing window allows you to pick the map that you want, and with the new cache mode property on the latest hitchhiker, is very fast. The greatest thing was that I wrote this entire script on my train ride home one day. This was exactly why I wrote HitchHiker, a plug and play solution to speed up my deployment of production scripts.

The material setup is simple,  matte/shadow.reflection (mi) shader is made with an Environment/Background Map (mi) shader. The texturemap is then set to screen and the blur taken down. You have to option to include the alpha so that you can use the render for composition. While the script itself is simple, it’s an example of how you can speed up a common bottleneck with very small programming outlay. Suffice to say, it checks that Mental Ray is the production renderer, as the materials are only compatible with that, but if you wanted to adjust it for use with an alternative material setup, it would be very easy. There is a method called :

CreateMatteShader <texmap> <slotnumber>

This could be changed to whatever you liked.

There is another assembly that is included with this script too, called ImageBot. It is an extended picturebox that allows you to zoom in on an area by dragging a marquee with the the right mouse button. This could also be used in other scripts, for example a rendered frame buffer.

How to use the script

Make a copy of your scene and render all static elements and save the rendered background file. Start MonsterMatte and use HitchHiker to navigate to the rendered file and select it. Press ‘Create Shader’. The matte material will be created and added to the designated material slot.

Apply the material to anything in the scene that isn’t animated and render – watch how fast it goes!


To install, just download the script below and copy the folders to the root of your max installation. You’ll see the macroscript listed under the ‘LoneRobot’ category and is called MonsterMatte. It’s not really a monster tool, but unfortunately when I was writing this article that monster mash song kept going round my head, damn pesky irritating brain.

Merry Xmas!


You can tell by the way I walk I’m a woman’s man

Nov 2, 2010 by     1 Comment     Posted under: 3dsMax, Maxscript, Rigging, Technical Research

zfOn the last few projects I have used a system that I developed as part of Lonerobot R&D. It’s a walk system called Zimmerframe that is targeted at optimising animation production. The reason I decided to develop something like this was simple – when working as an animator on production, there were many times, especially when I was up against the clock on my weekly allocation that I wanted to eliminate the time it took setting up characters into position in a shot. This was so I could get on with actually animating the performance!

My logic was that there are a multitude of what I call ‘bread-and-butter’ entry and exit shots where characters need to walk in or out at the start and end of shot. On a production, you want to have the walk standardized as much as possible so it struck me that if you stored the distance information of a walk cycle to XML, you could automate the translation part of the animation depending on how many steps you are taking. On a walk it’s pretty much set in stone if you want to avoid foot slip and I also wanted a more precise way of calculating these walk around curved motion paths too.

This was certainly not designed to remove any of the inherent character from the walk cycle – These can be animated however the animator originally wished, except that the actual cycle must be on linear keys to provide a constant speed to the step cycle.

My solution involved adding a helper object – the zimmerframe dummy which stored the XML preset walk data in a parameter block.

Zimmerframe has a small collection of extras to augment it’s operation on this production – A walk cycle maker, A walk browser featuring a custom XML dotnet interface, and footlocker, a simple but useful way of fixing any foot slip around tight corners.

The key to this system is it’s simplicity. However, by combining different walk and run cycles you can build a complex movement animation in a very short amount of time – leaving you to spend the time making the acting good!

Featured here are some screen grabs I made to help the animators on our last production use the system. They are in quicktime mp4 format. I hope it goes some way to explaining how the system works and the ease by which it fits into the max UI and program flow.

1 – Setting up Macros

2 – Setting up a linear run

3 – Removing the helper

4 – Setting up a curved walk

5 – Creating a new walk cycle

6 – Correcting foot slip around corners

HitchHiker Update v4.4

Oct 9, 2010 by     29 Comments    Posted under: 3dsMax, DotNet, User Controls


I’ve been so swamped with work this last year, my planned update to Hitchhiker had to be stalled. It’s a shame really, as I have had a working version of the updated assembly for a while but no time to update the help files to show how to use it. However I’ve been pleased with the progress made in it’s place – I’ve been able to write RigStudio, Digit and Character Silo which I’m really proud of. Hopefully I will get a bit of breathing space to allow me to concentrate on next generation 3dsMax UI stuff, namely learning WPF.

There are a few updates – mainly from great feedback I’ve had from the community. I am glad people are using HitchHiker in any way to augment their Asset Browsing scripts. With the new additions that I’ve made, I am hoping this will be even better.

Please let me know if you like Hitchhiker and use it for anything useful. You feedback is critical as my time tends to be limited. So if i feel people are using the control I can spend my time improving it. I’d love to spend all my time refining this control but there are so many other project that I have to work on! But feedback on any level will always motivate me to fix and improve!

Recent Updates/Fixes –

v4.4 – 19th January 2011

Added the .buttonborder <boolean> property. If you set this to false, Hitchhiker will not render the black border around each control. If used with the .gap <integer> property set to 0, Hitchhiker will render like a seamless section of tiles.


Instantiating HitchHiker

I had to have a re-organisation of my namespaces as they were getting confusing. Since HitchHiker isn’t really anything to do with characters, i decided to change the default namespace to lonerobot.ui.controls. If you have any scripts that were written with the previous release of this assembly, you can just do a search and replace of ‘character’ for ‘controls’

make sure that you call dotnet.loadassembly <hitchhiker dll location> in your script before using.

if using on a dotnetform or maxform – dotNetobject “lonerobot.ui.controls.hitchhiker”

if using on a maxrollout – dotNetcontrol “lonerobot.ui.controls.hitchhiker” width:<int> height:<int>

please refer to the hitchhiker tab at the top of this site for more detailed help, all these are still valid

Additions to Version 4.4 of HitchHiker

Max file support –

Hitchiker will now support the searching of the Maxfile type. Not only this, you can render an associated thumbnail directly from the assembly to be displayed with the file when previewing it in HitchHiker.

Additional populate methods –

Hitchhiker was always designed to operate on a folder level, whatever was inside with the designated filetype was displayed. Now you have two options.

populate (by directory string)

populate (by file array)

This means you can now pass an array of filepath strings to be displayed in the hitchhiker window.

This can also be utilised with the enhanced search parameters –  PopulateFilterSearch

Hitchhiker will now allow you to display files that start with, end with or contain certain characters. So if you are doing a recursive search population of many folders, you can tell it to only display those with a particular character’s name for example.

Other options is that you could prefix or suffix a filename “Approved” or “Unapproved” and allow the showing of approved files only.

Fast Cache Display Mode

Hitchhiker is reasonably fast in realtime mode, but (like most asset browsers) can slow down when loading multiple hi-resolution images inside folders. Hitchhiker has a display state that  can be set to cache – meaning the thumbnails are stored locally on the user’s machine, meaning that the slowdown only exists the first time the populate method is called. Subsequent calls result in the control being populated very fast!

hh.cache =  (dotnetclass “lonerobot.ui.controls.hitchhiker+cachestate”).cache

Store Favourites of your commonly used directories

Hitchhiker can now add locations that you use to populate from to save specifying the folder each time

Fully integrated toolbar

Hitchhiker can be run without the toolbar and it’s behaviour controlled entirely by script, but setting the toolbar to true allows you to do everything from the menu system, set thumbnail sizes, search parameters etc, meaning it really is a pretty comprehensive asset browser straight out of the box.

A few caveats I have noticed about this release –

Occasionally the keyboard focus can be stolen by HitchHiker if you close the dialog. Make sure you call the housekeeping function in your close handler, as this will make sure max gets it’s shortcuts back.

Feel free to download at the link below. If you find any issues with using this version of Hitchhiker, please let me know and I’ll do my best to fix it. I would ordinarily like to test a release more than this one has been – But didn’t want to delay the release this to the community any longer. I hope it helps you make great utilities with minimum effort.


Flexible Animation System for Fingers and Hands

Oct 8, 2010 by     No Comments    Posted under: 3dsMax, Characters, DotNet, User Controls


For many years as a character animator I have wanted a system to aid with the animation of fingers. It’s one of the things that tend to be done as an afterthought when pushed for time on a production, but there is no doubting that some of the nicest animation will always have really great hand gestures. The balance is trying to find the balance between time and ease of animation. If you are really pushed for time, it would be far better that you could store hand poses that you use most of the time, with a view to having a robust toolset to allow you to refine them afterwards.

I recently wrote a system called Digit that goes some way towards addressing this issue in production. The key to this system working well was to provide a UI that was intuitive to the way people currently work in max, and making it minimal and simple enough that it didn’t need too much understanding. This article will hopefully explain the process that I undertook in planning and executing this system.

Planning the control layout


I usually start with some sketches – i have a technical journal that I write ideas and loops into. This over the years (and much to my chagrin) has replaced my sketchbook but it does give me a kind of technical reference for everything. I will scribble UI ideas down before I code anything, as it helps me to plan in advance potential layout conflicts. It is by no means final but it gets me thinking about how everything is going to interact. The thing to remember is that it’s not something you’ll proudly display, but it helps to organise your mind and avoid any UI layout problems along the line. UI design is a hard thing to do, generally people will tell you when it is wrong in a heartbeat and not even notice if it is right. It’s one of those thankless tasks that only you can appreciate.

With Digit I felt I could deviate from the look of the max UI – firstly, square controls were simply not going to cut it, and I wanted to allow control to adjust the layout when running in either a portrait or landscape mode.  The FlowLayoutPanel is built for this task and I’ve used it extensively for my controls up to now. The layout logic was pretty simple, I didn’t want to separate the controls too much, what it gave me was two main panels – the selection interface, and the slider controls.

The critical thing for me in terms of the functionality of the system was that it was as intuitive as possible, and mimicked a lot of the same methods as the native max UI. This was mainly the use of CTRL and ALT to add and remove from selection, and the double-click hierarchy selection. My other consideration was to try to keep the dialog as minimal as possible. I had setup finger controls in the past and found, due to the nature of wanting them to be able to control individual fingers, that they can become large slider interfaces. I thought that this time i would be able to use less and still have the same level of control. Here is what I came up with in the end, they are the same UserControl, they have a hand property, Left and Right which decides what UI colour they get.

Colour profiles

Selection based curl slider

I did this by having a two stage approach, working on a specific selection or on the entire hand. If no finger element was selected, the curl slider affected the entire hand. If a particular finger had been selected, then the curl would only operate on that finger. The same went for resetting the finger position. This worked well, you could quickly set up different poses based on others.

Splay and Thumb position and rotation were different. You don’t want to splay individual fingers, it looks odd so this acts on the entire finger rig. And individual thumb position and rotation are also necessary. However the thumb curl operates on the global curl slider.

The +Thumb button was something that came from the evolution of the control and testing it on some real characters. Sometimes, you didn’t want to move the thumb but still move the fingers. This checkbutton allows you to affect the thumb curl and splay with the other fingers – as before, it is based on the selection, so you have to have no part selected for this to work.


Its all put in place with a bit of simple matrix rotation. You can prerotate a matrix according to an angle, so each time the slider moves, it is calling a function that supplies the current transform and returns a new transform matrix that is prerotated by the angle from the slider.

Medial,Distal and Proximal Selectors

The three selectors to the left of the fingers are to select across the first, second and third bones. I thought this gives an extra control if the automatic blended rotation of the fingers isn’t quite enough to get the hand pose you are after.

Pose Storage and Mirroring Transforms

I have been using XML for a while now to store any sort of pose when I use a reference transform monitor to store a node. Most of my facial animation systems and rig setups use these. Once the directory is specified, you can store the local transform of each node and that’s all you need. I use an XMLLayoutPanel to handle the files. Its a dotnet user control I released a while ago that handles all the layout and even lets you specify a custom thumbnail. Check my previous blog post if you want to have a go at using it.

When you apply it back on the hand later, you multiply the current finger’s parent transform with the XML preset’s local transform and you have applied your stored preset. Because you extract the local transform, the pose is the same, even when applied to a different hand position as you are making a new transform matrix from the current parent’s position. When you want to mirror the transform to the other hand, that is a little more involved.

You start by reading the local transform of the finger nodes. Then, you Mirror the transform matrices of all bones, by creating a mirrored transform around a common parent (like the character’s root). However the other arm is not necessarily in the same position. So, you need to create a mirrored transform of the hand too. Once you have this, you can get the mirrored bones local transform matrix. This becomes the one you use, as you can then multiply this mirrored local transform onto the current location of the parent (i.e. the opposite hand) With this you can paste a hand pose from one arm to the other, regardless of the arm position. I was grateful for all of the brilliant examples on the CGTalk board to help with this, specifically from Paul Neale.


It is possible to set up a character with this complete hand animation system without any Maxscript. This works on Bipeds, CATrigs, Puppetshop rigs and custom bone rigs, so hopefully it will be useful for many projects to come.