Is there a mass based rig? Opinions?

[queequeg]

I'll try to explain what I mean by mass based behaviour: The three big masses in the human body are pelvis, chest, and head. The weighted average position of those is a good approximation of the center of mass(COM) of the human body. What I am looking for is a rig that features for example pointConstraining the COM (either xyz or xz). I.e. when I move the hip a bit to the left, both head and chest move to the right, in order to keep the COM in place.

Something more advanced would be having the arm automatically swing while walking. When I walk, my arms/shoulders are very relaxed, and most of the movement of the arms come from the chest. -> pendulum.

When I'm animating with one of the rigs I found on the internet (I tried Maya rigs, Animanium, Motionbuilder), or those I've built myself, I'm constantly fighting with the rig. A common situation is when the character is balancing on one foot (to kick for example, even a simple walk cycle). All the time, the COM must be above the foot. Now, where exactly is the COM? And how do I keep it there?

So my question is: Has anyone ever heard of such a rig, seen one, or even tried it? Even better: Implemented it?

TBH I doubt that such a feature already exist, because in each and every CG film I've seen so far, there are lots and lots of movements that scream "IHHHH!!!! KAAAAAAY!!!!" MOCAP is a) cheating and not worth it. Even Pixar has problems with weight. Everyone. Gollum's face is super sweet, but the body movement... Usually, when I watch a CG film, there are 2-3 outstanding movements where I say "oh wow, that was good." But that's it. Am I alone with this? Is it not important?

I really don't intent to say that animators suck, or anything like that. Animation is more than realistic body animation. What I try to say is that FK/IK-only rigs are probably just not enough, because they don't know anything about weight. And they are in fact rather counterproductive for animators, because animators know a lot about weight. So, aren't there any alternatives?

[warpcat]

I've never actually seen what you're describing, other than sort of hacks. But from my experience (as someone who builds rigs for people all day) the animators I have worked with usually hate any kind of "automation". Obviously, it's a personal preference, but I think even if what you're after is doable (and anything really, is doable), it will start to become pretty complex when you deal with other angles than upright motion. I guess all I'm saying is sometimes people think of a cool new function, but when in reality it actually gets in their way. All just theory of course, since I've never see what you're after implemented well.

[joojaa]

Agreed, its a good idea but in reality not somehing one would want to use.

Ive tried to push this to users but they dont like it!

[queequeg]

Warpcat: The main problem that I see with a rig like this would be the user interface. After all, IK is automation. And it makes getting the rig into a certain pose a lot easier. However, most IK is 1-2 bone IK, so it's very predictable.

Automation is not necessarily a Bad Thing, as long as it's predictable. And there should always be the possibility to switch it off. It all depends on the user interface.

Now that I think of it: The automatically swinging arm wasn't a good example, because it is not really a rig specific feature; it's more a question of tangents, not of poses.

Anyway, my basic idea is this: When I imagine myself talking to a real actor, and I have to describe the movements that he should perform to get into a certain pose, how would I talk to him? Things I'd say would include "stand on the left foot," and, when he stands on one foot, "keep the waist like this, and bend to the left." Something like this.

So what is easier: Talking to that actor, or talking to an IK/FK rig? I'd prefer the actor, because the actor already has certain automated movements. And balancing would be one of the most prominent IMO.

Joojaa: Why wouldn't one want to use it? Did you test it? What was the specification?

[failure]

No rig can teach you weight.
You'll have to learn it all by yourself.

Weihgt is inside the animator. Not inside the model/rig/ik/fk/bones/mocap/normals/tangents/quaternions thingie.

You cannot automate the feel

[ writing pure poetry lately ]

[joojaa]

Extra clutter. Se most animators prefeer controlling every aspect of thigs. If the countermove is automated, what is to say the animator wanted something different, could be a switch of some kind. but then you wouldnt be able to manipulate teh anim curves that controll this etc. etc.

Se a body isnt balanced at all times, in fact whan you jump run and in fact move at all its intentionaly unbalaced.

Believe it or not but animators actualy use FK just because it has most predictable curves wich they can read from the curve editor and its simple gves most controll.

A system where theres a visual hint of the Center on the otherhand seems more acceptable than one that actualy moves the body.

But i believe sony tried to sell a anim system like this but it didnt fare too well.

