Rig slider woes...

Support Animation and Rigging
#1

Okay, I have some problems with integrating a slider to switch IK/FK for my latest rig.
This time around, since it is possible to drive constraints in-armature, I don’t use outside objects.
Instead, I have this nice frame and a few bones which drive the switching.
All’s nice and well, and everyting is setup to work, however it doesn’t.

You need to skip a frame to make the switching effect “active/happen”

It’s actually the same technique as lots of people used before. The only main difference is that this time, the sliders are in-armature, meaning they are part of the same armature, rather than seperate outside objects.

Cessen’s latest biped rig (http://blenderartists.org/forum/showthread.php?t=131079) uses the same technique, and it does not have that issue. Granted, it uses a different setup and different constraints to do the FK/IK thing, but when I alter my rig to follow his exact same technique, I still have the same issue.

I´ve uploaded the file containing a limb at my site:
http://tieleman.m.googlepages.com/hiddenpage2

If anyone has a clue as to why this refresh issue is happening, and how to fix it, I’d be more than happy to hear it.

Here’s an image of the setup:
http://img397.imageshack.us/img397/6858/screendump08al0.jpg
Shot at 2008-09-12

and here’s an old WIP of the rig:
http://img145.imageshack.us/img145/8392/screendump07ac2.jpg
Shot at 2008-09-05

meeeeeh, consider this more or less the announcement… The rig is done, except for this slider thing which is driving me up the wall right now…

ps. The original character design is not mine on this one. I liked the character, and took the original mesh, and changed the hell out of it. Would’ve been faster if I just redid the entire mesh, well over 90% of it is changed. Original design is by Balade, over at CGtalk. He’ll also do the new texture.

Don’t think I’ll release it untill I get the switch to work right though…

#2

Have you any hidden bones there? Cessen’s rig has two identical chains of bones - one deforming the leg, the other an IK chain. The deform chain copies the rotation of the IK chain with influence keyed by the slider. (so you can still move around the IK chain when it is at FK, but as the deforming bones aren’t being influenced the mesh stays put.)

#3

I am having the same problem, and I am using a multiple limb setup. Before, when I used obj based sliders, I would move the slider, it would work partially, then when I tabbed up and down a frame they would work. Since I couldn’t figure out how to link in obj sliders that worked, I made the sliders out of bones, and now I always have to change frames whenever I change the slider. This is from the MC FAQ:
“Furthermore, there are the glitches: Sometimes you have to frame back and forth to get blender to update the chain properly. Sometimes you have to click on the Constraint “show” button or it doesn’t update - and sometimes, you have to go into the constraint IPO window (after hitting show) and retype the name of the control object in the driver. All of this to “nudge” blender back into working.”

If any of these work for you let me know, I will be trying them out later today.

#4

@ sausages, yeah, those workarounds do the trick, but the whole point was that I don’t want to use those workarounds. as far as I can tell, Cessen’s rig doesn’t have that issue.

@ doncuan: no there are no hidden bones there. It does not have a second (FK)limb set with copyrot constraints, that you drive instead of the IK.
When I found out my approach had this refresh issue, I also made a version with 2 limbs, an IK one, and a deforming FK one with copyrot constraints, that you drive instead.
So I made a limb setup completely identical to Cessen’s rig.
It had the exact same refresh issues, so I went back to the “one limb set” approach.

If this issue is really unavoidable, then I guess it’s ready to be released. I’ve mailed a few people who might know what’s causing this, and I hope I get a reply from them soon. Otherwise… aah what the hell, I dunno, there’s another side project I started working on as well. But I want this one finished, and I can’t get past this bloody issue!!

EDIT:
ow and sausages, this linking thing is also the main things why I wanted the sliders in-armature. being able to clear the position/user transform without the objects jumping to the origin of the 3D view was another.

#5

so far, the only difference I see between my and Cessen’s rig is that his ikfk switch IPO has 3 users, while mine has 7. I really don’t understand that whole part of it, how do you tell what the users are?

#6

users are in this case the number of bones that use that particular IPO curve/Action. Since an action also has a false user, I think you have 6 bones that use the driven ipo to toggle a constraint on/off. correct?
I have no idea to see what the users are directly. A way would be do pose the thing someway funky, then do the sliders and check what changes. Chances are some of those are users.

#7

Ah yes, thanks for the info. I deleted the useless constraints/users, sliders still don’t work properly. Maybe I will try a bit more tomorrow, I have been flipping between the biped rig and my own and I really don’t see much difference, it is puzzling indeed.

#8

I guess that the problem really may be because you have only one bone chain for IK as well as FK. Cessen uses two chains and I personally use even three (FK, IK and the third deforming). I really would not be so concerned for need of one frame skip. Because if animator wants to use a swith he anyway animates within two frames to avoid jumping bwtween FK and IK and vice versa.

The details of animation procees of switches is described here
http://blenderartists.org/forum/showpost.php?p=1173035&postcount=19
http://blenderartists.org/forum/showpost.php?p=1202244&postcount=66
and it demonstrates that it is really no big problem for animator. Moreover it saves contrl for him.

#9

@sausage, the number of users shouldn’t matter for the switch. It’s a single driven curve anyway.

@JiriH
But I HAVE tried two chains. I even went as far as adapt most of my rig to be exactly the same as Cessen’s.
It didn’t work, so I went back to my own setup, which should work the same anyway.

I’m trying the 3 limb setup now, but I’m pretty sure the results are the same. It all adds up the number of bones and constraints. For just the arm, it would mean using at least 4 additional bones not mentioning the hand (so maybe 6 bones or up) and at least 4 constraints on the deformation chain, again not mentioning the hand.

If the results are the same (and they are with the 2 limb set chain at least, and technically, should be the same with the 3 limb set chain) then why go through the trouble to drive all these extra constraints when you can drive only one and have the exact same result?

The only advantage I could think of with using the “2 or 3 limb set” setup, is that you always know where your IK and FK chain are, because they are independant from the actual arm. So you can pose them beforehand.
But isn’t that just a matter of well, taste and ones likes?

About the one frame skip switching, yes I read those posts a couple of times. I haven’t applied it so far, most “animations” I’ve done so far have the IK/FK blended switching. i was going to try your technique for the next one.

BUT STILL! Cessen’s rig does not have the refresh issue, and I can’t figure out what it does differently. You may say it’s not a big deal for animators to skip frames, but it’s a big deal for people just posing/playing around. And it’s a big deal to me, because it is something that should be fixable.

I’ve added a few new rigs to this page:
http://tieleman.m.googlepages.com/hiddenpage2
using some other variations.
A 2 limb setup like cessen’s rig,
a 3 limb setup like JiriH’s approach (also used by ward in his cool alien model)
and a 3 limb setup that defaults to FK instead of IK.

All of these techniques have that refresh issue.

And – it – is – driving – me -NUTS!

#10

I definitely agree that IT IS ANNOYING, you are right. I hope to have some time to reverse engineer Nathan’s rig to find out the solution for problem in matter. And you are probably fight that two bone chains are rather for animator clear and independent picture (IPO curves etc.) of FK and IK.

Sorry that I cannot help you right now.

#11

FreakyDude, you may be interested in my own research concern IK/FK switching. Here is my blend rig with three chains (FK, IK, Deform), FK IK relationship is through third objects (cubes) because actually you cannot use IPO pydriver within the bones of the same armature. But during my test I did not meet problem you are describing hereabove. Even I have my switch as a separate armature, it worked also well when it was part of other bone chains.

http://rapidshare.com/files/141076002/FKIK_Switch.blend

#12

FreakyDude, I had tome this afternoon for some testing and definitely you are right. It seems impossible to set up even simple IPO driver switch for constant using bones of the same armature. But Cessen did it somehow.

Really strange. Maybe we should PM him.

#13

I noticed that Cessen’s rig does not have an Armature modifier in the stack. Maybe his rig is just parented to the mesh?

#14

There is a bug in 2.47 that screws up sliders setup with armature bones (objects are ok) … just use an earlier version like 2.46 to set it up as it seems the bug only affects the setup process and not the end result (Cessen’s rig seems to work ok and that was made in 2.46) …

#15

Vertex Pusher, thank you very much for explanation. It has started to drive me crazy :slight_smile:

#16

Unfortunately it seems that even 2.46 does not work correctly.

#17

Wow, just got home, and lots of good responces.
Nice. i was starting to believe I was imagining things…

FreakyDude, you may be interested in my own research concern IK/FK switching. Here is my blend rig with three chains (FK, IK, Deform), FK IK relationship is through third objects (cubes) because actually you cannot use IPO pydriver within the bones of the same armature. But during my test I did not meet problem you are describing hereabove. Even I have my switch as a separate armature, it worked also well when it was part of other bone chains.
Cool, I will look at your blend file tomorrow, too bloody tired now.
I actually saw that topic of your alternative IK/FK switching, with the constant instead of lineair interpolation thing, but that was before i was worrying about the sliders. will dig into it again.

When the in-armature switch didn’t work, I made it a seperate armature as well. Didn’t copy the original and keep only the sliders, I rebuild it from scratch.
It was actually worse, because not only did you have to skip a frame for the slider to be considered active, you also had to consider which armature you had selected.
it kinda had to update both armatures, and you had to select each of them.
If you did get that to work then I should look into it again.

FreakyDude, I had tome this afternoon for some testing and definitely you are right. It seems impossible to set up even simple IPO driver switch for constant using bones of the same armature. But Cessen did it somehow.

Really strange. Maybe we should PM him.

YAY! I’m not imagining things…
Actually I did PM him a few days ago, didn’t get a response yet.

I noticed that Cessen’s rig does not have an Armature modifier in the stack. Maybe his rig is just parented to the mesh?

It’s the other way around. His rig consists of seperate objects which are parented to matching bones in the rig. if his rig was just parented, there would be an armature field with a “make real” button on it.

There is a bug in 2.47 that screws up sliders setup with armature bones (objects are ok) … just use an earlier version like 2.46 to set it up as it seems the bug only affects the setup process and not the end result (Cessen’s rig seems to work ok and that was made in 2.46) …
Thank you, it was driving me crazy as well. I’ll test it in 2.46, and probably 2.45 as well.
I know in-armature driving wasn’t possible in 2.44, so 2.45 is the earliest bet.

We’re starting to get somewhere now, and that’s quite a relief.
Thanks guys.

#18

Freaky Dude, I have jstu checked the bug tracker. There are already some calls for IPO drivers faults in 2.47 (from famous riggers Burgman and Jorge Rocha). So it is really bloody bug, so be patients. I have put also our problem in the tracker. [#17626] IPO driver using bone not working

#19

that’s good. I’ve been looking through the bug tracker after you mentioned it, and there are a number of IPO and driver related bugs mentioned. Some of them by nathan vegdahl, on the exact same issue, driving in-armature. tony mullen also posted one, but all of them I see so far seem to be closed. Is this fixed in svn?
I dunno, someone is waiting for this character rig, think I’ll release it as is.
It’ll be fixed someday.

Here’s a few of the trackers:
#17466
#17383
#17397

#20

Thanks to JiriH for pointing me to this thread.

The duplicate-arm-bones setup has nothing to do with this delay problem. The reason I have a duplicate set of arm bones is two-fold:

  1. Because it makes the IK/FK blending interpolate better.
  2. Because then the animator never changes or keys the rest pose of the IK bone chain, which can screw with the IK solution.

Getting rid of the delay is actually suprisingly simple to actually do, but is also difficult to understand why it works.

For those who just want to do it and don’t care why it works:
Go to the IPO curves for the constraint whose influence you want to drive. Down at the bottom of the ipo window there is a button with a little icon of a person. Toggle off that button. Then rebuild your drivers for that constraint. That should do the trick.

For those who are curious, the super-short explanation of what’s going on is that this is switching the drivers to be stored in the constraint itself instead of in the action. If I remember correctly (which I may not, since it’s been a while) an action is treated as a single entity in the dep-graph, so if the drivers are both stored in and affect the action, blender considers that a cyclic dependency. So by moving the driver into the constraint you’re giving the dep-graph the chance to solve all the dependencies properly.