Problems blending actions

I have been having many problems blending actions in NLA and need some advice. I am using Blender2.49b. One problem is that a bone with a ChildOf constraint on it works fine when its influence is set to 0 or 1, but acts funny when the influence is somewhere in between. I don’t know why, but the bone with that constraint moves in odd directions when the influence is between 0 and 1.

Another problem is blending between actions where one action uses FK and another action uses IK. Is blending between FK and IK actions something I can realistically expect to be able to do? Or is it inevitable that any attempts will produce strange results? When I do this, the influence of IK constraints is between 0 and 1 so I wonder if it could be a similar problem to the bone with the ChildOf constraint.

I also have actions with characters moving their arms defined with it standing up but I’ve been using the actions with the character sitting down. So far there havn’t been too many problems with this, but there are still things to fix. I was wondering if anyone has any experience in this area and knows if it is worth the time to try to define actions in this way or if I should define separate actions for the same arm motions based on whether the character is standing or sitting.

I don’t think you will get much help because very few people keep using Blender 2.4x, is there any chance for you to transfer your project to 2.5x?

The main reason I still use 2.49b is because I often use deform action modifiers, which has not yet been included in 2.5x. The project I am currently discussing does not use action modifiers, so I could look at it in 2.53, but I’d have to get used to the new interface.

All the main concepts remain there still, Blender has almost only changed visually. Check Ira Krakow’s tutorials, they’re pretty good and fast to start working with 2.5x:

The current version of 2.5x is still in beta and subject to significant revision in any area, which can (I have learned from sad experience) break a project. If 2.49b is serving your needs, by all means stick with it, many people are still using it and its feature set and weaknesses both are well-known and stable.

To the OP: you begin the first post by saying that the problem seems connected to NLA blending, but then go on to mention how bones act oddly with fractional constraint influence applied. Is the Constraints problem NOT present when NLA is disabled? Try to narrow the problem down to a specific situation.

Posting a .blend file for others to look into often helps as well. Regardless of version used, you may be trying something that others have not yet tried, or a different approach that isn’t commonly used, so being able to see what you’ve done can be of benefit in troubleshooting.

FK to IK blending is quite possible and you should be able to search out a number of posted rigs that do this very well.

Re: Arm Actions for sitting and/or standing – I think that would depend on whether or not you’re using IK or FK and how you’ve set up the IK controls if that is that case. If your arm actions are defined by objects acting in worldspace, then you’d probably need two different sets. If everything is defined in Armature space, then you should be OK to use the same arm motion for either pose of the rest of the body.

The problem with fractional influence still exists outside NLA in Blender 2.49b. However, it looks like it doesn’t exist in Blender 2.53 beta in or outside the NLA (at least with the ChildOf constraint).

I have attached the blend file. Scene.002 is the scene where fractional influences on the ChildOf constraint were producing strange results in 2.49b. Scene is the scene where I tried to blend between IK and FK.

I have the influence of the constraints affected by bones at the bottom of the armature. I have python script constraints attached to the same bones as the IK/ChildOf constraints to use the other bones at the bottom of the armature to affect influence.

I realize that with Scene.004, I need to redefine the action so that the character’s arms stay above the table. I also realize that the bone flies a bit at one frame, so I need to try to configure the elbow control bone (UpArm.R.001).

If someone wants to create a new scene and link object data to the new scene, it will be necessary to run the python script called rename_option and change the nname variable to Person1.arm.005 and run it again with the variable changed to Person2.arm.005.

Sorry, I couldn’t attach the .blend file. It was 1.07 MB and the limit is 0.976 MB.

I think I got it this time. I deleted some scenes to reduce the file size.


action_test_20100902at21.blend (879 KB)

Taking a look at your .blend, I gotta say I can’t quite understand why you’ve approached the rigging in this fashion, seems terribly over-complicated to me, but that’s not really the point, it just makes it harder to suss out the problem.

In 2.49b – it does seem as if the Child Of constraint when used as you have (bone to bone) produces some non-linear effects with fractional influence. After peeling away all the other influences on the source and target bones, manually dragging the Child Of constraint slider does produce odd dislocations for values between 0 and 1.0.