On the otherhand a rig where you can move the center bod just 6 or 5 translates would be nice. Especialy if it allows you to pin each corner fast and let the shape stay put in a intelligent manner.And allows you to pick the body proxyobject and move it along where you picked onb the surface.

[queequeg]

failure: yes and no. You're right, the animator has to have a very good feeling of weight, and no rig will teach him this. However, if the rig has 0 support for weight, the weight-conscious animator will constantly fight with the rig to keep the weight right. I mean, when I have a rig in a certain pose, and I change the position of the chest a bit, the entire pose is kinda ruined because of a rather big implicit weight change, so I have to rebalance everything by hand.

I don't want the rig to do all the work. But I want a rig that understands and supports what I want, and part of what I want is good weight.

Your post sounds a bit like eastern philosophy, so here's the western reply: Why use that katana when it's way easier to use a Magnum?

Joojaa: But "every aspect of things" also includes weight. When you run and jump, you have to be very careful about how the body is unbalanced. FK-fcurves don't say much about weight, only very indirectly. If you work with FK-curves to adjust weight, it's a very boring and tedious process of trial and error. Maybe you can speed it up with a lot of experience, but now we are back at katana and Magnum.

And as I said before: It all depends on the user interface. And it has to have an off-switch. It should help, not force, that's what UI is all about. One way would be to have the COM constraint animating time-only, so you can key it and get your fcurves. Or instead of IK/FK switching have IK/FK/balance switching. I mean all switching is about changing control. There is a certain number of DOFs in a rig. When you switch to IK you get additional DOFs at the expense of others. That's all. It's just a question of what you want to animate: Joint rotation, end effector position or weight? It doesn't mean loss of control, it means changing what you control.

Example: Balancing on the left foot. The additional DOFs would be the position of the foot and the COM (which can be moved of course), while you would loose control over the rotation of the leg (hip joint) and the ankle (because the foot is parentConstrained to the floor). If you lift the other leg, the entire upper body moves by "rotating" the entire left leg in order to keep the COM in it's xz position. However, all those implicitely moved parts (here: the upper body parts) must never ever change their overall rotation or their positions relative to each other (i.e. try to outsmart the animator), but only relative to the COM and the foot. It would be sort of a 1 joint reverse leg with weight support. I think it'd be quite useful, and, because you only loose two DOFs, still predictable.

[joojaa]

Well yes but how do you porpose the rig handles such things as tumbling and clibing then? Lets face it a walk cycle is easy as is. Animators get called when theres a need for some extraordinary movement that cant be done otherwise.

I mean if the countermovement is right 50% of the time then the animator will be constantly working against your rig even when he is in the 50% range because he will want to tweak tweak tweak. It happens a lot.

Also doing fcurve editing isnt so boring or tedious if you dont edit them in viewport but as fcurves directly after the nitial movement is establised. Cut paste are wonderfull tools for secondary animation paste shipf paste shift scale and your doen with it.

[queequeg]

Joojaa, I don't want to remove or replace functionality, I want additional functionality. When I use IK while posing, I still use FK keys most of the time, IK keys being a rare exception. This is what I mean by "animating time-only" as opposed to "animation time" (playingBack). You could still use FK keys and use the balance mode only while posing.

The DOFs in a basic FK skeleton are the joint rotations, and the translation of the root. What is your guideline for animating that root translation? I mean this root bone in world space is such an arbitrary and IMHO far-fetched parametrization. However: Is it just a coincidence that normally the root bone is located approximately at the position of the COM, and not, say, at the head? Why not use the real COM instead, which would give you explicit control over the weight of the entire body, which would probably be more useful?

A walk cycle may be easy, but a walk cycle that shows a good feeling of weight is just as hard to get right as any other movement. My ramblings about animations screaming "IK" refer to about every walk cycle I've seen so far, be it from Jack NoName or Pixar. And, come on, for a biped, climbing and tumbling are really not the most common movements. As the name "biped" suggests. Who does 95% of the other animation?

I mean, I understand your argument, but, as I said before, there must be an off-switch. If the animator is fighting with the rig because of COM constraining, he switches it of, no big deal. What I try to say is that I found myself many times in situations where I fight the rig because there's no COM constraining.

