Skeletal

In bones mode, on the Hierarchy tab, you can offset, scale and rotate the bone (and its children) relative to its current position... there is also a checkbox "move control points" Click that checkbox on, and change the offset of either the patriarchal bone(s) such that the feet are now at x,0,z as you want.

- David Snyder

The roll value in the property box for the bone is useful only to enter an offset based off of the current positioning. This makes some degree of sense, since there is no easily intuited "True Magnetic North" of roll. Anyway, if you enter "90" in the box, the bone will roll ninety degrees, and the box will flash back to the number zero. So, basically, in order to copy things out, you're probably going to have to do it by eyeballing. I hope this helps.

Actually as long as the bones that you move around to to the actual animation are named the same then you can swap em out at will. in fact if you set up the constraint systems in a pose and apply them with a slider at animation time then you can even have completely different constraint systems at work and as long as the bones that you move around and the pose that hold your constraint system are named the same it will all come across wonderfully.

the trick here is that when you swap out the model the channel data doesn't look for hierarchy or parent child relationships it only says 'move Left Hand in this manner." "apply Pose:Constraints with a value of 100" so on and so forth. So if the proxy has a bone named Left Hand and a pose called Constraints then everything works out for the new set of underlying bones as well, even if you called the fore arm 'left forearm' in one model and 'big_ole_forearm_bone_of_the_left_side' on annother. the data just ignores those bones and the pose has the appropriate names for the bones in it's particular model.

David Rogers

The reason why the bones systems are not named similarly is because they are not meant to be swapped. The Dennis system described in Dem Bones was created for v7.0--it predates the ability to swap models at all. Instead, DennisProxy was meant to be used as an Action Object of Dennis.mdl and attached to it with constraints. There was a DennisFull model (which I did not include for obvious reasons) that would have been used in an alternate Action to swap the model. This is no longer necessary, since you can just use the direct shortcut swapping feature, so all the setups I use today are created with only one model and not two.

--Raf Anzovin

Set up the bones in the crease of the fold and use roll. set longitude and latitude to 0 ( Zero ).

Ken Williams

This is a very easy effect to achieve with the Translate Limits constraint. You make the bones in a chain, A, B, C, D (one the parent of the next, and so on), but with them all in the same position (same base, same tip). "A" stays in the place where the telescoping starts -from-. B is your controller... constrain it so that it can only move along the Z axis of bone A (using the Translate Limits constraint.

Then constrain C as follows:

1. Translate To A.
2. Translate Limits, only along B's Z axis, and with a minimum (or maximum, depending on which way you want to telescope) Z value. Move B far away from A, and tune the maximum value until C -just- keeps contact with B.

Repeat these steps with D.

This will probably make -no- sense until you play with it for a while, so that's what I'm going to recommend you do. I can't make it much clearer short of drawing huge amounts of ascii art, unfortunately :)

-- Tony

Yes, this will do that. The "Translate To A" constraint will remain in force, keeping bone C at precisely its starting position, -until- it is overridden by the Translate Limits constraint, which will only happen when Bone B has gotten far enough away.

I haven't tried the above method so it may work too, but I myself would go with a pose slider. The good thing about pose sliders is that you don't have to create just two positions (zero and 100%). You can also create intermediate positions. So you could model your telescope closed, and that would be position zero when you create a pose. You could then type in 20 in the frame number field (although it's probably more accurate to call it 20%), and move the first extension of your telescope out. Type in 40, and extend the second section, and so on until 100, at which point the telescope is fully extended. This makes the telescope very easy to control via its slider during animation.

If you're going for a cartoony look, I would make 80 (or some other number to your liking) your final position, and 100 a stretched version. You would then overshoot 80, and bounce back to it. (Maybe even have the character's eyeball protrude from the other end of the telescope?) You could also do the same thing when contracting it, going into the negative numbers and back to zero for a squash effect.

--Roland

You can't weight the cp mappings in A:M but there is a workaround that works equally well. Just create an additional bone and place it at the joint in question. Now make two constraints "orient like" for that bone. One for each original bone of the joint. Assign the CPs to that new bone. Now you can adjust the percentage of the constraints to fine tune the mapping. This might still not solve all your problems with some problematic joints (like the shoulder) so you might want to use smartskin - which is basically a morph based one a bone angle rather than time.

Martin Weber

Ok, perhaps I'm a nitwit, but I just stumbled onto a solution that seems incredible obvious, but which I've been toiling over for at least a week. I wanted to create an arm setup that was switchable from IK/FK. I tried all kinds of crazy constraint setups, with alternate skeletons and compensate-mode to engage contraints, yadda yadda... it worked, to a certain extent... Then I tried something incrediblly obvious and easy, and it worked 10 times better! I animated my arms up to a certain point with FK. Then I went back to the model and attached all the arm bones to their parents. All the stuff that I did when the bones weren't attached stayed exactly the same, but now the bones were IK!

There may be some solutions that are quicker and less tedious than going back to the model every time you want to switch, but if you only need it a few times like I do, this seems to work great!

I have this strange feeling I'm the only guy that didn't know I could do this. But for those of you out there that were with me, I hope this helps you sometime!

-Chris

When a bone is constrain to a path, it will by default lie horizontal on the path and will steer along it. In the properties tab, you have the option of disabling the steering effect by unchecking the "store roll" option.

Presuming your character is built facing front and standing up. You probably had a vertically oriented bone constrained to a path on a horizontal plane. It'll flip the bone and it's associated points on it's "belly" so to say. If that's absolutely what you need to do then you'll have to uncheck the "store roll" option and rotate the bone to get a rotational offset. If this is not desireable, then why don't you constrain the master bone of the model. In it's default state, it is horizontal, points towards the front with it's roll handle pointing upwards.

There's more to contraints to a path than just selecting a model and make it follow a path. What gets contraint to the path is eventually a bone. Any bone in the model can be contrain to a path. More than one bone can be constrain to the same path or any spline of any model for that matter as long as it does not result in a circular constrain.

-sine

Mucked around with a camera rig set-up and thought I'd post some preliminary findings. As usual it was much easier to put together than I expected. In the PWS right click on the object icon and select a new camera. Now switch to Bones mode and construct your rig as you see fit. Open it in an action window and set-up the constraints. Save a pose. Drag the pose icon onto a New Choreography in the PWS. In the choreography hit the skeletal mode and animate away. The rig I put together is similar to a human leg:

rig
        |-Foot
        |       |-Camera1
        |       |       |-Thigh
        |       |               |-Calf
        |       |-Thigh aim at
        |-target

The Foot in this case is the root or parent bone so I can constrain it to a path and the whole set-up will follow. The constraints I use are the Aim at "Thigh aim at" on the thigh. The calf has a Kinematic chain to the Foot and the camera has an Aim at constraint on the target null. It's a bit rough and I haven't thought about spherical constraints or refining it yet. I used some geometry (cubes) for the rig but it cast shadows across my set. So bones only. I had forgotten that the camera doesn't cast shadows.

So why go to all this trouble you cry. I guess once the set-up is complete you can use it in any number of projects. As I play with the camera I find that the camera only needs subtle adjustments to make a good shot and that the dollies and tracking shot don't need to be such broad sweeps. The rig can offer more control if it is animated in stages. Say the primary animation of the camera is a tracking shot. Constrain the foot to a path. Once that's taken care of the secondary animation such as targets can be addressed without concern for the path animation. The tertiary animation could be focus and depth of field.

As for superior shots mimicking analogue cinematography I don't think the audience would pick the difference between a synthetic camera rig or a camera constrained directly to a path. It might be a better use of time to work on developing good script ideas, empathy in your characters or lighting. Let me know if you want to check out the prj file.

Stephen Gurban

Well, not exactly.

A Spherical Constraint is a limitation on the latitude and longitude of movement within a sphere. *But*, let's say that you entered, for example, just a longitude limit of -10 to 10 degrees. The range of possible motion is then like a 20 degree orange wedge, with the fattest part being centered at the original point of the bone, and the thinnest points being 90 degrees of latitude away from that (i.e. the poles of a sphere for which the original bone position is pointed at the equator).

So it's an orange slice. With me so far?

If you view the movement of your forearm, assuming that the elbow itself is not allowed to translate in space (don't get me started about the elbow's rotation and spin, or we'll be here all day) you will notice that it too is an orange wedge. The wrist can move up and down very little when the arm is fully extended. Likewise, when the arm is folded all the way to the chest, the wrist can move up and down very little.

*However*, when the elbow is at 90 degrees, the forearm can rotate up and down a tremendous amount.

*That* is longitudinal motion. You can get that effect with a spherical constraint, but only if the original position of the bone is with the elbow bent 90 degrees. Only then will the original position (and therefore the wider area of longitudinal freedom) be in the correct position.

Hope this helps! Go slice up an orange, and strap your elbow to a pole, and it will all become clear :)

Tony Lower-Basch

If you're actually interested in understanding spherical constraints, there's all the answers (not covered in the Wilton tutorial, the manual, or the handbook, not really different info just emphasis) in the large clump of text (pasted from my sent items folder from a long time ago) after this paragraph. If you don't want to actually understand them then use Euler limits constraints X,Y,Z, I believe they added them in an attempt to keep people from chronically bitching about how hard spherical constraints are to understand, apparently it didn't work... }:(>

Matt Andersen

Gotta play devil's advocate on this one. While I agree a visual manipulator would probaly ease the learning process, these things are a long, long way from rocket science, much more difficult was trying to animate without using them. I decided I needed to add them to something I was working on and started trying to absorb the various tutorials on them, while thorough they are, to me very confusing and not something you understand with a layman's knowledge, so I just started messing with them in an action window. Basically a spherical constraint is a hinge with a certain amount of play, the latitude is it's movement axis and the longitude is the side to side play which can be added to it, it there is no latitude there can be no longitude, roll just rotates the arc of the latitude. If you want a hinge all latitude, no longitude, no roll. There's a couple of things to know when messing with them, you have to reduce the longitude in order to effectively work with the latitude numbers or it'll give you errors, longitude starts out at -180 to 180 (range=360) it's range has to be less than 180 for you to add negative longitude, I generally give roll and longitude all 0's then pump them up as needed. The second thing is right side to left side constraints if you made a constraint on the right side and want to create it's opposite on the right side use all the numbers but but flip the longitudes (right Min -15 Max 90 left Min -90 Max 15). For testing constraints, you can do it two ways, well you can grab the bone and rotate it around, but if you have identical latitudes this doesn't tell you which is which, the thing I like to do is change the minimum latitude because it actually moves the bones in the model see the default latitude minimum is 0 and so is the bone position but if you change that to say 40, it can't be 0 anymore as it's out of the acceptable range so the bone get's moved this tells you the direction of positive latitude, negative would be the other way. Hopefully someone will get something out of this they're not that complicated, just a hinge that wobbles.

The longitude defaults to 0, and it requires latitude movement before the longitude has any side to side effect (there's that hinge analogy again), generally you set the min and max longitude to the same number - and + respectively, unless you only want horizontal play on one side of the main axis of movement, that's what setting the min to 0 will do, change a spherical constraint to a hemispherical constraint. Areas where you don't want identical numbers - and + would be places like the shoulder and thigh, who's inward range of movement is much smaller than the outward. You've figured out all the hard stuff, which is the latitude and redefining the longitude range to less than 180 degrees, if you just play with the longitude settings in an action window it'll become clear very quickly, just set one to 0 and the other to 170 or so and drag the bone handle around and you'll figure out which direction is positive and which is negative, similarly to resetting the latitude min to a positive number, once you know the directions of everything it's pretty easy. Glad someone got the cool stuff at the end of my post, I thought I 'd lost everyone there.

There are times then the values should be negative instead of positive. Similar to how it's recommended that the roll handle should be opposite the direction of the major bend direction.

I've got the desired results without ever delving too deeply into this, I'm not sure if the driving ideaology was for IK usage or a version 5 quirk (bouncing bones and whatnot). Personally I point all my roll handles on something like an arm or leg in the same direction, except for a wrist joint who's main axis of movement is 90 degrees away from the elbow's. The negative values I use for latitude (roll and longitude almost always have negative if they have positive) is if the joint can rotate past it's start point in both directions (hip vs. knee, Shoulder vs. elbow). Very admittedly I am not Joe IK I started out my last project set up for IK and ended up with about everything locked, it included pole vaulting, rowing various vessels with 4 types of paddles, and various cycles and handlebars, lots of animating moving an object with both hands, it became clear to me early on that if I wanted the object they were holding in their hands and not through them the IK elf wasn't gonna be a great deal of help, for what I was doing. However, Mando's sermon has renewed my interest, easy is always good.

Bones work well from a side view (where the bone looks like an L), but from a birdseye they can be hard to manipulate, so switch to the roll manipulator. As far as movement limitations that's why I use the hinge analogy for sperical constraints you have to have movement along the main axis in order to have the side to side stuff, the constraint can move side to side but when it's at a 0 latitude position, you can of course fix this by adding another bone (the eternal answer) whose main axis of movement is side to side.

You can get around this limitation, by adding another bone directly above or below the existing one in the exact same position (the lowest of the two has to have all of the existing bones points associated with it), the only difference between the two is one's roll handle will be set 90 degrees away from the other's this way you can control the side to side movement as a main movement axis without altering the original bone's setup.

I've come upon an interesting, and not terribly involuted little trick for setting up arm constraints. Since I've had so much fun with it, I decided I'd share. None of this is constraints rocket science, but hopefully it's a combination that somebody won't have thought of before :)

For those who haven't seen my descriptions before, be warned: I give very detailed, very long descriptions.

First: * What You Do *

OK, basically you have a Bicep, Foream and Hand bone. These actually control the skin.

In addition to these you create two extra sets, positioned in exactly the same places:

Bicep Control, Forearm Control and Hand Control. Do NOT connect Forearm Control or Hand Control to their parents.

AND

Bicep Kinematic, Forearm Kinematic.

Finally, you create a top-level bone called Hand Target. This bone should be at the same level as the Pelvis, not a child of any of the body bones.

With me so far? Good.

In your default pose make the following constraints:

• Forearm Kinematic: Kinematic to Hand Target.
• Bicep Kinematic: Orient Like Bicep Control

In a seperate pose ("Arm connect"?) make the following constraints:

• Bicep:
  • Orient Like Bicep Control (100% at frame 0, 0% at frame 100, linear interpolation)
  • Orient Like Bicep Kinematic (0% at frame 0, 100% at frame 100, linear interpolation)
• Forearm:
  • Orient Like Forearm Control (100% at frame 0, 0% at frame 100, linear interpolation)
  • Orient Like Forearm Kinematic (0% at frame 0, 100% at frame 100, linear interpolation)
• Hand:
  • Orient Like Hand Control (100% at frame 0, 0% at frame 100, linear interpolation)
  • Orient Like Hand Target (0% at frame 0, 100% at frame 100, linear interpolation)

Hide every bone except the following:

• Bicep Control
• Forearm Control
• Hand Control
• Hand Target

Second: * Why You Do It *

[ Preface: Discussion assumes that you understand the basics of assigning a Kinematic Chain to a seperate target. If you don't, check out:

http://www.museoffire.com/Lyceum/Dojo/Tutorials/Anatomy/T0.htm

That's it for the preface ]

The first benefit is that you have an easy Pose-slider way to switch between Forward Kinematics (using the Control bones) and Inverse Kinematics. Slap the Arm Connect slider to 100% and you're fully inverse. Slap it to 0% and you're fully forward. Additionally, because the transition is handled by shifting Orient-like constraints, the movement between the two states is more natural and fluid than it is if you just ramp up the enforcement on a single kinematic constraint. Make sense?

The second benefit is in terms of usability. Those who have played around with controlling a Kinematic chain (and if you haven't, you should) will be familiar with the use of the "Thigh Target", or (in the case of arms) the "Elbow Target". This is a common way to control the middle joint in a Kinematic chain. However, it's "magnetic" attraction is very unintuitive, even for those who are experienced with it.

Well, the Elbow Target concept works on the fact that an Aim-At constraint on the Bicep will apply only within the limits of the Kinematic chain. Through careful experimentation, I have discovered that an Orient-Like constraint will do the same thing.

SO, through Orienting the Bicep Kinematic bone like the Bicep Control bone, you have a more direct way to control the motion of the elbow when you are moving the arm by way of its kinematic target. Just move the same bone that you would use to influence the elbow if you were using Forward Kinematics! The Bicep Kinematic bone will orient as close to the Bicep Control bone as it can within the limits of the Kinematic chain. Much more intuitive, IMHO.

Sorry if this got a little thick in the description... I tried to keep it down for a change. Hope this helps someone!

Tony Lower-Basch

I will attempt to answer this.

You CAN put a roll like constraint on a bone with a spherical limit constraint on it.

What you are trying to do is to make a parent bone (the forearm) roll like the child bone (the hand) The hand bone position is dependent on its parent bone, and yet you want to make the parent bone's position dependent upon the child bone's position at the same time. Is this starting to sound like a circle?

What I did when I was learning each constraint was to make a very simple cylinder model, and start applying different constraints on the 2 bones I added to the cylinder. I typed in the constraint values at their extremes and played with the bones in an action window until I understood the effect each constraint had. Maybe this would help you?

Lou De Marco

The problem doesn't actually have anything to do with the spherical limits. It's just that you can't control the rotation of the forearm bone with the hand bone at any time. Since the forearm bone controls the rotation of the hand bone (since the hand bone is perented to it) you'd get stuck in an infinit loop as the two bones would try to control each other, so the program sends an error rather then try to figure it out and crash. There's an easy workaround: Just create another bone that is a child of the forearm bone but has nothing to do with the hand bone, assign the arm points to it, and create your constraints there.

--Raf Anzovin

Assuming you're referring to the "Roll Handle", this statement is false. When a bone is pointed straight down with the handle pointing forward, Latitude will constrain the front to back movement, Longitude constrains the left to right movement, and Roll constrains Roll.

If you need an example, make a blank model with one bone, pointing downwards, with the handle pointing forward. Make a new action, and add a Spherical Constraint to the bone. Change all of the constraint values to zero. For the latitude, enter -20 into Latitude Minimum, and 20 into the Latitude Maximum field. Now from a side view, grab the end of the bone and move it. Movement is restricted as expected.

Jeff, Hash, Inc.

Just do a copy keyframe/paste keyframe with only the little handcuff button in the lower left corner depressed (as in pushed in, not sad).

David Fontes

Lock Offsets allows you to have your hand bone translate and orientlike say a gun bone. When you initially do this, the hand and gun will appear to be intersecting each other. You then move the hand to the position you want (handle and trigger). This is called Offsetting. Now you want to be able to move the the gun and have the hand follow realistically -- no slipping. That's where Lock Offsets comes in.

FWIW: With 7.1's Compensate turned on, you no longer have to set the offsets manually. You position the hand where you want on the gun handle, positioning fingers as desired. Then you select the hand bone, hit the compensate button, then do your Translate To and Orient Like constraints. You will now find that the hand is locked to the gun without the hand moving from your set up. No "Constraint Jumping" (those who've had this happen know what this means).

Oh yeah, and because these just generate offset channels, the animation is backwards compatible with v7.0. I just tried it.

I dunno what the store roll thing is except that it doesn't let me do my own roll, so I always turn it off.

-Armando Afre

I have not noticed any substantial slow-down when scrubbing through an animation, or when animating.

I -have- noticed substantial slow-downs with many bones (like 500+) in certain limited areas. If you rename a bone, change a bone's position in the hierarchy, or delete a bone, the system needs to resort its list of bones: in versions long past, this would take a longish period of time. I haven't tested it more recently, but I would imagine the same problems might recur.

-- Tony

Make a new model. Shift-drag the branch onto the new model name in the PWS. Delete the new model.

Regards, Myles - A:M dilettante.

If a model has 50 bones in it, any combination of the 50 can be put in different draw modes. Clicking the patriarch bone and shift-clicking the draw mode buttons will change the draw mode for all of the bones.

Jeff P.

Try this...select the root bone, shift-X, shift-X. This should put every bone in shaded mode and then every bone out of shaded mode.

Thom Falter

You remove CPs from the influence of one bone by assigning them to a different bone.

The only time that CPs are "unassigned" is before their first bone assignment, and even then they are technically children of the "Default Bone" (which you can see by going into Bones mode and clicking the icon of the model in the Program Workspace hierarchy list thingy)

-- Tony

If you hold down the shift key when you click the "Hide Bone" box, all of a bones children will be hidden as well.

-- Jeff, Hash, Inc.

It does precisely what it says...lets you scale, offset, and rotate a skeletal hierarchy (chain). So for instance you make the arm bones a certain length, but then decide to scale the arm mesh down in the modeller. By selecting the base bone (humerus) and entering the appropriate scale factor in the hierarchy tab, you can save yourself quite a bit of work. Also by checking the control points options, you wouldn't need to go back to the modeller - it scales the assigned control points as well.

There are small things to look out for though. Whenever you enter a value in the hierarchy panel and press enter, the return value becomes 0 (for some reason it doesn't go back to 100). If you have control points checked and this happens, you can end up with a pancake model and only realise when you rotate the view...

Also, if you're going to mirror parts of a model, for instance the legs, do all of this before assinging any control points. Funny things started to happen after constraining my model, and I'm assuming this was the cause.

Other than that, I use the hierarchy settings all the time to mirror bone chains such as the arms and legs from one side to the other (offset in X, and scale -100).

CL Audio

You could add a bone that starts at the base of the can, on the edge of the can that will always be in contact with the ground as it falls. Have this bone be at the top of any heirarchy you have, so it affects all CPs in the can. Use that bone to tip the can over. Have another bone, next in the heirarchy, right through the middle of the can. Use this bone to roll the can. (actually it might not matter which bone is topmost in the heirarchy, as long as both end up affecting all CPs.)

-David

The way I had done it in the passed versions (I'm not sure if it still works in v7) is to select, in your PWS, the parent bone of the heirarchy that you want to copy. CNTRL-Drag it to it's parent bone. If it's already the top of the heirarchy, drag it to the model name, this will create a duplicate heirarchy.

Not to gainsay this method (which is very good), but there is also a more comprehensive option available, particularly if you have many Poses of constraints which you want to maintain.

Create a copy of your model file (or save to a model file, if necessary). Open the copy and work in it. Remove all control points. Remove all bones that you don't want copies of. Use the "Hierarchy" tab of the bone property on the top bone to scale/reflect the hierarchy.

Now you've got a set of bones with the original names, in the new position, in a seperate file. If you rename bones (like from "Right Thigh" to "Left Thigh") this will effect the channels in the poses as well. Rename all your bones.

Import this model into your original model. This will create the new hierarchy, but will not (I think... could be wrong) import the poses. Assign CPs to the bones as needed.

Open both models in a project. Drag new poses into the old poses (with Constraints-button set on the frame bar) in order to add the constraints. You should end up with poses which contain constraints on both hierarchies.

Complicated, but very thorough. Hope this helps!

-- Tony

Open the bones in the PWS find the highest bone on the left arm branch, hold down control then click and drag it up to that bone's parent (torso or whatever) then drop it there and it should make a new branch in the same positions with the name's incremented by 1, then you can go into either position or hierarchy on the branch's patriarch (Lshldr2?) and make the x plusses minuses.

Matt Andersen

This is correct. The draw modes on the model or action properties panel are Bones draw modes that affect the default model bone. Therefore, if you've taken a model and assigned all of the control points to another bone, the model bone has no geometry associated with it that will shade. If you wish to change the draw mode of a model, pick a bone in the Project Workspace and then select the draw mode you wish to use.

Jeff, Hash, Inc.

On the 'Frames' toolbar, there are keyframe filters for things like Translate, Scale, Rotate, Constraints, Muscle ....

If you only want to key a translation, make sure only the Translate button is depressed. When you select a bone and make a keyframe, only translation data will be saved.

These filters also affect Copy/Paste commands, so that if you already have a bone with lots of data, and you want to COPY only translation, set the filters as described above, then copy.

Also, to the right of these filters are 3 buttons that adjust how far your keyframes [or copy commands] reach: Key Bone, Key Branch, or Key Skeleton [I may have the exact names wrong, but check *any* Hash manual for info on all these filters].

James Poulakos

If you don't need IK from the object to the actor, constrain object to actor, and, increase constraints to 100%, to pick up object and decrease to 0% to let go.

If you want the object's movements to cause the actor to move, you can constrain the actor to the object, again use 0%-100%-0% at appropriate frames.

Or you can have twin actors, one with the object as a child, and one with the object separate, and swap the twins at the appropriate frames I hope this helps.

Ken W

You can only associate a control point with one bone. However, you can constrain a bone to be influenced by the movement of two other bones. Mainly when people talk about blended constraints, they're talking about using identical constraints on a single bone with seperate target bones and varied percentages which usually add up to 100. Example, Thigh bone is the parent of the knee bone, but there is a knee2 bone whose base and orientation is identical to knee however the tip only goes about halfway down the length of the knee bone, knee 2 is also a child of thigh but not part of the branch that knee is on. So you have points associated with thigh, and the points associated with knee, but the uppermost ring of these gets associated to knee2. Thigh and knee bones will be directly manipulated to edit orientation, but knee2 will probaly be invisible and oriented by constraints.

Thigh
    Knee
        Ankle
            Foot
                Toe
    Knee2
        orient like Thigh 50%
        orient like Knee 50%

That's an example of a blended constraint, if you still don't understand then make one, doing is the best learning. Good luck.

Matt Andersen

A way to do it that is a little rough would be to copy the keyframe at frame 10, paste it at frame 15, and then delete the keyframe at frame 10.

You could do this easily in the channel window. Open a channel window, drag and drop from the PWS action the bones into the channel window, then use the group tool to select the keys and slide them to the desired position. You can even filter out a specific transformation set, meaning that you could drop all of the translation channels and only manipulate those in the channel window. Hope I'm making sense.

CL Audio

The points you associate with a bone move with a bone. You don't need to tell the software which control points move at a joint because splines stretch and rotate appropriately (or with little adjustment, like a 45 degree angle spline at the knee or elbow).

Jeff, Hash, Inc.

Under the properties of the bone, there is a check box; "hide bone" If you hold down the shift key while you hit toggle it, all the bones underneath it in the hierarchy will hide as well.

Matt

The basic answer to what you need to do, for the effect you want with minimal changes, is this: Create a bone in the Shield object. Place that bone at the right handle. Constrain the right hand to that bone. That will place the right hand at the correct handle, and when the shield moves the hand will follow.

On a more general note, I think you may be making a mistake by deriving the shield's motion from the left hand. Personally, I would do the following:

• Place the Default bone of the shield in the same position as the torso of your character. Make sure that the roll handles are in matching orientations.
• Create a "Shield Movement" bone which runs up the long center of the shield. You probably want its roll handle pointing outward.
• Create a Left-handle and Right-handle bone, both children of the Shield movement bone. Place them at the appropriate handles.
• Bring the shield into the same choreography with your character (or Action Objects if you prefer). Constrain the shield object itself to Translate-to and orient-like the torso bone.
• Constrain the Left hand to kinematic to the left handle.
• Constrain the right hand to kinematic to the right handle.

Once you have this setup, you can move the -shield- in order to move the arms into appropriate positions. However, the shield still follows the movement of the main torso. I think you'll find that this setup makes the animation easier and the results more natural.

-- Tony

Just select the patriarch bone (the parent bone of the entire skeleton) and scale it with the scale manipulator.

My only suggestion would be to get the latest beta and use it. I started using constraints intensively in beta 15, and I haven't looked back since. The betas are extremely stable. (Of course there are some glitches) I have never experienced the problem you're describing -- and I've got quite a few aim ats, aim role ats, orient likes, kinematics, what-have-you. I've got them constrained to bones on the model proper and to bones on other models, I've got their enforcements set anywhere from 100% to 0% upon switching from the model's own puppeteer constraints to that of another model (i.e. grabbing something, or someone else in mid animation).

The only problem I had was constraining stuff in Action Objects where the bone would want to adhere to some completely different bone. This is just the proximity of the bones to each other within the Action. To solve this, I select the bone in question, set the constraint but to no bone in particular, then go into the properties panel, select shortcut to the model in question, then scroll down the bone menu until the desired bone is selectable.

-Armando Afre PixelShop(TM)

The answer is... don't allow it to get left behind.

Generally, I will move the Master bone whenever I want to move or rotate the pelvis in the horizontal plane. That way, it's harder to accidentally lose synchonization.

Also, this lets you more easily deal with the horizontal (Patriach) and vertical (Pelvis) motions as seperate issues. Very useful for calculating conservation of momentum.

-- Tony

The problem is: regardless of where the thigh bone's roll is pointing when you model it, if the thigh's Aim Roll At bone is in front of it, it's going to aim the roll to the Aim Roll At (to the front).

If you put the Aim Roll At bone in the rear of the thigh, you'll run into all sorts of problems when you extend the knee too far outward and the Aim Roll At gets too close to the thigh and flips it.

I'd suggest aiming the Calf bone's Roll forward to match the thigh (and knee smoother you have?). I had aimed the Calf's back as a holdover from how Spherical Contraints prefer the Roll. But because I use IK and puppeteer bones for animation, the Roll can be front or back. Doesn't matter. The only time the roll matters with my setup is when you have it aimed at an Aim Roll At. I just confirmed this by twisting the calf's Roll 180 degrees forward, and redoing the constraints.

Took about 30 seconds to redo.

Also, instead of adding a seperate knee bone to smooth the bend, try rotating the calf and foot 90 degrees in Model, then adjust gamma and alpha to how it should look when bent. Then rotate back to original position and see if it looks okay. Then you'll get a smooth bend without the need for an extra bone.

-Armando Afre PixelShop(TM)

First off, I don't use spherical constraints. I use complete IK from the first joint, (or thigh on a humanoid) down to the foot. But my constraints are in reverse. I have a bone (called ToeGrab) at the edge of the foot (not within the skeleton), that I kinematically constrain the tip of the foot to. Then I have children of this kinematic bone called aim at bones, that are children of the kinematic bone at every joint in the leg. between foot and toe, heel knee, etc. (it's like a null, only I don't use nulls because I had probs with them in v.5. Using floating bones as nulls works the same).

Now when I want to move the leg, I grab the kinematic ToeGrab bone and put it where I want. The leg follows as far as it can go without separating from the torso. I copy that bone's position, and paste it on the very next frame. Same thing in reverse. Two keys, one frame after the other, right before the leg leaves the ground. This ensures no Channel drift from the time the leg is planted to the time it leaves the ground.

You could aleviate the foot slippage in channels with either bias adjustment or zero slope, or peaked curves, but it is much faster for me to just "double key" the foot when I want it to stay planted.

I only copy the kinematic ToeGrab bones placement key, so that I am free to position the heal, and knee however I desire to compensate for the motion of the torso and such. This way you can get the desired channel drift on joints without worry of channel drift on the foot.

I also hide the actual leg skeleton, and only manipulate the joint by way of the aim at bones which are children of the ToeGrab bone. These act as virtual puppeteer handles for the bones.

It should be noted that the ToeGrab and all its children are in their own hierarchy, seperate from the model. This way, you can move the skeleton without disrupting the positon of the feet.

-Armando Afre PixelShop(TM)

I didn't understand this the first time you asked. The leg chain isn't seperate from the hip. Only the ToeGrab constraint and its aim at children.

Since the thigh is a child of the hip, the leg would shift its weight naturally. The foot would remain where it is because it is constrained to the ToeGrab. After the leg shifts its weight, you would further fine tune the position of the knee and heel by adjusting the Aim Ats (which would look like little foating bones near the jointed areas). Those are children of the Toegrab. Because they are Aim Ats, the joints will aim at them only as far as the kinematics allow. No joints will be broken.

To clarify, the leg's skeleton IK is the child of the hip. But the foot is constrained to the ToeGrab, which is in its own hieararchy (foot a child of the calf. ToeGrab the parent of its own hierarchy).

I guess it would be like attaching your foot to a tightly wound coil of fishing wire. Its tensile strength would be tuned to hold the foot in place until such a time as the resistence from the hip would be such that it would rip your foot off. At that time, the reel would unwide only enough to avoid such mutilation.

You pull the body far enough away from the fishing coil, the foot would be allowed to move away from the coil, but there would be this line of tight fishing wire from the coil to the foot. This line of fishing wire would suspend the whole leg, held by the foot, aiming the leg exactly to the ToeGrab (fishing coil).

-Armando Afre PixelShop(TM)

There isn't a hide bone setting for the defaulted "black bone." All other bones that you add yourself will have the checkbox to "hide bone." Generally, it's a good idea to leave this bone alone, until you get a full understanding of bones, the "black bone" is the reference for how the model's bounding box will display in the cho window.

Jeff C.

Yup. Select your model's name in the Project Workspace, which selects the default bone. Now click on the translate manipulator button (or just hit "t" I think) and move it that way - all the bones under the default bone in the heirarchy will move with it. (If you hold down Ctrl while doing this, the associated CP's go with it all too.)

David Fontes

      +--------------------+
      |        b           |c
      |a                   +--    front view
      |                     d

Try this. Forget about spherical constraints. Add a floating bone in its own hierarchy right above A. Make A aim at this floating bone. Add another floating bone in its own hierarchy behind A (or wherever A's Roll is aimed). Make A aim roll at this floating bone. Now whenever you move the second floating bone, A will twist.

Add a bone that is the child of A. Put it right next to A, but make it point down. Make C orient like this bone, then hide this bone.

Once you have all these constraints set up, hide A altogether. You don't need to directly manipulate it anymore, since the Aim Roll At bone and the Aim At bone take care of this.

-Armando Afre PixelShop(TM)

Constrain Bone C to Aim-Like-Two: Bone A, Bone B (or maybe in the opposite order... I forget).

Alternately, you can just create a new Bone called 'A reverser' that is a child of A, with its base at the tip of Bone A, and with an Aim-At Bone A constraint, then Orient-Like Bone C to the Reverser. Whatever makes you more comfortable.

Unless I'm much mistaken, it won't really matter if Bone A itself rolls around its axis: it's the CPs attached to Bone A that you want to have move, right?

To accomplish that, just create a new Bone called "A-Faker" (or whatever). Make sure that it is not a child of A (maybe a sibling, or maybe at some totally different level of the hierarchy). Constrain it to Translate To Bone A, Orient-Like Bone A, and Aim Roll At Bone C.

Because "A-Faker" is completey disconnected from the hierarchy, it will not cause a Circular constraint. But because of the various constraints, it will always behave exactly as a hypothetical Bone A that could be Roll constrained would behave. Connect the CPs that you want to roll on Bone A to Bone "A-Faker" instead, and you should be set.

-- Tony

Gary, I've used a similar setup for a snake and for long tails, but instead of using 3 heiarchies, I used 2 with the second (control) being one for every 3 skeletal bones...

   s1    s2    s3    s4    s5    s6   s7    s8    s9
<-----<-----<-----<-----<-----<-----<-----<-----<-----
         C1                C2               C3
<-----------------<-----------------<-----------------

Then each bone get's orient-like constraints. Most of them get 2. S1 orientLike C1 50% -- This is a unique bone because it's at the end. s2, s5, s8 orientLike C1, C2, C3 respectively, each at 100% because they align to the middle of the control bone and therefore stay parallel to the control bone.

s3 OL C1 65%
s3 OL C2 35%

These constraints are broken into thirds as the Skeletal bone should be influenced by the control bone 2/3s to 1/3

s4 OL C1 35%
s4 OL C2 65%

s6 OL C2 65%
s6 OL C3 35%

S7 OL C2 35%
S7 OL C3 65%

etc....

This setup results in very smooth curving IK chains without kinks! It's also easy to override with FK offsets if you need extreme bends in certain areas.

Hope this can help someone!

Tommy D'Aquino

look in the channels of the roll like constraint, in 6.1. you will find a channel called roll scale.

S.A.Y.

Yeah, it's pretty cool - if you put negative numbers in, the bone rotates in the opposite direction! Great for gears and such...

Ted

If you are using V6 or V6.1, open the bones window, click on the model's name on the PWS to see the default blackbone. This is the bone that the cho uses to draw the bounding box, it's orientation and pivot point for rotation. You normally see it in the cho window (directing mode) as the yellow bone with the yellow bonding box around the CPs.

Take notice when making a new model that the blackbone keeps updating itself so that the wide end starts at X=0, Y=0 and the tip of the bone faces forward and extends to the farthest CP at the front, the roll handle will extend all the way up to the height of the top-most CP. *Once* you move or adjust the blackbone, the program assumes you know what you're doing and does not automatically update the blackbone anymore.

This is from my own observation and may not be official data... BTW, the bounding box is *not* all wrong, the program actually followed your instructions! LOL My word to the wise is, for 9 out of 10 models you never have to touch the blackbone.

Jeff C.

Say you heirarchy looks like this:

   Hand
     Finger1
       Finger2
         Finger3

Grab Finger1 in the Project Workspace, hold down Ctrl and drag it on top of Hand. This will duplicate the structure, but it will be in the exact same location as the original bones. To move the whole chain select the base bone (it'll probably be called Finger4 in this example), hit the translate manipulator and drag it to the desired location.

I hope this is correct, I'm not writing from my A:M computer so I can't double check, but I'm pretty sure that's the way it works (for PC, anyway.)

David Fontes

Actually, in the case that David was illustrating, it would be better to negate all of the bones' X values so that the new hierarchy would be mirrored across the X axis instead of just translated

lemme splain a bit clearer (I hope)

using his example, lets say Finger 1's properties dialogue says

Start Pos          End Pos
   -15.5            -17.2
   10.56             3.99
       0                0

This would be the position/orientation of one bone, "Finger1" on the left side of the screen (note: the first values, the X values are negative denotes the bone is on the left side)

Now, if you duplicate the hierarchy by doing what Dave says and CNTRL-drag that over the branch's parent, Finger4 is the initial bone you'll want to translate (mirror) so that it's on the right side of the screen. Change the start and end X values in the property dialogue and it will flip across the X axis. You'll see that it's child is still connected and stretched across the screen. Switch it's end X value, along with the children throughout the branch and it seemlessly mirrors the bone structure.

-Tommy DAQ

Alternately, in the newer betas, there is a Hierarchy tab on the property dialog for the bones, where you can enter in an X-scale of -100, to perfectly flip an entire hierarchy of bones. Just like scaling CPs.

-- Tony

One thing that I've learned from way-old tutorials (back in V4 days) is that it can be important to -rotate- your bones in modelling mode before applying your constraints?

OK, is everyone confused now?

Long explanation follows.

Here's the basic thing. If you apply a minor longitude range (like -10 to 10), you create a wedge of a sphere in which the bone can move, right? This wedge is widest at the point of zero latitude, and narrows down to points at -90 and 90 latitude.

With me so far?

So, if you wanted to simulate a knee (which I believe was under discussion) you want to have no longitude movement when the knee is fully extended, no longitude movement when the knee is folded against the buttocks (I know you think you can longitude the knee in that position, but it's hip-roll... trust me) and the maximum amount of longitudinal movement when the knee is 90 degrees bent.

If you visualize this, you can see that it is a wedge of a sphere. The trick is, the wide section of the sphere is behind the knee, in the position that the bone will point at when the knee is bent 90 degrees.

If you model the character with their feet on the ground, then the 0 latitude position will be with the knee fully extended. That means that there is no way to create a Spherical Constraint that will apply this range of motion.

If, however, in modelling, you rotate the knee so that it is 90 degrees bent, THEN the zero-latitude position is with the knee at 90. If you create spherical constraints with Longitude -10 to 10, and latitude -90 to 90, the knee will have some longitudinal range when it is 90 degrees bent, and no range when it is fully folded or fully extended. Just like we were aiming for, neh?

Then, you just make a default pose that bends the knees back to the position you will most likely want them in. Simple, yes?

This can also help with constraining the Elbows... you bend them to a 90 as well, which will end up with the forearms pointed directly forward. Again, this allows you to construct a range of motion that would not be possible if the arms were modelled directly out to the sides.

Generally, I actually model with the feet on the ground until I'm ready to start constraining, and then bend the limbs as a final step. It's just so much easier to get all of the proportions correct in the classic "Leonard DaVinci" pose, that it's not worth the bother of doing the change until the last minute.

-- Tony

I forgot who mentioned this on the list. But there was some talk about it on IRC last week. I was saying that the constraints offsets were something new as per what Jeff Paries told me. Steph and Scott said they were from v.5.

Well I got it wrong and didn't know what Jeff P. was talking about. Here's the deal. Instead of having to make a special grab bones for the trigger handle and barrel, (I'll use the example of a guy holding a rifle) then setting your constraints to grab that (kinematic on forearm, translate to, and orient like on the hand), you now only have to have one bone for the gun. Set up your kinematic constraints for both forearms to the gun bone. Set up your translate to and orient like on the hands to the same gun bone.

It's gonna look screwy at first, but you then go about offsetting your hands and forearms into your desired position, just like v.5 had all along. However, in the beta, you check that little Lock Offsets box after your done positioning your guy to properly hold the gun. With that checked, your offsets are locked in the position you've set so you don't accidently move them when you're animating. With just one gun bone, both hands will stay in their perfect complex position no matter how you orient or translate the gun.

This is fantastic! You can now have models grab all sorts of complex objects without having to make special bones for just thos situations. That Row project I gave you guys? Old news. You can do the same thing with just that long bone in the handle of the oar. Forget about grab bones. =)

Now if somebody could tell me what the Store Roll check box is for...

-Armando Afre

when i read jim's example on how he gets his coordinates it made me think about how i get my numbers.

basically, breaking down the sphere into quarters(90deg) is not too difficult for most people to do visually. it then just becomes a matter of further sudividing that region which you range falls in. from the minimum position to a quarter turn produces a right angle, perpedicular lines. now if you can see that then it's a small step away from being able to visually see half of that, and so on. you just add the ranges together, if it helps to point your finger at the screen or use some kind of marker, then do. i don't try to hit the nail on the head the first time, just get in the ball park. this is not unlike the grid system used in drawing.

Also, most of my confusion came from from forgetting that latitude values are often half of what i thought they might be, depending on the kind of range i wanted. this is because if the longitude has a range of 360deg, a latitude value of 10deg appears to be 20. this is because from the zero point, the bone can move 10deg, but in all directions. so what you end with is 10deg back to back effectively doubling the target range. this becomes more apparent when you start to limit the longitude. furthermore, when you start to limit the longitude it becomes more importsnt to have a good grasp of negative values, where they are on the sphere and how to calcuate them. a longitude with settings of -30 to 30 is a total value of 60. positive and negative are just locations on the sphere relative to zero. remember where you are relative to zero helps alot, again use markers if you have to. by default spherical constraints are broken down into two 180 deg hemisheres, one positive one neagtive. totalling in a longitudinal range of 360degs. there is a tricky part where a location can be defined by two different numbers(ie. -90 is the same as 270, it just depends on which direction you travel from zero) there are occasions where this comes up. spherical constraints don't have to be complicated but they can be. i haven,t had much need to do that kind of fancy calculating. alot of headache can be avoided just by making sure your bones are all the way they should be before you get to the constraints.

S.A.Y.

here's one last stab at an analogy. picture the earth as a big spherical pie. latitude is the direction the knife travels from pole to pole to slice thru it. longitude is how big a slice.

Ok, here is my 2 cents on Constraints. I spent most of today boning and constraining my insect creature. I found an easy way to make spherical constraints a little easier.

1. create a new pose and name it constraints and create a new action
2. in the pose window select each bone and then right click to add spherical constraint. Do this for every bone first
3. drag the constraint pose to the action window
4. in the action folder expand all everything, so that you can see the constraints
5. select each bone and move it beyond where it should go. now it's just a matter of entering numbers until the latitude constraint is correct. Repeat this process to figure out the longitude constraints. What happens is this. When you enter a lower constraint value for the latitude, it move that bone.
6. test your constrainted limb and make sure it is the way you want it.
7. write down the constraint values and enter them in the Constraint pose. Now you have a pose which has all the constraints. when you want to create a new action, you simply drag it to a new action window and start moving your creature.

Walla, a quick easy way to do spherical constraints without pulling your hair out. Well I almost pulled my hair out, but patience kept me from going bald. Once I get spherical constraint and aim at constraints working in tandem, I'll be ready to animte the creature. I hope that helps.

Peter lin

Just one final brief explanation with the above setup. You can raise the heel aim at target a little so its like you're on the balls of your feet. Then all you gotta do is orient the kinematic foot target back and forth, and you've got your character doing the Chubby Checker twist without having to worry about the thigh and calf. You want your character to get back down on his whole foot, you push the knee aim at in toward the thigh, and your guy's putting his whole weight on its foot. And you don't necessarily have to adjust the heel target becuase the IK skeletal setup will push the heel farther down than the heel aim at bone is.

It's like the skeleton knows just how far your aim ats need to be, but not so much that they screw up your IK. I used to be an FK advocate. But I just recently discovered as long as you don't touch your IK, hide them and, only move the aim at targets and such, moving your character around is almost like playing a video game. It's easy, you can move the body around and don't have to reposion like the arms back to their previous position to get that overlap effect.

With a proper IK setup (spherical constraints excluded -- at least for me), animation is orders of magnitude easier, more precise, WAY less time consuming, and just plain old much more fun, than doing it ala FK.

Sorry for my digression.

*soapbox mode off*

-Armando Afre

I don't. I use bones for all my aim at, aim role at, orient like, etc constraints.

I always thought nulls were harder to select.

I had some problems with nulls way back in v.5. I'm sure nulls work now, but floating bones either in their own hierarchy or part of the skeleton works great. So since I got a good thing going with bones. I don't wanna rock my boat by touching nulls.

What I do is make almost everything IK (attached to parent) then make floating bones for like ElbowRightTarget, etc. The trick for me with IK, is that if I decide to go IK, then I gotta set up target bones so that I never acutally touch the IK bones.

I hide like 95 percent of my kinematic skeleton, never touching them or seeing them again thoughout the piece, and animate with the target bones alone. It helps to hide the skeletal bones right after you've set your constraints so that you don't accidentally move one of them when you animate and screw up your constraints. Its like virtual string puppets.

-Armando Afre

Let me think out loud. Suppose you make a 3-point (or more) spline, make 3 bones, each will have one point. Then you make that 3-point spline follow your spline-path. This sounds not to hard. But what has it got to do with what you wanted to do? Well, take the bones of your banner, and use the path constraint to attach them to the 3-point spline. That way you only have to worry about 3 bones, while still having that snaky movement. I've got no idea if this works at all, but it might be worth a try.

Francis

You're almost there. You can save one step: the dropping of the pose onto the first frame.

Create the pose. In the pose, you'll have the default constraints [as well as the stance]. Since it's a pose, it saves with the model.

For those folks who have already set up constraints in an Action: look under the Action menu. There's a command for you, called "Create Pose".

OK, you've made your pose, and it now appears under the Model in the PWS. You probably want to give it a name, since it probably is called "Pose 1" ....

No matter what you name it, you can set your Model to default to this pose. Click the Model in the PWS. Look on the Properties panel. See the long, white rectangular field labeled "Clear Actions With Pose"? Pull that field down [it's a drop-down list] and you'll see all the character's current poses. Select your default pose and save the model.

From now on, when you start a fresh Action with this model, it will assume the pose you've selected.

It's very handy for loading up those common constraints you know you'll want most often, such as the Right Thigh's Aim At Right Thigh Target......

James Poulakos

It sounds like you want to dynamically change the characters movement along a path, also know as eyeballing it? If this is what you want to do set your end keyframe for the ease, then open the percentage channel for the path constraint and move the end keyframe control point up and down, if you want the character to be at a certain point along the path at a certain keyframe add a control point at that frame change your choreography window to that frame and nudge the point up and down in the channel window, you may have to refresh the choreography window to see positional changes. This is the AM way of producing the result you're talking about.

Matt Andersen

Poses are saved with the model data. So if a model is saved with a pose and that pose is set as the "clear action with pose," that will be the opening position for any "new" action or if you choose to clear an old action. The bicep model prolly had the pose in there, and your new model, of course, didn't (not until you make a pose and then set it as the pose to use for clear actions).

Jeff C.

Did you have the right keyframe buttons pressed when you made the pose? Were the right keyframe buttons pressed when you dropped the pose?

Open up the pose and then expand the channels under the bones you moved in the pose. You're looking for anything ending in orient (x,y,z and roll), if you don't have these channels you've basically got an empty pose so you'll have to make a new one, make sure your rotate keyframe filter is pushed down. If you have the orient channels you're probaly just filtering the pose out when you drop it into the action (window), that's the rotate keyframe filter again. The keyframe filters can be your friend or your enemy, so make sure and check them regularly, I generally filter everything except constraint, rotate and translate, unless I need the other things. Hope this helps.

Matt Andersen

Euler (pronounced "Oiler") is a little too complex to explain without diagrams, but may well result in smoother motion because of the way it interpolates angles.

When you specify a vector, you're basically "pointing" a bone. A vector angle of 0,0,-100 tells a bone to point at -100 Z. So, the interpolation between two vector angles can get a little choppy depending on the movement.

Jeff, Hash, Inc.

All I know is I had to change a bunch of my gek's bones to vector because if I bent like the wrist more than 90 degrees, the roll twisted 180, flipping the hand. Making it vector changed this.

Steph mentioned something like Eular keeps the X,Y,Z a constant 90 degrees from each other, and that it was a combo of these three coordinates that determin the roll. Or something like that. He also said the bones shouldn't have flipped in Eular when I bent it more than 90. Go figure.

I think that in my case, changing back to vector, which added the roll channel, fixed my prob because I wasn't directly touching the roll handle. But I'm not sure. This stuff makes my head hurt.

Anyway, Steph said that if my bones rolled like they did in Eular, that it was probably a bug.

-Armando Afre

Sure. No problem. Just turn the bone around.

Specifically, you want a bone just for the piston. This bone's Base will be at the point where the bone connects to the knee. The bones Tip will be at the point where the bone slides into the piston sleeve.

Secondly, you'll want a target for said bone. That target should be way back at the base of the sleeve.

Then constrain your piston bone to Aim-At the target at the base of the sleeve. It will translate back and forth as the knee bends, but it will keep aimed at the sleeve (and therefore presumably look like it's sliding in and out of the sleeve).

If the piston moves side-to-side enough that it's penetrating the sleeve wall then you'll need to move the sleeve too. Add a third bone for the sleeve, with its base at the target bone, and its tip at the edge of the sleeve. Constrain that bone to Aim-At the piston bone. Then, as the piston angles side-to-side, the sleeve will move with it.

Hrm... this one is fairly simple, but not exactly intuitive. Maybe I should write it up as an Exsplination....

-- Tony

I agree with Yves on this. I do this on any model for which I want semi- realistic arm motion.

However, there's an additional ancient secret that might help people. I can't claim to have invented this: I just read it in the V4 manual, and remembered it.

Sometimes it is best to bend your model into a certain position in the *model* window (by CTRL-rotating the bones), and then undo all of this motion in the *pose* window when you create your default pose.

To get the position I'm talking about, take the standard "feet together, hands straight out, palms down" position that's easy to model, and then do two things:

1. Bend the elbows ninety degrees so that the fingers point straight forward
2. Bend the knees ninety degrees so that the heels point straight back

Why? Simple: That puts the bones into the very center of their legal swaths of movement. This means that you can constrain their latitude to "90 to -90", rather than "0 to 180". Why does this matter? Because if you allow any longitudinal movement, the range of motion is different for the two cases.

In the "0 to 180" case, the longitudinal range is essentially unchanged by the movement of the latitude (for reasons of Constraint-sphere interpolation that are too detailed to delve into here). The result is that the character can (for example) bend their elbow up and down even when the hands are extended out to the sides. If you test this yourself, you'll see that this is not physically possible.

If, on the other hand, the latitude is restricted to "-90 to 90", the effective movement at the "-90" and "90" areas is very limited (because the longitudinal movement is not a major factor at the poles of the sphere), but the longitudinal movement at the middle of the bend is still wide open. This more accurately simulates the ways in which such joints move.

This may not sound like a big deal, but I assure you that it can have a serious effect on how good the Inverse Kinematics looks. The more accurate the constraint information you give, the better a solution the IK engine can come up with.

-- Tony

There isn't really any distinguished category in the program for "Patriarch". It all comes out of the fact that, in the Action module, moving a bone will move all of its children. So, whichever bone has all of the other bones as descendants (children, or children of children) can be used to move the whole model.

While any patriarch bone must be at the top level of the hierarchy, it does not follow that any bone at the top level of the hierarchy will automatically move ALL bones in the hierarchy. You could have several bones at the top level, each with their own distinct set of descendants. This would be useful when, for example, you want to combine several people into one model (a "crowd" model, for instance) for whatever reason.

Yes, although this would be an extraordinarily bad idea. Studies of motion make it clear that almost all motion in almost all creatures on earth has its main origin in the hips/pelvis. Motion which originates in a different part of the body has a tendency to look "floaty".

The only time I would imagine having the pelvis as a child of another bone would be if you set up a specific hierarchy to deal with a specialized situation of Inverse Kinematics. If you want to hang your character by the neck until dead, it might make sense to have their head (or neck at least) be the highest level of the hierarchy, and have the torso through to the pelvis be a child chain off of that.

Maybe. I'd recommend, at the least, looking over some of the models on the CD. PuttyDude is a good example. It uses the Pelvis as the patriarch of the bones hierarchy, and does quite a good job.

However, Jeff Lew has recently made a recommendation that has been taken to heart by the martial arts groupies, which is to add a patriarch distinct from the pelvis. This has a few benefits, the most major of them being the easy ability to move the character through rolls and falls by rotating the patriarch smoothly.

Yes, you can only have one bone formally "Attached". However, a bone does not need to be attached in order to inherit the movement of its parent. Any child bone will move when its parent moves.

The only thing that attaching the bone does is help with Inverse Kinematics. If you move an attached child bone, it can cause the parent bone to move (to maintain the attachment). If you move an unattached child bone, it will just drift away from the parent (although it will still inherit the parent's movement... just with an offset).

The leg bones should not be attached to the pelvis: the first bone of your torso should be attached to the pelvis. The leg bones should be children, but there is no need (in general animation: again specialized cases abound) to have the movement of the legs force movement in the pelvis.

-- Tony

I'll take a crack. I think what you want to do is make all the vertical splines that make up your banner associated to bones, probaly oriented vertically from the bottom of the banner to the top with the roll handles parallel to the plane of the banner. Here's the important part, all of these bones need to be at the same hierarchy level, so you'll have the black bone then all of these bones on the next lowest level. Then you just put it in a choreography, create a path, and go into skeletal mode and add path constraints to each of these bones, and vary their ease channels to get the banner back into the proportions at which you created it, then just adjust the ease proportionally on all of the bones and make sure on your path constraints that roll orientation is allowed. This should allow you to move the banner along a path with each vertical spline exactly following the path for a serpentine sort of movement. I haven't tested this, but this would be the first thing I would try, hope it helps.

Matt Andersen

The overloaded wave action should be added last. Make sure that there are ONLY channels for the hand and arm that are waving. If your whole body has channels (even there is no motion the eye can see, like in the case of 'make keyframe' with whole body checked) then they will overwrite the walk action. If that's the case go into the wave action and delete all channel icons for any bone other than arm and hand that wave.

Glen

That's the best way, other than making an entire single action exactly the way you want from your poses.

Make a very very short path. Microscopic. I wouldn't use stride length in this case, though.

Actually, AM is the only app I know of that allows you to do this so easy! Actions as separate files that are stackable and overloadable is more powerful than the options I had in Alias, for example. It would be cool to be able to set a number of repeats/cycles of the action as well as the existing properties it already has. It would be a cool refinement to speed up the users workflow, but we can do it now even if it means dragging 47 actions into your CHO.

If you're talking about rotation like a airplane propeller you can use a bone's roll channel and enter in degree's. Make sure you have the bone pointed at right angles to the turning blades.

If it repeats from a starting point for the rest of the scene you can make one "cycle" then hit the repeat button in the channels properties for each needed channel.

Glen Crowell

Yeah, I can do that. I used to think it wasn't possible in Hash, but then I noticed a sleazy little trick that you can play.

Make Bone A with its base at (0,0,0) and its tip at (0,1,0), for example. Make Bone B with its base at (0,1,0) and its tip at (0,0,0). In overhead view, make sure that the roll handles are facing in the same direction.

Constrain Bone B to "Roll Like" Bone A. Roll Bone A to the left (again, in overhead view, in an action or pose) and watch Bone B roll to the right. Sleazy, eh?

Now, since you don't want to do everything with Roll handles (they're a pain) add Bone C, with its base at (0,0,0) and parallel to the Roll handle of Bone A. This will be your control bone. When you drag to turn it left and right, Bone A will roll left and right.

How? Simple. Add Bone D as a child of Bone C. Make it's base connect to Bone C's tip. Hide Bone D (you'll never have to think about it again). Constrain Bone A to "Aim Roll At" Bone D. The Roll handle will now match the movements of Bone C (since it's pointing at a bone that is always at the tip of Bone C). I generally call Bone D something like "Bone C Tip", just so that it's easy to pick out when constraining.

Note that this bone configuration will not copy any movements of Bone C which are not in the axis of the Roll handle's movement. This may be good, it may be bad, it all depends on the effect that you want.

-- Tony

The "euler and vector" refer to the kind of representation of rotation values in the Properties panel. I haven't downloaded beyond V6.0d, but I assume there should also be spherical as an option. Now, please don't get me wrong...I've appreciated all the talk and tutorials about spherical constraints that AM users have put forth, but they mean nothing when you are faced with editing the rotation curves in the channel editor: the channel editor only displays rotation data in vector format.

If you haven't used vectors before, my way of dealing with this is to only to deal with one bone at a time and to imagine the bone is 100 units long (that is basis for the values that the channel x, y, and z uses for it's 'unit' length (don't worry about that if it seems cryptic)).

If you ever had 2D geometry, you know the diagonal side (hypotenuse or 2D bone) of a right triangle in equal to the square root of the product of the squares of the other two sides. That is, h = sqrt(x*x + y*y).

In the 3D world of our beloved AM98, the added third dimension changes the equation to

100-unit-long-3D-bone = sqrt(x*x + y*y + z*z)

So the numbers for rotation values in the channel window are the x, y and z of the immediately above. This doesn't seem to be so practical until you relate these x, y, and z's to the bone as defined and oriented in the bone mode of the modeler. The channel window rotation data represents the change in tip (small end of the bone) of the bone's rotation in the x, y, and z values relative to the bone's original orientation and keeping the bone's length at 100 units.

Jeff Watson

Yeah this is for bone interpolation, which affects the available channels. Default settings are Euler interpolation for the black bone and vector for all the lower bones. The difference between the two is that euler is defined by only three channels x, y, and z orientation, it does not have a roll channel, vector does, and Euler is a great deal easier to do things like make something spin (it supports numbers above 180 in the channels but they have to be entered in the channels or it rounds down) and on the whole is much easier to conceptualize the affect your channel tweaks will have without visual feedback, I may be slow but I still don't know what the heck the deal is with vector you seem to have redundant axes (2 orientation channels seem to control the same orientation) and numbers over 100 don't have the same affect as the same slope would have if it was under 100. Neither is absolutely better for everything, there are some situations where either type won't bend to your will, which is why you have the option of changing the interpolation type, globally or locally (the properties box for any given bone). Between the two types I've been able to do everything I wanted to, personally I would say the default settings are probaly best left as they are, you can always change types if you're not getting the desired results with your current interpolation type, but on the whole, I think you usually want roll. Or such has been my experience anyway.

Matt Andersen

What I like about using a null in a model is the larger bounding box that appears in the action window, its easier to grab and you don't get it confused with say finger bones when you use a null as a "hand" target. There may be other benefits as well, but for me, I like Nulls for targets over bones for targets because of the icon size.

Jeff C.

Just create a new bone, and make it exactly like the parent that you want to have two children, position info, parent, roll, etc. then make the second child bone, a child of this bone, then when you make your default rotation pose, set your second parent bone to translate to and orient like the initial parent, this will only be necessary if you are going to animate the first parent. You probally want to set the second parent to be hidden once you get everything set up, or you'll have problems selecting things.

Matt Andersen

It sounds like you may not have set the Action (wherein you asked it to constrain to the path) to Hold Last Frame (or whatever it's called).

Hash has two user-specifiable ways to deal with the end of an action: either it can hold the last frame, or it can default back to whatever has been defined in other, overloaded levels of action.

If you default back, and have no other actions active on that object at that time, you're gonna bounce back to the origin.

-- Tony

Yeah, something along those lines would be very valuable! In the mean time, to get that effect (rotation without any change of length) I was going to try to attach a bone network and constraints to each individual point of a 'cloth' mesh. I haven't tested it yet, but it has the potential to mimic a decaled shirt or cape without noticeable distortion. I bet Tony L-B would have fun with this idea;)

Glen