Bone names and limits

General discussion about JPatch

Bone names and limits

Postby sascha » Fri Oct 28, 2005 4:17 pm

I've got a question to everybody who's got experience with other animation tools:

For a simple human skeleton (i.e. without individual fingers and toes), what are the "default" bones, their names and their limits?

E.g, how many bones are used for the spine and how are they named? What's the limit e.g. for the elbow-bend (in degrees) and all other joints?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Fri Oct 28, 2005 7:37 pm

I don't know that there's a standard naming convention. You can either use the (correct) technical name, but more typically people use terms like "left upper arm" and "right lower leg".

The Animation:Master Handbook suggests:
  • Head
  • Neck
  • BicepR
  • ForearmR
  • HandR
  • Torso
  • Pelvis
  • ThighR
  • CalfR
  • FootR
along with left hand versions. The hand bones are:
  • HandR
  • HBaseR1 (lower thumb)
  • HTipR1 (upper thumb, only two bones)
  • HBaseR2 (first finger, base)
  • HMidR2 (first finger, middle)
  • HTipR2 (first finger, tip)
along with the other fingers (and hand).

I think 3 bones is the minimum for the backbone; it depends on the needs of the character. More is generally better, but you want to maintain control of the character as they bend and twist. Many rigs will have lots of bones, but the actual bones will be hidden, and manipulated via a smaller number of bones the back is constrained to. The backbone is also a prime target for a "spline" bone.

Here's a link to the A:M "standard" 2001 rig. It's apparently going to be replaced by a Squetch (squash and stretch) rig - no links to the new rig, sorry. But it's probably not especially helpful, since it uses lots of constraints you don't have yet.

Speaking of constraints, Here is an interesting article. I've always had mixed feeling about setting up a complex rig - it's nice that it does stuff for you, but then you reach the limits of the rig and have to turn it off. Or worse, you have to set up multiple rigs for a single character. I was reading yesterday about someone who set up a shot with leaves drifting around. He initially tried it out using the builtin physics system, but ultimately fell back to hand-animating all the leaves. There's a lesson there somewhere. ;)

You can find a good listing of range of motions here.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Oct 28, 2005 8:10 pm

Thanks David (I knew I could count on you :wink: )!

The table with limits and types of joints is extremely helpful!
As far as the backbone is concerned, I think I can make it with fewer segments, as JPatch will be able to "non-ridgidly" attach points to bones - I'll give it a try with just two segments.

The bone and degrees-of-freedom system is almost ready - I'm currently building a simple humanoid skeleton to test it. Next is auto-assigning controlpoints to the skeleton (should be quite easy).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Fri Oct 28, 2005 10:52 pm

You're welcome. :)

One thing that should probably be mentioned is the feet. In order to animate a walk, you're probably going to need to set up the feet so that the bend at the toes. Here's a link to an IK rig in Blender that explains some of the issues.

I've been looking at Spline bones, and I'm wondering how difficult they would be to implement in JPatch. Since by now you've got a lot of experience with splines in general, so it should be a cinch. ;)

Here's my take on it: You set up bones as normal, but then assign them as "bendy" bones. Each of these bones is broken up into n smaller bones (a user assigned value). A spline is run through the pivot points of the original bones, and the "bendy" bones are guided by the spline. The bendy bones adopt the same orientation as their parent bones.

Image

I don't know that the users would even need to see the "bendy" bones or spline at all - they could see the result when they moved the mesh. One nice option would be to have a "strength" of the bones, so you could control how much curve the bones would have. A value of zero would mean there would be no curve, and it would act like a normal "straight" bone. A value of one would be a "normal" spline, and higher values would be fairly wacky, like the "rubber hose" animation of the early '20s - especially if you stretched out the parent bones. :D

By the way, I reinstalled Java on my work machine the other day (it was having trouble running NetBeans), and I just launched JPatch. I got the warning that the OpenGL drivers weren't installed on my machine. That explains why "Install OpenGL Drivers" is in the menu. :cool:

My only suggestion here: at the point where it reports OpenGL not being installed, it should give the option to install the drivers, so you don't have to search for it in the menu, and don't have to reinstall. (It should still stay in the menu, though).
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Oct 29, 2005 8:34 am