And why would the weight-conscious animator want to tweak a pose in a way that destroys the weight? If my fictious rig is in keep balance mode, tweaking would still be possible, but now you don't tweak that root bone/COM fake, but the real COM. Why would that be a problem for an animator who has a good understanding of weight anyway?

Here's an analogy from programming: Not so long ago, procedural programming (c, pascal) was the state of the art, but object orientation eventually became the dominating programming paradigm. Why? Because a) it is easier to model real world problems and it is just an extension of procedural programming, not a replacement. You can still write butt-ugly c-code in Java. And also the reverse is true: You can write very nice object-oriented code in plain c. However, an object-oriented language has features to support, encourage and facilitate object orientation.

Back in the CG world: Weight is an important part in animation, but although this is known for decades, there is still no rig that supports, encourages and facilitates weight-oriented animation. See my point?

[failure]

I think you are searching for the weight in the wrong place. Weight is function of timing, not posing.
If you have the most sophisticated posing engine in the world and you still screw up in actually animating the poses, there goes your weight down the drain.

There are no real benefits in com based control. At least not as long as weight is the issue.
Take a simple example in which weight problem is not obscured by the complexity of biped-like character: You need to animate a single sphere. And you need to do it so it has a great sense of weight. How can com based control help you here? I doubt it can.

Model, rig and posing tools can grow more complex but none of them acctually has anything to do with weight in animation. Note: weight in animation not weight in posing since later one has a little sense ( at least to me )

Even If someone make com based tools as you suggest I believe majority of animators will find them annoying at best.

If we still conclude that com based control would be somehow useful it for sure wouldn't be in a form of constrain-like tool.
Last thing you want in the animation of biped body is fixed com. It yields very unnatural movement.

You would need to define masses, gravity and other forces in order to use the com rig for some benefit. Without them the rig won't know how to behave. This all is time dependent so it would be more like simulation than posing /constraining tool.
It brings us to a very complex topic of simulating the forces in the human body. But I'm pretty sure that's a thing that average animator doesen't like to tinker with.

Using com based constraints wouldn't really change present animation paradigms. It's just another form of constrain.

Magnum is really cool but you can fire your six shiny loud bullets really fast. And then what? Really fast, you'll have to run back to the ammo store. With katana you are deadly all the time.
But in reality I prefer all things western. So I would always pick magnum over katana. Especially if my backpack is full of bullests. E-especially if I must fight pack o' katana wielding thugs.

[joojaa]

I could se the logic in tha fact taht theres some com based controll.

But actualy posing a object the way you describe isnt all that beneficial. As a example out of this cotext lets take a posing system where you can grab the animation porxy or the final object whereever and pose it by puhing say th hip a bit that way and tehn the sholder thiswai and belly tahtway. wouyld be intuitive. But This still would have all the problems accociated with rigs. The rig is simpler to get into, but the time it takes to learn the rig is actualy not a issue most of the time.

Se theway you place the object isnt realy a issue, as llong as tyou can predictably do it. Now if it is automated overmuch so that theres 2 things happening when you move this or that, its one otehr thing to check for,

How does tha rig account for such things as slight bodyform changes humans do to lift the and lower the point of weight? Or unnatural movement thats wanted.

[queequeg]

Ok, this is my point: There is a center of mass. Right now, with a typical FK/IK rig, we control this center of mass only implicitly; whenever we move a body part or the root, the position of the COM changes, which effectively changes the weight distribution in the whole character. That way it's really easy to mess up the weight in animation, unless we have a lot of experience. But even then it's merely guessing.

I don't consider this a given, inherent fact of animation; it's a problem that asks for solutions. So I was looking for alternatives, and I started this thread to find out if there are other people like me. However, I am aware of the fact that it's quite a hard problem. I don't expect to find a perfect solution, but ways to deal with it in a more effective and appropriate way than what is possible/available right now. To me, enhancing the rig was the most obvious starting point.

---

It seems that I didn't express myself very well in previous posts, so to make things a bit clearer:

• When I said "pointConstraining the COM" I didn't mean to fix it forever and ever to some place in space. I meant pointConstraining to some control object, so you can change or animate the position, whatever you want. You could use it for the animation itself, or only to get the rig into a certain pose; your choice.

• It's not the optimal solution for every situation. So "weight-based rig" should probably be replaced by "rig featuring FK, IK and weight-oriented behaviour" or some such.
  I only referred to situations where you WANT the COM to stay (or to be) in a certain location. Be it above the left foot while walking, above the center of both feet in a standing position, a bit behind the feet when preparing for a back-flip, or constrained to a path-curve when jumping/falling.
  However, if I try to animate some movement, and I don't know where the COM is in a certain pose, it's safe to say I have not yet understood the movement.
  If you want unnatural movement, and weight doesn't matter anyway, why use a weight-oriented rig? However, with a weight-oriented rig you could control how unnatural the movement is!

---

failure: I really don't understand your sphere-example. The center of the sphere is it's COM anyway, so what's the point? If you animate the center of the sphere, you animate the COM. The whole point of this COM feature is that the weight/COM _IS_ obscured in a biped. This is the difficulty in animating a biped the right way, and I tried to think of ways to reduce that difficulty. Reduce, not magically take it away. I'm not talking about having the COM animated automatically, but about having the possibility to explicitly control and animate it. (As opposed to only implicitly with FK/IK!)

And: A fixed COM looks way more natural than a fixed root joint!

As for the simulation issues: Yes, it would be a step towards simulation, BUT only as far as it remains usable. After all, animation IS simulation; not computed but made by animators. Animators simulate life. So animation tools should simplify that process.

You're right, weight is a function in time, but a pose is only a snapshot at a given time. If you look at some pictures for rotoscoping, you can still identify the COM in every picture. So you can interpolate this as a function in time, the poses being edit points of a NURBS curve.

Joojaa: The way you place things CAN matter, depending on the situation. Ok, you can get the same result in this way or another. But if you are in a situation where it is important that the COM is here or there, being able to explicitly control the COM is obviously an advantage. You said: It's not good "when there are 2 things happening when you move this or that." But consider this: When you move a limb IK/FK style, there are more things happening anyway, because this implicitly changes the COM! It only depends on how you look at it. The COM is invisible/fictious, so you don't see when it moves. But that doesn't change the fact that it moves!

As for the up/down movement: This is what I meant when I said pointConstraining in xz only. For example when the foot is planted on the floor, the y position of the COM would be implicitly determined by the contact point and the state of the rest of the body. I could go into more detail if you want to hear it.

[joojaa]

Wll my rigs do fequently have a indicator to show where the com is. Its a visual aid but the animator will still want to se the axact poits he moves not move around by it. Altough it would be nice if maya could get imput from two differebnt sources in a more intelligent manner. Even channel aliases would be nice.

So show it is usualy fine, whereas move but is not. Because its inhirtly unexact by nature.

The real problem is that its hard to anticipate wtre the com is at any given time. It depends on so manu things such as what mushces are flexed etc etc.

[failure]

Visual cue is often more than enough. Good animator won't even need that because he/she can simply "see" or "feel" where the com is and where to put it "next" to achieve the balance or unbalance.

The more you elaborate on com constrain the more I fail to see It's benefits and even feasibility.

See, you can't really exsplicitely animate com. There are two possible approaches: ik and fk.

With fk you transform the com to some new position. Since this is the com all sub-com's must rearange. There is infinite number of solutions to this but the easiest way for solver to handle it is just to tell sub-com's to inherit from com ( standard fk behavior ). Of course, some of the sub-com's might be constrained by other means, so solver ( or animator ) must decide about priorities. If some constraints have higher priorities than com, then com couldn't be placed at the desired location. You are stuck and this behavior would look awkvard. So it's either weird behavior or standard "root-joint" politics.

If you are for the ik approach then you'd have following situation: Pin the com down, pick one of the sub-com's as interactive ( freely transformable ). Other sub-com's in the system must magically rearange to satisfy com equation. In this situation solver will end up with infinite number of possible solutions. So there must be some intelligent system to decide which is the best solution. Reasonable way to do it would be to utilize standard ik-like system as a helper. Now it's obvious that this ik sub-system does all the real job here since com is to dumb to know anything about how to rearange all of the sub-com's. So we can freely bypass the whole com thing and just use ik since com can't help us one little bit here.

It's clear from above that any form of com constraining doesn't really make sense. In fact it could make sense if you bring the dynamics in the picture.

Weight really depend on forces applied, not on mass. Mingling with the mass settings can't help you. It merely "sets up the stage" for forces to act.
It's when you apply forces you get the weight ( or illusion of weightfor that matter ).

So if you wan't some sort of mass based solver for biped, you'll need to define the forces. Only that way you can instruct the com solver to behave properly. Othervise you'll end up with infinite number of "right" solutions. And once you bring in the dynamics the com shouldn't interest you, since you don't need such a hi-level abstraction anymore, solver is doing it all right now according to laws of dynamics.

Consider situation for walking biped: there is gravity as a main force and a number of biped's micro forces oposing it during walking. Those micro-forces are originated in biped's muscle system. Now all we have to do to get this right is to define biped's mass distribution, biped's dof's and all of the force vectors and their change with time. Dump all of this into the solver and voila! Perfect weight.
If we put aside that no today's hardware could acctually handle it, who would wnat to do animation this way?

I took a sphere example to try to illustrate that the illusion of weight has nothing to do with com by itself. You said it yourself; It's trivial to have absolute control over sphere's com. But still it's pretty hard to animate it with sense of weight. ( However it's not true that the sphere's com is always in the center. It cease to be if you apply any kind of nonlinear transformation )

Remeber that weight is a force. Mass it not. You can apply weight ( force ) to a mass to get some movement.
So think about the two terms you are using as synonims all the time: "mass based rig" and "weight based rig". They are pretty different concepts. Which would it be then?

I hope you are aware of the fact that in all of your explanations you've assumed implicite existence of some kind of gravity force during com solver interactive session, and yet you completely fail to elaborate on it. While in the same time you don't take into consideration biped's forces ( explicite or implicite )

[warpcat]

Man, this thread I just skimmed most of it up until this point. Isn't whats being talked about here "Character Studio"? (and forgive me if it was already brought up). I've never used CS, but I know most of the "pro" animators I talk with give the yuck face when discussing it. Of course, this is a sensative subject for Max people, but I doubt too many of them are reading this thread I have my own opinions which I stated at the beginning, no need ot state again. But i had to bring up the CS thingy.

[joojaa]

Theres a increasing number of max people who do not like character studio at all.

[queequeg]

failure, I'll show you an example of what I mean. It's really not as complicated as you think. Give me a day to get the math done though.

I apologize for mixing weight and mass. I wasn't really aware of that, and I was probably talking about mass most of the time.

Warpcat, last time I've seen CS was like 6 years ago. I've just read the tech specs for CS4 and couldn't find anything relevant/unusual. However, I'll check out the trial.

[failure]

I don't think it's complicated. I think it's useless.
And I bet you that what you'll come up with wouldn't be helpful in terms of reducing the human efforts when animating ilussion of weight.

I'm anxious to see the example

[queequeg]

In reply to:I'm anxious to see the example

I'm sure you are. ()

anyway, here (playblast, avi, 400kB, I had to zip it, sorry) is an example feature on a really crappy, um, "character". It's only 2-dimensional at the moment, but I think you'll get the idea. I've used linear tangents to keep it clear what happens. I hope it's obvious what parts of the rig I move at any time. I did no research about the masses of the human body (in numbers), so there should be much room for tweaking.

Controls: The rig has two main parts; the upper body and the legs. The upper body has a quick hack spine where you can control the (WS) rotation of the three parts. The legs can be controlled by rotating a knee control. Additionaly there is the COM target (the sphere), and the feet's snap target located at the origin. Both can be translated.

Here is another blast to illustrate what happens. The rig is driven by an expression that computes the translation and rotation of the legs (as a whole) and the translation of the upper body. Both parts have a sub-COM(white locators in the playblast) that is determined by their parts. For example the thighs and the calves both have a mass point(black selection handles), and the sub-COM of the legs is the weighted average position of these two mass points (think pointConstraint). So, those two sub-COMs determine the COM of the entire body (green locator). The expression makes sure that this COM is always placed right at the xy-position (it's a z-up scene) of the COM target, while the translateZ value is determined by the snap target and the legs' "lenght".

This would be one example feature, which, in a real rig, could be switched on and off like IK. Other features could be variations on that, with no snaps, or both feet snapped, whatever.

[failure]

Excuse me, but this is plain ik