Archive for June, 2008

Everything you need to know about Normal Mapping

Eric Chadwick has been working very hard on the Polycount Wiki, and has just released a massive amount of information about Normal Mapping that pretty much covers all the tech you need to know.

Maxscript wiring function for roll/twist bones

When working with lots of rigs you want to automate as much as possible, especially as they become more complex. I’m working with Character Studio Biped as a base, and then adding custom roll/twist bones on top of this, so it made sense to take the time out to develop a script that could connect up several rollbones in a rig so that I’d get the same results every time. The first and most obvious thing to do was to create these extra bones using script, so I wrote a function called BuildNewBone that builds a new bone between two points and links it to a parent.

The next step was to connect these new bones to the Biped system so that they would behave in the way I wanted, rotating based on the underlying rig. Biped is a relativley closed system, so to query the rotation of Biped bones you need to expose the internal values using expose transform helpers. I set these up via script, so that as well as always having the same name I can position them on screen and even set their colour for easy identification.

Wiring rollbones in max uses the paramwire.connect command, and this takes three variables: the driving or controller bone (in the case of Biped I use the aforementioned Expose Transform Helper as the driver), the bone you want to affect, and a control expression which controls the amount of twisting.

With twist bones like the forearm twist you will most likely want to affect them on the X axis only so that as the hand rotates the rollbone will twist around the forearm bone. Bones like a neck roll however will roll in all three axis. Also in the case of the twist bones like the upper arm twist bone which is parented to the clavicle then you require it to follow the driver bone (in this case the upper arm) 100% in the Y and Z axis.

What I was finding was that I was calling the paramwire command several dozen times to link up an entire skeleton, sometimes calling it 3 times in a row with the same rollbones just to specify a different axis each time.

To makes thing easier for myself, I ended up writing a function to wire rollbones where I could simplify this to a single call:

-- Wire up a Local rotation rollbone given a bone to roll, a controller object and a roll amount per axis.
-- If any of x, y or z are 0, skip the wiring for that axis (inherits parent rotation)
fn wireRoll theRollbone theDriver xr yr zr = (
if xr != 0 then
(
controlExp = "Local_Euler_X*" + (xr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_X] theRollBone.rotation.controller[#X_Rotation] controlexp
)
if yr != 0 then
(
controlExp = “Local_Euler_Y*” + (yr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_Y] theRollBone.rotation.controller[#Y_Rotation] controlexp
)
if zr != 0 then
(
controlExp = “Local_Euler_Z*” + (zr as string)
paramWire.connect theDriver.baseObject[#Local_Euler_Z] theRollBone.rotation.controller[#Z_Rotation] controlexp
)
)

So with a calf roll that is parented to the calf bone, I want it to make it rotate 50% in the X axis as the foot rotates in the X axis:

wireRoll $'L Calf Roll' $eTM_LFoot 0.5 0 0

Uncanny Valley

Uncanny Valley Youtube Link

The phenomenon can be explained by the notion that, if an entity is sufficiently non-humanlike, then the humanlike characteristics will tend to stand out and be noticed easily, generating empathy. On the other hand, if the entity is “almost human”, then the non-human characteristics will be the ones that stand out, leading to a feeling of “strangeness” in the human viewer.

From: http://en.wikipedia.org/wiki/Uncanny_Valley