"Spline bones":
I think that JPatch will be able to accomplish the same result without the "spline bones": How much a controlpoint is affected by a bone can be dependend of the position (wheter it is close to the start or close to the end of the bone it is assigned to). This behavior can be enabled/disabled per degree-of-freedom (see the example I wrote earlier with the lower arm - there's a difference between bending and twisting it). Normally this would be used for all DOFs that allow a "twist" (arms, legs, backbone, neck,...). But if you'd turn it on for all DOFs of a particular bone, you'll get an effect that's quite similar to the image you've attached. This would make sense e.g. for snakes, tentacles, etc.

The DOF system is almost ready (you can check out the latest "HEAD" from CVS), just give me a few days to implement the controlpoint-to-bone assignment - it will be easier to discuss the pros and cons of my approach once we can play with it :wink:

Btw, controlling forward kinematics with sliders is quite annoying. IK will help a lot, but, from what I've read, many animators prefere FK to fine-tune the poses. I think I'll add a new FK tool: it will display one handle per DOF if a bone is selected, and the handles can be used to rotate the bone around the DOFs axis. This way you could keep the mouse-pointer close to the models (select a bone, drag its FK handles, select the next bone, etc.) Right now you'd have to select a bone, open its DOFs in the tree, select a DOF, move its slider, select the next DOF, move its slider, select another bone, etc...
TheFK tool should make live easier, at least until IK is implemented.


I have to admit that I have not yet looked at AOI's IK system, but considering that it might be the most efficient way to animate if IK and FK can be used in parallel, I had the following idea:

For simple systems (e.g. the elbow and shoulder joints) IK is simple as well: There's always exactly one analytical solution if you let the user manually control the remaining DOFs: E.g. You select the position of the hand and the IK system will compute the angle of the elbow bend. There are two remaining DOFs left: The position of the elbow and the twist of the forearm - if there are two FK handles for those DOFs, exactly positioning the hand would be a matter of three mouse-clicks.

Now, many tools offer a much more sophisticated IK systems: You can literally take you characters hand - first it's elbow and shoulder joints will follow, then it will bend the torso, and maybe even start walking to follow its hand. These things certainly look cool, but are they really necessary for animation? Wouldn't it be sufficient to have a set of independend and simple IK systems? Here's an example:

You what that the character holds a hande: First, position it that the hand is on the handle and lock the hand (IK). Next, position the shoulder (the elbow joint will be controlled by the IK system). Then lock the shoulder and position the body (the spine is now controlled by IK), then lock it. Last, position the feet (with the knee joints controlled by IK). Since the IK solver would work in both directions, you could also do it the other way round.

Those simple IK systems could not only be used to pose the character in key-frames, the IK locks could remain active during the animation. That means that some DOFs would be controlled by motion-curves, while others would be controlled by the IK solvers during the animation. This would be an elegant solution for the feet slip and similar problems (without the need to key-frame every single frame). If the character should hold a handle between two keyframes, the IK system would ensure that the hand does not move in the in-between frames.

Just some ideas. Well, I'll install the latest AOI version and have a look at their workflow.

OpenGL: It currently only reports the JOGL drivers as missing if you've selected OpenGL as the display "driver". But you're right, I'll add a "install JOGL..." button to that warning dialog.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Oct 29, 2005 7:53 pm

sascha wrote:I think that JPatch will be able to accomplish the same result without the "spline bones"
It looks like the effect I was after, all right. :)

Btw, controlling forward kinematics with sliders is quite annoying ... Right now you'd have to select a bone, open its DOFs in the tree, select a DOF, move its slider, select the next DOF, move its slider, select another bone, etc...
A lot of systems I've been looking at have methods of structuring sliders so they're easier to access. For example, you can arrange facial morphs to appear next to the head when the head is selected. I've got some older screenshots of Pixar's Marionette system that I'm puzzling through right now.

I have to admit that I have not yet looked at AOI's IK system ... Well, I'll install the latest AOI version and have a look at their workflow.
Did I mention that AoI supports IK and FK?

I always want to use FK in the same way that you use IK - grabbing the end instead of the joint. I don't know that it's a good idea, though.

For simple systems (e.g. the elbow and shoulder joints) IK is simple as well: There's always exactly one analytical solution if you let the user manually control the remaining DOFs ... Wouldn't it be sufficient to have a set of independend and simple IK systems?
This sounds exactly like the "limited" IK system that I was proposing a while back.

I'm interested in what you think of the AoI bones system. I'm not really a big fan of the workflow, because everything is done by popping up another modal dialog of some sort. At some point, I know they're planning on moving to a more integrated system, but popular vote moved the UI restructuring until after some more important features were added.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Oct 29, 2005 8:11 pm

I've got some older screenshots of Pixar's Marionette system that I'm puzzling through right now.

Wow - I thought that they keep the details about their Marionette system a secret. Now I'm curious...

PS: I've found and fixed a lot of bugs in JPatch 0.5.1. I wouldn't use 0.5.1 anymore - I'll upload 0.5.2 as soon as the controlpoint -> bone assignment works.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Oct 29, 2005 11:38 pm