By contrast, Copy Location and Copy Rotation constraints used on the same bones are perfectly linear for fractional influence values. This seems to indicate that the Child Of constraint is glitching in this situation, but it may also just indicate that use of the Child Of constraint is inappropriate as you have it set up. The question to ask is what purpose the Child Of constraint serves in the rig, and can that purpose be accomplished by using a constraint that doesn’t show the glitch (such as one of the Copy constraints)?

Don’t mean to imply an critique of your rig, btw, I’m sure you have very sound reasons for the design. But it’s complicated enough to make figuring it out in detail require more than an hour or so playing with it.

As far as using 2.53 beta, using it is of course at your own discretion, and if it seems to fix your problem, all the better. But being betaware, and in particular, betaware for a major new version of the app, it’s still subject to changes that can possibly break project-critical features/functions. Just be aware of that when choosing to use it.

I apologize for the complexity of my rig. Let me explain why I have it set up the way I do:

The reason I have bones like UpArm.R and UpArmY.R where one controls the X and Z axis Euler rotations of the upper arm and then a separate bone to control the Y axis is because when the upper arm twists, the part of the arm near the shoulder would rotate by a smaller degree than the part near the elbow, but when rotating about the X or Z axis, the upper arm would rotate by the same angle at every point. This way I can set up a vertex group where the vertex weights in the group are smaller at the vertices closer to the shoulder and larger at vertices closer to the elbow. I realize on my current robotic looking humanoid model, the arm twists the same angle around each point and looks fine, but I want to use the same armature on a human looking model as well.

I have IK constraints on both the hands as well as the arms (and then switches to turn on or off the IK as bones on the bottom of the armature) because sometimes I have found it easier to define actions with IK on the arms and sometimes it is easier to define actions with IK on the hands. My intent is to never have the IK switched on for both the arms and hands on the same action. Usually, I use the IK on the arms.

The bones called ElbowIK.R/L don’t do anything and I probably should have deleted them before uploading the .blend file to avoid confusion. These bones are left over from when I used to control the elbow in IK in a different way. Currently, I control the elbow with the bones called UpArm.R.001 and UpArm.L.001 by rotating that bone about the global Z axis.

There are some things about my rig that I am unsure about (such as how I set the rotation limits for the arms and legs) and there might be other things about my rig that are not set up very well. Feel free to criticize my rig. I might learn how to improve it and I appreciate you taking a look at it.

I’m stuck between a rock and a hard place on whether to use 2.49b or 2.53. 2.49b has deform action modifiers and 2.53 doesn’t, but the ChildOf constraint behaves better in 2.53 than it does in 2.49b. I think I might end up sticking with 2.49b and trying to use copy Loc/Rot constraints, or maybe setting up a PyConstraint to replace my use of the ChildOf constraint.

No need to apologize! You obviously have specific reasons for this design, and if it does what you want, then the complexity isn’t a problem, it just makes troubleshooting more difficult for someone unfamiliar with it, because of all the layers of control you’ve put into it. I guess if I have any criticism – and it’s more in the way of a comment – it’s that all those layers of control might be fighting one another to a degree. Like having too many influences on any one vertex, it can make finding the source of problems a real chore. But if it works the way you intend it to, then all that just comes with the territory, so to speak.

The actions of various constraints is something that isn’t always intuitive or even altogether consistent. It’s definitely worth trying alternatives if one type isn’t doing what you want. Probably the most important part of making a choice of constraints is to know exactly what you want one to do, and then choose one that serves the need with minimum “overkill” – if you only want something to follow a location, then Child Of is more than you need and adds layers of complexity that are unnecessary – Copy Location should do just fine.

One thing I’ve realized working with Blender is that assuming that something “should” happen as a result of a certain rig design is an exercise in futility – better to think “might work,” try it out, and if it doesn’t, find another approach. Armatures, constraints and the like are just code, and it’d be unreasonable to think that every possible configuration of a particular rig/constraint system could be anticipated in writing that code, so sometimes “should” doesn’t happen because a particular configuration was never anticipated.