View Full Version : Rigs and Animation for Games

10 October 2004, 01:05 AM
All the material I can find on animation doesn't seem to distinguish between pre-rendered and real-time animations. I'm wondering if there are things that I need to be looking out for when creating the rig for game models as opposed to rigs for pre-rendered, high rez animations, the same way you have to watch poly counts when doing the modeling.

Since I can't find anything on the subject, I assume there isn't, but I'd like to make sure before I spend a lot of time working on it only to find out I have to start over.

Thanks for any input,


10 October 2004, 02:31 AM
I'm not familiar with this,but I'll state some from my experience.

I think it's really depends on the case and person who setup the model,but it seems Game model character has more simple bone suructure compare to highend model.It simply because low poly character doesn't has enogh mesh to correspond complex bone structure.
And It also depend on that if you use motion capture or not.
I heard that there is kind of format bone struture(or way of naming?) for Motion Builder.
(I haven't used this software but one of my friend who can use MB said that)
This is not compulsory rule but,it is desirable.(I really not sure about this)

I hope this gonna help you some.:)

10 October 2004, 04:58 AM
Realtime/FMV rigs are getting close tho. Most often the case nowadays is: what was used in film has been eventually adopted by realtime. Keeping up on FMV rigging can give you a heads up on what will soon be expected of realtime rigs. Check out these sites, too, when u get a chance.

peace d=^)

10 October 2004, 07:41 AM
Nice links:)

There are many interesting articles and posts.
Thank you.

10 October 2004, 05:47 PM
Nice links:)

There are many interesting articles and posts.
Thank you. No problem!:) In fact, as far as the gaming connection goes, the guy who runs works for a game company. I can't wait to see the next naughtydog game with him involved.

peace d=^)

10 October 2004, 06:21 PM
Excellent stuff..thanks for the info


10 October 2004, 08:59 PM
I only see info on those sites about rigging pre-rendered characters. I must be missing something.

Sure, some things migrate from film to real-time 3d, but as far as I've seen complex rigging isn't one of them. Games that support complex rigging are few and far between, if not non-existent. If you know of any using muscle dynamics or complex dynamic fat jiggle, let me know.

All the game rigging techniques I know of use simple bones in simple hierarchical linkages. Fat jiggle or muscle bulging can be simulated somewhat by adding extra bones in the right places, but the motion for these is created in advance, it's canned motion.

Most games don't support scaling their bones, and usually the root bone is the only one you can create position keyframes for. Rotation keyframes are mostly what you have to work with.

One common limit is 4 bone weights per vertex. This allows the graphics card to tranform the bones, instead of dumping that work on the CPU which generally is slower since the bus bandwidth is really tight.

I wrote up a list of issues awhile back about what _not_ to do in 3ds max when rigging a game character, and how to fix fubared bones. Might help you.,21
(free registration required to see the post)

Even if you're not using 3ds max, in general you need to avoid any kind of scale on your bones, whether uniform or non-uniform or negative (mirrored bones). Game engines tend to puke.

Please correct me if I'm wrong about any of this.

10 October 2004, 09:34 PM
All the game rigging techniques I know of use simple bones in simple hierarchical linkages. Fat jiggle or muscle bulging can be simulated somewhat by adding extra bones in the right places, but the motion for these is created in advance, it's canned motion.
There's tons of ways to "fake" jiggle and secondary actions without it being canned motion. A simple time delay expression applied to the desired joints could do it for you.

Granted I'm a more of a Maya dilettante than anything else, so I don't know how you'd solve this in Max. The point is, if these techniques aren't being advertised as in-use now, I suspsect it is most likely due to NDAs preventing realtime folks from talking about what they're R&Ding.

peace d=^)

10 October 2004, 09:50 PM
Oh yeah, forgot about that. Ragdoll, polytails, capes, and the like. Good point. Also some game rigs use IK, although programmers generally don't tell the artists if they're secretly converting it all to FK. Helps performance, and if the artist generally can't see the difference, then no biggie.

Another point I though of. Each game exporter/engine tends to want the rigs set up a certain way. Unreal is a good example. Kind of old, technology-wise, but many of the issues still apply to current and next-gen engines.

I found it helps to pay attention to the needs of the particular system you're rigging for, otherwise you end up re-doing a bunch. Early and frequent exporting helps when I'm setting up a new game skeleton. The sooner I see it breaking, the less work lost.

10 October 2004, 11:47 PM
Thanks for the other info Eric. Limits on numbers of bones and what can be done with them is what I was originally concerned about. I just wanted to make sure what my limitations would be.

Thanks for all the great info posted here,


10 October 2004, 01:50 PM
You're welcome. I try to share what I know. I also hope people correct me, like spakman did, so I can learn more.

Are you making a rig for a particular game? Or just for your portfolio? If the former, check with your coders to see what their requirements are. If the latter, I think it's to your advantage to show you can rig export-friendly setups as well as higher-end pre-rendered rigs... if you're shooting for an animator or rigger/technical artist position.

As for limit of total # of bones on a single character, we've set a rather arbitrary limit in our exporter of 255 bones per model. Our engine supports much more than that, but our game format needed a limit to keep it from getting unweildy, and we couldn't really foresee artists needing more than 255 bones... it's really kind of crazy if you're going that high, you're likely to see a performance hit on current hardware if you try to transform that many bones at once.

Other game engines have other limits, I think between 16 and 32 bones, but I'd love to hear more info about that. If anyone has info to share about their system, or others they've used, I'd like to hear about it.

10 October 2004, 05:06 PM
Does anyone else find that Character Studio (biped) really just sucks? I mean, after learning on Maya's bones system, things like not being able to look at/adjust the curves in your animation just seems stupid.

So I wonder, do game companies often use Biped to rig characters in max?

I've not had much experience with the bones in max but everything I've heard is negative... although I'm using max 5 and maybe things have changed since then.

Is there anyone out there using CAT (or some other auto-rigging plugin) for game characters? Or is it mostly custom setups?

Another thing I've wondered about is if .bip animations are often reused... are all the skeletons in a game the same setup so that animation assets can be transferred? Is this possible with other kinds of skeletons?

10 October 2004, 06:01 PM
I agree Biped is a mess. It was revolutionary back when it came out, like in '93 or something. No need to setup IK limits, re-scaled animation to fit, the whole footstep solution to skating mocap feet. But it has too many drawbacks now that better systems are available. Even max's default bones are better. TCB controllers are definitely not animator-friendly, the IK is messy and pop-prone, and what's the deal with separate vertical, horizontal, and rotation tracks?

Some developers might still use Biped because their export pipeline was designed around it, or they have an animation library built up (ala UT2003/4). But those things can be adjusted to get them into standard bone rigs. Exporting/importing to/from FBX will easily convert a Bip into bones, for one.

We create rigs here usually with standard Bones, along with IK and various controllers. We do support Biped as well, but mostly for legacy content, or to support 3rd party devs who want to use it, because we create software for developers.

As far as re-use goes, you can re-use bone animation in stock 3ds max, using the Character node, but it's not an optimized workflow, and yes the rig needs to be similar or re-targeting is shoddy. I've heard good things about Messiah and CAT, but have no personal experience with them.

Bones in max got a bad rap in v3, but improved considerably in v4 and beyond, to the point where they're really quite capable.

A couple 3ds max bone rig tools I've come across... (SkeletoMat, towards the bottom) (charRigger)

Whew. I'm really typing too much today. Must be the boring work I'm stuck on this week.

Hmmm, I just stumbled across this on Paul's site, looks like it'll be a good read...
Advanced Game Character Rig and Controls
(Paul, if you're reading this I hope you don't mind the direct links)
Lots more great rigging stuff on his site, well worth a look.

10 October 2004, 08:20 PM
as far as bone limits go, i can say about our engine that we're using 32 or more bones (cannot recall the exact maximum since i'm not an animator). for a normal human character 32 should be enough to give him some good rig. we used to use character studio but its a nightmare for the programmers to get these rigs and animations exported correctly since every single bone in cs has internally his own local rotation and position matrix. as stated above though, normal max bones are okay and work quite good. but from all that i heard from our programmers max is a pure nightmare to write plugins for - at least when you're working in the guts of max. thats why we switched to lightwave recently - fast, stable and a wet dream for our programmers ;)
i can't comment on CAT though...



10 October 2004, 10:16 PM
Oh yeah, forgot about that. Ragdoll, polytails, capes, and the like. Good point. Also some game rigs use IK, although programmers generally don't tell the artists if they're secretly converting it all to FK. Helps performance, and if the artist generally can't see the difference, then no biggie... Heh, I'd once been involved with an In-engine IK system.

There was a point, before the gameplay had changed due to RAM and child friendly ratings issues, that you could kill a bunch of enemies, and step up and over the pile of corpses lying in your path. Depending on where you'd kill them, their collision detection could cause them to pile on top of each other as they bit the dust.

I'd jokingly suggested we use this as a "feature" to gain access to higher, previously unreachable locations. Run around, get the enemies to chase you, wait till they're near the area under your desired destination, and dispatch with them there. Kill enough of them and you'd get a pile of deadmeat high enough to climb up onto to reach said ledge. Playing those early prototypes was pretty hilarious in a gruesome sort of way. In the end, the dead bodies ended up having to fade from the environment to free up processor realestate.

But depending upon the engine don't be surprised if it's Bake, Bake, Bake. For example, one thing I'm not fond of about renderware ( is it's linear f-curve interpolation. While the baking makes up for this, it creates tons of extra data. d=^(

I like that the folks doing Tekken are using endorphin ( Looks like a another good tool to free up the animators' time to concentrate on acting and cool moves instead, of creating multiple, canned "hit" and "death" anims.

peace d=^)

11 November 2004, 06:54 PM
Hi. Just a newbie here, however, this thread is quite interesting to me.

I've also been a little confused about the "rules of rigging" when it comes to game animation.
I recently created my first attempt at a gaming rigg. Details can be found here:

Problem was, when I digested the animation into UnrealEd(My realtime testing engine of choice), I realized I totally screwed myself with certain "issues" in the rigg that I was unaware of.

For example, as was already stated, I keyed "translate" values into joints other than the root. A big no-no. Also, how the heck to do you handle constraints with only a single heiherarchy? If a sword is "skinned" to a wrist joint, and you want it to temporarily leave his hand, you would have to break the single-chain heiherarchy, ya?

Scaling? how do you do it? Like if a persons head needs to "bloat" a little. Is it bone driven, like the famous Cane_toad ( rigg?
Games like Jak and Ratchet and Clank for PS2 use lots of squash and stretch and heads seems to "scale" in a cartoony manner. How do they get away with this?

I also ran into an issue with certain IK. My foot IK setup didn't function properly(foot rolls didn't digest right). Perhaps I should have rigged the foot via classic "reverse foot" driver bones?

Most of the animation was ok, but it was these tiny little things that really prevented me from showcasing the animation in actual "realtime" which is what I was really hoping for :(

So I'm working on modeling my second character, and this time, I want the rigg to really work within a realtime engine. Hopefully, with some trial and error, I can get it to work.
I wanted to exploit UnrealEd's "matinee" feature. A pretty cool way of making your own "realtime" cutscenes. It's fast and doesn't require knowledge of programming.

I'm looking into apps like Motion Builder. Reason being is that is seems like it would be great tool in a "realtime" animation workflow. Because the app essentially creates a "control rigg" around a simple skeleton, so when you export from MB back into Max/Maya all you have is a skinned character and bones/joints. That's it. No weird controller, no Iks, no strange connections between joints and nodes.. and, all of your IK animations are translated into simple FK motions. Would this make for less headaches when digesting animation?

Also there is this issue with dynamic simulations. In my first rigg above, I realized that I couldn't export any dynamics like hair or cloth, so I had to manually keyframe all the joints myself to essentially "fake" the stuff. This added up to many hours of time just to do a simple sword swing. Would it be possible to put dynamics into the joints and then "bake" them into keyframes after the initial motion is done. You can do this in Maya with Bonus Tools 6 or check out CREATURE TOOLS ( Would this export correctly? I'm guessing it would seeing that it'll just translate to simple rotation keys.

Then there's the issue with SDK in maya(Set driven key). Sometimes they exported correctly, sometimes they didn't at all. All of my fingers motions(driven by keyed SDK attributes) did not :(

Anyhow, before I continue to bore everyone, any further light into this topic is much appreciated!

Thanks, all
-pod :)

My current WIP (

11 November 2004, 07:37 PM
I had no idea translate keys didn't work in UnrealEd...I was able to export facial animations with translate keys out of max, and I'd assumed things would be the same when I switched over to Maya. I'll have to test it out.

The Jak/Ratchet is a special case. They intentionally broke the no NU scaling/transformation "rule" and had their engine support it, because it was a cheap way to achieve squash and stretch in realtime, no matter how crude it might seem. I thought it was pretty clever, if only for the fact that its unconventional and it worked.

I ran into a lot of the problems you mentioned in UnrealEd... have you tried checking to see what your skeleton looks like in UnrealEd? Are all the bones oriented properly? I ended up having to rebuild skeletons a few times, because re-orienting joints didn't seem to work all the time. My failsafe method is to build a skeleton, place a locator at every joint pivot, and rebuild the skeleton using a connect the dot method by snapping to the locators using the create joint tool. I've had no problems so far with IK or constraints, although I haven't tried SDK yet. The source of the problem in my experience has ALWAYS been with joint orientations.

As for dynamics, I've found the best way to go about it is to have two identical skeletons: one skinned to the characted, and another to receive the dynamics (doesn't have to be the entire skeleton. A clone of the bone chain driving the hair for example). Then simply constrain the joints on the original skeleton to the dynamics skeleton. I'll try to run a few more experiments for ya, but from the looks of it you much more extensive experience with character setup in Maya.

11 November 2004, 08:05 PM
Thank you, Snowfly! You've already helped me a great deal more than you think! The whole snapping locators to the skeleton, then rebuilding is pure genius! Great idea!

You're approach to the dynamics problem is also quite clever.

Yes, many of the problems were due to joint orientations(the typical mel script for realligning does not always work). You say you were able to export translate keys in Max? hmm. That's interesting. I've always though Max doesn't even let you translate any bone other than the root.

Good looking out so far. Keep em coming. I wish I had my own personal TD ^_^


11 November 2004, 12:30 PM
i did a few tests, well, you can translate keys from maya to just can't scale. i'm finding the golden rule is just to IK everything. and btw, driven keys worked fine. i don't know what could be wrong with your rig..

also, reading back, i was mistaken about cloning need for that, just use proxy geometry and set up a rag doll, then link the IK handles to the proxy objects.

the thing is, animations created using this method are highly impractical since you can't take a snippet of them and tweak in the curve editor. i think you're on to something with that motion builder thing...maybe fbx would work?

all the test anims i did showed up in unrealed. ya think its safe to assume that they'll appear in-game too?

anyway, this is becoming too engine specific...moving on...

11 November 2004, 04:30 PM
hehe, this is becoming a personal study/chat between me and Snowfly. lol That's ok, I don't think anyone else is reading. I kinda dug up this thread from the last page because you were on a topic that no one seems to be researching on the forums.

Thanks a lot for doing the tests. Hmmm, yeah I dunno why the SDK's didn't digest. The thing is, some of them did, so I'm beginning to think that "joint orientation" is the culprit. Proxy objects for the IK seems like a very good idea. Actually, it sounds like a GREAT idea. I would have to re-skin my other character to a new skeleton for it to work or perhaps I can save some time and use Maya 6's "retargeting" feature. Although with some joint orientations out of whack, this might not go so smoothly.

So translates DO work? ok, I'll have to try that myself. If so, then that's great! And it doesn't have to be a translate on the root joint only, ya?

One other weird glitch for me. I have a series of animations which I compiled into "clips" in the trax editor. Once they exist as "clips", the keys are removed from the timeline and sent to the NLA trax editor. Ok, now, I set up a series of motions, by merging, blending, scaling clips until I have a nice one minute animation demo of all my "blended" clip. My problem is, ActorX will not digest the animation unless they exist in the timeline. Why is that? And how would I go about taking a series of blended "clips" and dump them into the timeline as keyticks. Weird, eh? Perhaps a setting I have that's off?

Thanks again Snowfly. Oh, btw, I saw your entry to Demon Princess' model over at Polycount and it was pretty cool.


11 November 2004, 02:29 AM
Yes, someone else is reading this. Hope you don't mind. :)

I'm using 3ds max, so I can't help with any Maya tips. But to move non-root bones you typically have to turn off the Bones property first (Character menu, Bone Tools, uncheck the Bone On [? don't have max running right now] checkbox towards the bottom).

About breaking hierarchies (letting go of the sword example), there was a discussion recently on the GDAlgorithms mailing list about this, and there have been other similar interesting ones within the last year.
I listen in because it's a great chance to hear what some of the top game programmers are up to. Much of it goes over my head, but there are some great tidbits now and then.

the_podman, I guess you spent some time poring over the UDN skeleton docs? Oh well, not much meat there I think unless you're registered.

Scaling bones is generally a no-no, mostly because most games don't support it. But even the ones that do, ala Jak & Daxter (thx Snowfly!), usually require that you only scale the bones that are at the ends of hierarchies. If you scale a bone that has children bones, each of the children have to transform themselves within the new scale inherited from the parent, so you can get some weird problems. Especially if the game supports non-uniform scale (does Jak & Daxter?). I know we do (, but I do need to be careful with it, even though it is a really cool tool to have. For example, if I scale a humerus bone lengthwise, then as the radius/ulna rotates through that weird scale it will skew and stretch oddly.

Here's some info I posted awhile back about setting up bones for games. Mostly 3ds max-centric, but still it might help out.
(heh, someone familiar in there)

11 November 2004, 03:02 AM
Hello, Eric! Thanks for the input. You have given me a plethora of information to study. Thank you very much. A lot of what you stated is very interesting and as I've watched games develop over the years(I was around when Pong came out and still remember playing in on the Odysee when I got that system), especially the 3d scene, I've scene more and more game engines getting away with stuff that was always told you weren't allowed to do. Double-sided polys for example, don't seem to be a problem anymore.

Yes, I've spent many hours over at UDN. It's a ton of info to read and unfortunately for me, it's target audience are people familiar with programming, as it assumes you are familiar with what they are talking about. The last thing I ever programmed was a little game for the Texas Instruments TI-994A, back in the day! and Basic could be learned in like, a month.

Even though I'm primarily an art guy, I'm interested in a lot of the TD work that goes into a rigg, especially for games. Since you don't generally "see" the rigg in the final product, I feel like a TD is akin to an unsung hero.

I've downloaded the demos for the tech that you are developing and am quite impressed with what you've accomplised. I especially like the Snake Monster and Sen Arcade peices.
This type of middleware software(I hope I've classified it correctly) continues to impress me. Just take a look at what the latest PS2 games can do, compared to the games that came out during the system's launch. I'm seeing all kinds of visuals and effects that shouldn't even be possible.

Thanks for clearing up the Jak/Ratchet scale mystery for me, guys. That's always stumped me.


11 November 2004, 03:25 AM
Wow, thanks for the praise. The snake was made by Kuman, the other artist here. You might have seen some of his stuff around CGTalk. But that video is really just scratching the surface, the first step towards the per-pixel blending we'll be showing off soon. I'm really itching to share, it's blowing our socks off here... and we're kind of jaded, being so close to it. Anyhow, blabbing way off-topic, sorry. If you have any questions or just want to chat about it, amble on over to that other thread.

Back to rigging, I'm working on another tutorial video that will show how we set up bones in our system. What's cool is that pretty much anything goes, you can use IK, funky controllers, expressions, whatever, and it exports just fine. Quite the opposite of the other skeletal systms I've seen. Only requirement we have is that you maintain an unbroken forward-branching hierarchy, so the system can recreate the skeleton. Well, you can break the chain if you want, but where you break it that new root won't inherit rotational data from the previous chain. Like if you unlink the hand from the wrist, then when the bicep contracts the wrist will rotate in an arc... but the unlinked hand will follow it by moving in a line instead. Might be what you want, might not. Oh well, I'm hoping the video will make it more clear. Cool stuff.

11 November 2004, 03:48 AM
I agree Biped is a mess. It was revolutionary back when it came out, like in '93 or something.
Have to agree 100% on that! I've only rigged a few models with CS but going from rigging with max's default bones to biped was painful. Seems like you loose more than you gain. I'd prefer to make it from scratch any day!

11 November 2004, 03:57 PM
Back to rigging, I'm working on another tutorial video that will show how we set up bones in our system. What's cool is that pretty much anything goes, you can use IK, funky controllers, expressions, whatever, and it exports just fine..
What about constraints? Object interaction? or to get even more complex, one skeleton "grabbing" another, like someone throwing a body. Just curious as to how the engine will handle these things.
I believe this is still "on topic" since the thread is about rigging for games :)


11 November 2004, 05:26 PM
We don't have the tools yet to show one skeleton grab another and toss it, Judo style. But it's built to allow that kind of thing.

For constraints and interaction, we set that up mostly via scripting, which in our system is called Explanations. You design an explanation for the character that tells it what its abilities are. If you've given it an understanding of physiology, an awareness of an incoming attacker, a sense of self-defense, and an understanding of how to grab and throw, then it will grab and throw the attacker. It will "know" where to grab, and how to shift its "weight" to leverage the other character.

The idea is that the bones of the character and of the attacker will react to the forces applied to them. You control how much the predefined poses control the bones vs. how much physics will control the bones (keyframing vs. ragdoll, as one possible example).

In other systems typically this kind of Judo-style interaction is all pre-canned. The user tells the character to "throw," then the character and the attacker are realigned to match each other's keyframed positions, then they each do their throw/be thrown animation, then control is returned to the user.

There was also some discussion not long ago on GDAlgorithms about how best to mix between physics-simulated bones and keyframed bones. Do a search for "How to sync fighter-style character movement with animation?" Also they talked about cloth/capes... look for "Procedural Cape Animation" too.

CGTalk Moderation
01 January 2006, 05:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.