I picked up a book on the making of Toy Story, so the images are rather dated. If I looked through The Incredibles videos, I could probably find something much more current.

I had grabbed these off the net a couple years back after spending hours Googling for anything related to Marionette. They aren't as nice as the ones in my book, but they're the only ones I have electronic copies of:

Image
Image
Image

There's nothing especially "magical" about the user interface.

For rigging, Pixar uses/used avars, which stands for articulation variables. They're not unlike morphs or actions. Rigging isn't actually done by the animators, it's by a seperate team. This helps keep the character's acting consistant from animator to animator. Here's a description I grabbed from somewhere:
    Traditional computer graphics models are geometry stored in a database, but at Pixar, models are procedural - that is, they exist as programs that are executed to generate the actual shapes. Some of the background and rigid pieces are done in a traditional modeling system (Alias), and these are incorporated into the "program". The procedural modeling system (custom developed by Pixar) is the basic environment that everything developed for the film goes into.

    The model procedures include various "avars" (animation variables). These are the "puppet strings" the animators control to move and change the model. Mr. Potato head's mouth used 8 avars for the basic shape, some others to control its position on the characters face, etc. The "holes" in Mr. Potato Head's body could be turned on and off as needed with an avar. Avars can be high-level, e.g., controls for walking, bending over, etc. The controls are usually given appropriate names (e.g., "move elbow"). A complex character like Woody has over 700 avar controls.

    For animation, stick figure stand-in models are used because they can be moved in real time on the animator's workstation. Later, the data recorded by the animator is "executed" again with the real model to generate the data for the film.
The UI consists of a number of independent windows. There are typically a number of camera windows open, showing wireframe or Gouroud shaded view of the characters. Each camera window has the menu options:
  • undo(u)
  • save
  • get
  • acam
  • axis
  • zoom
  • misc
  • setup
  • quit
The main interface is basically a spreadsheet. It's actually quite spartan. You can see it in all three photos. At the top of the window are the following menu options:
  • undo
  • add
  • del
  • sel
  • clr
  • move
  • copy
  • mung
  • linear
  • misc
  • edit
  • setup
  • quit
You can see in the third photo that the linear menu option is labeled as beizer, so I'm guessing that the menus don't work quite the way you might expect.

Each row holds an avar, and each column shows the value at a particular frame. Only columns that actually hold keyframes values are displayed.

In the title of the first column is the current frame number, and in each row the value of each avar at that frame is displayed in yellow.

The second column holds the names of each avar. In the example in my book, the left names are clipped, but they look something like:
Code: Select all
ead/lneck headturn
ead/lneck headside
ead/lneck headfront
/buzzhead jaw_matci
/buzzhead rusneer
/buzzhead lusneer
/buzzhead lolipUD
d/jawbase pucker
/buzzhead lstretch
/buzzhead rstretch
/buzzhead rbrowout
/buzzhead lbrowout
/buzzhead rbrowin
/buzzhead lbrown
eyes/left lpupdown
eyes/left lpupleft
eyes/left llidtop
eyes/left llipbot
yes/right rpupdown
yes/right rpupleft
yes/right rlidtop
yes/right rlidbot
I suspect that add and del menu options are for adding avars to the spreadsheet. With characters having more than 300 avars, you can see why they don't all appear on the list.

The remaining columns have the frame number as a header, and then the value (if any) of the avar at that frame. Only the keyed values are displayed; interpolated values are displayed in the first column. The current column is highlit in purple.

At the bottom of the spreadsheet is a horizontal slider so you can move along the timeline. You can see it in the second image - it's the red widget, with a yellow arrow pointing to the current frame.

A seperate window for editing the motion curves directly is also available. The menu options there are:
  • undo
  • curve
  • d_e_r
  • sel (alt)
  • ops
  • linear
  • setup
  • avars
  • quit
Each curve is a different color, but I don't see where there's a correspondence between curves and avars. You can see it in the first photo, sitting in the upper-right corner.

There are other windows, such as for playback and so on.

In this version of Marionette, it doesn't appear that IK is implemented, although I know that it exists in later versions. You'll also note that there are avars for high-level actions, like walking. So there's more in common with POV-Ray modeling than you might think. :D

The only other thing that I've been able to find that comes close to Marionette is AL, by Stephen May, right down to supporting a spreadsheet-like tool for animating objects.

I'd like to find out what's been changed to keep Marionette up to date. I know that they use tools like Maya in their process, but I was under the impression that it was mainly for modeling. I know FK and IK were incorporated as well.

