Bone Target does not work in frame 1

[ericbdg]

Hi all,

I am rigging a character and adds a bone target for the leg, with no parent. It's working in frame 0, but not working in frame 1. Do I miss something?

As for the arm bone target, should it be parented or not?

Best regards,

Erick S.

[Greenlaw]

Can you post a screen cap or video?

In frame zero, the setup frame, you can test IK with the Manipulate Bone tool but it's limited, and you can't test a target there at all. Normally, you would test your rig on a later animation frame. I usually just step into frame 1 to test, but if I have a few pose frames where I'm testing different features of my rig, I'll use the Design Mode shortcut (Shift-Ctrl-D) to toggle between zero and an animation frame.

Re: Bone Target (Tgt). That's up to you and how you like to animate your character. What I like to do for most rigs is use a Tgt bone for the lower leg or 'ankle' of the character and the Independent Angle constraint for the foot bone. This keeps the feet locked in place and the constraint keeps the foot from rotating with the IK. After moving the Tgt bone, you can rotate the foot when you need to.

Remember, you can always un-target the Tgt bone when you want to animate FK instead. Switch to the Parent tool, then Ctrl-click the lower leg and Alt-click the Tgt. This released the Tgt bone. Do this again and it will re-target. When doing this, I suggest Selecting the leg bones and using Keyframe selected before releasing the Tgt, otherwise the leg may 'pop'.

Hope this helps.

[Greenlaw]

Whoops! Sorry, I misread and I see you asked about the arm bone. The leg info may be useful but here's the info you actually asked for...

Generally speaking, no, I do not use a target bone for the arms. It's easier to animate the arms using IK (without target) and FK, and you can easily switch modes by holding down Alt for FK.

For example, pose with IK by animating the lower arm to animate the whole arm chain. Then, you can tweak the position of only the lower arm while pressing Alt. This is a really fast way to animate a character precisely.

[Greenlaw]

But there are times when adding a target for the arms is useful. For example, if you need to lock a hand to the hips while a character is scolding another character, you can use the lower body bone as the target for the lower arm bone. The arm will then follow the body movements as the character rocks from side to side. Then I release the Tgt when I'm ready to animate the arm again.

You can see a lot of examples of this happening in this demo reel...

'My Puss-In-Boots Interactive' demo reel

Edit: A little correction is in order. I'm not actually targeting the lower spine bone here. Instead, I have a small target bone parented to the lower spine bone, and the target bone is offset to where I want the hand to stay locked. Just thought I should mention this before you try it yourself.

[ericbdg]

Hi Greenlaw,

Can you post a screen cap or video?

https://youtu.be/Dda9Uy84ddo

Yes, please check the video. I did according to what you have explained. Does it conflict with the smart bones? Is it either smart bones or target bones?

Thanks about the arm target, yes, I think it's better to just use the lower arm bone instead.

Let me know if the video is clear enough or not.

Regards,

Erick S.

[Greenlaw]

Hmm...that is strange. It looks like you have it set up correctly.

I think I know what's going on here: you probably have a conflict inside one or more of your Smart Bone Actions (SBA)

Try this: specifically check that all the bones in your rig haven't been keyframed inside one of your SBAs; it's probably at frame 1 but check the whole frame range, and check each of your SBAs to be sure.. This can happen, for example, if you accidentally press Ctrl-F (Freeze) or if you had Auto-Freeze Keys enabled while editing an SBA. Unfortunately, this means you may have to crawl through every SBA for your. When you find these unintentional keys, you'll need to delete them all, and possibly re-key what intended to keyframe.

I just recreated this issue here as a test, and I'm pretty sure this is it. My test is behaving exactly like what you recorded.

If this is indeed the case, chalk it up as a lesson learned for the future. (I've made this same mistake more than once myself.)

Hope this helps.

[Greenlaw]

BTW, I recommend learning the Parent tool modifier key I described earlier for targeting and un-targeting bones. It's much easier and faster than selecting from a long list of bones in the Constraint window. With the Parent tool, just Alt-Click your limb bone and then Ctrl-click your target bone. This toggles targeting on and off, and it is completely keyframeable.

[Greenlaw]

Oh, and I was mistaken when I said you can't test a target bone in frame 0...obviously, you can. But it's still better to check your rig at a later frame because not everything is in effect at the same time at frame 0. (Like Smart Bone Actions, as this problem demonstrated.)

[ericbdg]

Hmm...that is strange. It looks like you have it set up correctly.

I think I know what's going on here: you probably have a conflict inside one or more of your Smart Bone Actions (SBA)

Try this: specifically check that all the bones in your rig haven't been keyframed inside one of your SBAs; it's probably at frame 1 but check the whole frame range, and check each of your SBAs to be sure.. This can happen, for example, if you accidentally press Ctrl-F (Freeze) or if you had Auto-Freeze Keys enabled while editing an SBA. Unfortunately, this means you may have to crawl through every SBA for your. When you find these unintentional keys, you'll need to delete them all, and possibly re-key what intended to keyframe.

I just recreated this issue here as a test, and I'm pretty sure this is it. My test is behaving exactly like what you recorded.

If this is indeed the case, chalk it up as a lesson learned for the future. (I've made this same mistake more than once myself.)

Hope this helps.

Noted, I think it's the SBA conflict. I will do this in the next rig, as it was too much to go through each smart bones. Thanks for all of your suggestions I'll keep them in mind

[Greenlaw]

Noted, I think it's the SBA conflict. I will do this in the next rig, as it was too much to go through each smart bones. Thanks for all of your suggestions I'll keep them in mind

It really isn't that difficult. Just double-click each action and look at the bones. If only the bones that are supposed have keyframes are highlighted, then the action is probably fine. But, if all of the bones in the action are highlighted, particularly the entire skeleton or other smart bones, then that's probably one you need to fix. It should be fairly easy to fix once you understand what you're looking at...the tedious part is when there are dozens or maybe even hundreds of actions to check but I find it's usually worth the effort, especially after I've already put a lot of time into the project.

Hopefully, you only need to fix one action but it's a good idea to check all of them to be sure.

IMO, if you've spent any significant amount of time creating this rig, I would not think this effort is a waste of time. Besides, fixing the error yourself can be educational in itself.

[ericbdg]

Hey, this still doesn't work for you ?

It's working now . But with another rigged character.

[pindsvin]

Hmm...that is strange. It looks like you have it set up correctly.

I think I know what's going on here: you probably have a conflict inside one or more of your Smart Bone Actions (SBA)

Try this: specifically check that all the bones in your rig haven't been keyframed inside one of your SBAs; it's probably at frame 1 but check the whole frame range, and check each of your SBAs to be sure.. This can happen, for example, if you accidentally press Ctrl-F (Freeze) or if you had Auto-Freeze Keys enabled while editing an SBA. Unfortunately, this means you may have to crawl through every SBA for your. When you find these unintentional keys, you'll need to delete them all, and possibly re-key what intended to keyframe.

I just recreated this issue here as a test, and I'm pretty sure this is it. My test is behaving exactly like what you recorded.

If this is indeed the case, chalk it up as a lesson learned for the future. (I've made this same mistake more than once myself.)

Hope this helps.

i am register to this forum, solely to say thank you for this solution.
i am learning moho recently, and so many "hidden" thing still to be found, mostly from my mistakes.