Still, I think it's important to remember that, for the most part, it's the person using the tool, not the tool itself, that actually created the amazing animations. If there's any magic to be found in the Marionette program, that's probably it. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sun Oct 30, 2005 4:41 am

OK, I've been through the "Making Of" portions of Monsters, Inc., Finding Nemo and The Incredibles. The fact that so little of the "Making Of" documentaries focused on the technology should be is a pretty strong statement. Someone said "It takes a tremendous amount of effort to create something that looks effortless." :)

I'd also forgotten how gorgeous that film looked, and how much Pixar seperates the workflow into independant elements: layout, blocking, simulation, lighting, etc.

That having been said, I noticed a few more things about the Marionette. In Monsters, Inc., the interface still retained a lot of the elements it had before:
Image
Some things to notice:
  • The spreadsheet retains the same elements. The Current Frame column is still there, but it's blocked by another window. Next to it is the list of avars, and then the columns of frames. Every fifth row is red to make it easier to find things. Underneath everything is the "real" timeline, since the frames aren't necessarily evenly spaced out.
  • The currently selected row is cyan, which changes color as the mouse moves over the different rows. When the cell is clicked, it turns red. (I don't know what green portion is). Something I wasn't aware of: you can change the value of an avar by clicking in a cell and the dragging the mouse. As long as you drag the mouse, the value will change - it's not limited to the size of the cell. In that way, it works a lot like slider buttons work in Blender.
  • You can see the timeline slider has a yellow arrow pointing to the current frame. I think the red horizontal bar shows the relative amount of area currently displayed in the spreadsheet.
Here's a shot from The Incredibles. It's the same spreadsheet interface:
Image

While the spreadsheet is one of the most visibly intriguing bits of Marionette, it's hardly the only element. I found the following quote here (circa A Bug's Life):
    One of the things Kahrs particularly likes about Marionette is its ability to transition easily between forward and Inverse Kinematics and the exactness of its controls. To illustrate, he plays back a scene in which Hopper gestures with his arms then grabs his brother Molt and shakes him. He created the first part of the animation by animating Hopper`s arms, and created the latter part by moving Molt, not Hopper. All the animators have their own video recorders that give them the ability to store and play back their clips. Onscreen, they work with a layout that contains a grid shaped to match the irregular ground plane and a few key objects in the scene.

    "When we re-engineered Marionette we added in a snap to the ground for the characters and the ability to see several layers of animation," says Reeves. "These are not 2D layers composited together; they`re all in 3D."
So Marionette has had the cool IK stuff we've been talking about has been there since A Bug's Life. :?

Here's a shot from The Incredibles. I assume this is the user's interface to FK, although it might be a shot of the rigging tool. It looks a lot like the Maya rotate tool. You can see a little "pie slice" showing how much you've rotated the limb. I assume the Camera option allows you to rotate the camera around the point you're looking at, which is pretty cool:
Image

Here's something amusing from a Max FAQ
    >Q: What cheaper alternatives are there besides 3D Studio MAX?

    A: Animation Master by Hash software is heavily aimed towards character animation (it operates in a similar vein to 'marionette', the software written and used by Pixar for Toy Story/A Bugs Life), and one person I know who is a commercial Maya animator has said that AM can even out-do Maya in terms of character animation. Best of all, it only costs $199 US, and has fantastic support from it's website, users, and developers. Info can be found at http://www.hash.com.
I thought that was sort of funny. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Oct 30, 2005 10:57 am

That's pretty interesting, thanks for the images!

Looks like all the systems use the same approach: There's a number of variables (e.g. for morphs, bone rotationes, whatever) - and the UI is just responsible to give the user control over these variables.
I think there are two important things the user interface must provide:

Firstly (and this is the most important thing) it must provide immediate interactive feedback. If you cange a variable, you want to see how this change affacts the model. That's the main difference to the "POV-Ray style", where you change a parameter and have to wait e.g. 10 minutes before you can see the result.

The second thing I consider important is that the UI allows to group those variables and, if it makes sense, allows to modify several of these variables at once. Examples are IK, but also the "smartskin morph" - if you rotate a bone, it also triggers a morph - in effect, you e.g. manipulate the bone slider, and the UI automatically moves the corresponding morph slider for you.
This concent can be extenden. Instead of controlling several "sliders" in parallel, they could also for a sequence - this could be used to record and play-back actions. Define several steps of a walk cycle and bind them to a single "slider", in the animation you need only to cycle the "walk-slider" from 0 to 1 and repeat it to get a walk.


Ok, before I forget, here's something I'd like to show you: It's working!!! :D :D :D Yeah!
I used the PuttyDudeMillinium A:M model (by William Eggington) and a skeleton I've made. Points have been autoassigned - currently this is rigid (i.e. there is no weight) and smartskin morphs are not implemented.
Just give me a few days to fix some bugs and add the missing features...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sun Oct 30, 2005 8:49 pm

Excellent! I can wait a couple more days. :)

I think the 'ticks' on the bone limits don't really add that much information, though. They also make a scene with a lot of information in it even busier.

There's also potentially two sets of ranges for bones - the "maximum" range, and the "comfort" range. The "comfort" range helps IK stay in a reasonable range, while the "maximum" range is the normal working range.

By the way, the "Press ATL to move perpendicular to the screen plane" message should be fixed at some point. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Oct 30, 2005 9:30 pm

I think the 'ticks' on the bone limits don't really add that much information, though. They also make a scene with a lot of information in it even busier.

I agree. I'll show them only for the selected bone. They show the axis and the limits for each degree-of-freedom. I'll also add a "handle" for each dof in the viewport. I'll put all this into a separate tool, so it doesn't pollute the screen all the time.

There's also potentially two sets of ranges for bones - the "maximum" range, and the "comfort" range. The "comfort" range helps IK stay in a reasonable range, while the "maximum" range is the normal working range.

Yes. Another method would be to apply some kind of energy minimization. Every DOF that's not in it's resting position consumes some amount of energy. Potential energy is also accounted for (e.g. a lifted arm consumes more energy) - alltogether the system tries to minimize the energy.
There are also systems that try to keep a body balanced (when different forces like gravity or acceleration act on it). I've even read about AI systems that add natural reactions to artifical characters - e.g. reflexes.

I think all these things make sense e.g. for games, where it's neccessary to automatically create the animations on the fly, or for systems such as "Massive" (the software that controlled the thousands of characters in some scenes of Lord Of The Rings).
I'm not sure if such tools make much sense for "classical" character animation: The IK system should help the animator to quickly set up a pose - if some things look uncomfortable, it's probably best to manually adjust them using FK.

Anyway, it's too early to tell. Once FK and basic IK is working in JPatch I'll need to gain some expirence using it before I can decide what additional tools to implement. I'll also have to look at how other tools implemented IK... :wink:
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sun Oct 30, 2005 9:59 pm

Sascha wrote:Anyway, it's too early to tell. Once FK and basic IK is working in JPatch I'll need to gain some expirence using it before I can decide what additional tools to implement.

So the sooner you get the Animator working, the sooner you'll be able to start working on the IRTC submission and identifying what really needs to be added.

I'm not sure what sort of workflow will make the most sense for JPatch. I'm guessing that your typical user will be a single animator who's responsible for the entire project. From a user point of view, having everything blended into a single interface is appealing.

Segmenting the workflow into seperate bits - as Pixar does - really appeals to me. For one thing, it means that you can have very specialized tools at different points in the workflow, and not have to worry about a single interface carrying the burden for the entire application. This also means that when you're working in the Animator, you aren't worrying about textures, or lighting, or cloth simulation. That can be considered good, because you're focused on a single task.

As you said, you won't know until you actually try it, and then different people will still have different opinions. :D

I'll also have to look at how other tools implemented IK...

Yeah, you knew I was going to mention having a look at AoI. ;)

I keep hoping that you'll be able to pull the IK classes out verbatim, but I know it's never that easy. Although (the last I looked at it) the core IK class was decoupled from the UI, Peter was using a different 3D class than you, so it'll probably be a complete rewrite. :(
Last edited by dcuny on Mon Oct 31, 2005 12:46 am, edited 1 time in total.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Oct 30, 2005 10:36 pm

I'm guessing that you're typical user will be a single animator who's responsible for the entire project. From a user point of view, having everything blended into a single interface is appealing.

Segmenting the workflow into seperate bits - as Pixar does - really appeals to me.


Well, my "vision" was a modelling/animation tool that could be used to collaboratively work on an animation over the internet. If open source software can be developed by hundreds of individuals spread all over the planet, it might work for animation movies as well :)

Ok, down to earth, a workflow that is devided into cleanly separated tasks doesn't neccessarily prevent a single user from playing all "roles" - And as you said, I think it even helps focusing on the current task.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby squirrelhavoc » Sun Oct 30, 2005 11:04 pm

I wish I could get excited by all this talk, but it's left me with a few questions:

1) What is DOF?
2) What is Inverse and Forward Kinematics?
Squirrel Havoc

We live as we think, very very slowly....
squirrelhavoc
 
Posts: 180
Joined: Tue Jun 28, 2005 11:17 pm
Location: Oklahoma, USA

Next

Return to General discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron