I'm getting a drift when i switch between IK and FK on the Scarecrow.

I hadn't noticed this before in the Scarecorw and I haven't found it to happen inthe TinMan yet.

Click to view attachment


I do recall some discussion about an IKFK problem previously, but I can't find the thread now.

It didn't do it on the initial switch, so what's the problem. I would think you wouldn't want to keep switching it on/off within the same frame. What you are seeing, IMO, is the offsets being recalculated everytime you switch it on/off.

It happens in any switch from FK to IK. In the movie I repeated it just to make it clear.

In the presently rigged TWO characters there is a slight twitch when switching from FK to IK. It is corrected in the present version of the rig, but, if I were to update the TWO characters it would affect already completed animation...so I haven't done it. You can minimize the twitch by turning the IK on and off a few times so that the baking of the constraints can help to settle it down. I'll take a look at the video later and see if that's what it looks like, Robert.

I just got a chance to look at the example video, Robert...yessir, that's exactly what I've been talking about. As I said, it is fixed in the latest version of the rig, but updating the TWO characters would affect any previous animation. The reason is there are a couple of things going on in there.

The first is the original design of the IK/FK switch, the new one is a lot better.

The second, which is what will affect previous animation, is that the character's arms aren't all straight on the 'X' axis of the arm bones...on some I would have to move the elbows. There is a constraint that prevents the forearms from bending any direction other than on the 'X' axis, this provides the pseudo-IK behavior of the arms in FK. If the arms are built where that axis isn't straight, you will get some jerking due to that constraint. The Tinman's arms are pretty straight, so, this would be less of a problem with him...I'd have to check to see which ones need the elbows moved.

These same problems exist in the legs, but since the legs were all built with a straight line on the leg bones' 'X' axes, it doesn't show as much.

I have debated making a v2 of each character with updated IK/FK so that we could transition over to the updated rigs at a pre-determined place in the production if it is necessary...that makes the most sense to me. If that needs to happen, I'll have to coordinate with anyone that is presently doing any modifications to a character so that I don't cause them any problems.

Thanks for explaining it.



Now that the movie is more than half animated it's probably safer to stay with what we have.

Really!?! Cool! I was calculating the other day that if we keep the current amount of animators, it would take about a year to do the whole movie start to finish. So, it's looking good before the end of the year. But then there's lighting and rendering.

Anyway....I haven't noticed this drift. Probably because I haven't animated SC much. I also agree it's not big enough to justify a total over-haul. Maybe for the next one.

Hello.

Mtpeak is right. In the movie you posted, the drift does not occur at the initial switch. Or, if it's there, it is very hard to see. I've attached a jpg.

I use a different rig (my own). I chord the limbs of my chracters, so that the arms are perfectly straight out, and the legs are perfectly straight down. I also use the Bob Croucher/Mike Fitz constraint switching properties A LOT. In my experience, drifting is liable to occur if I repeatedly click the pose on and off. If I do it just once per fresh frame, the problem is not an issue.

Sincerely,

Carl Raillard

Notice I'm saying it happens on the FK to IK switches, not the other way around. It does happen on all the FK to IK switches (including the first FK to IK switch) and never on the IK to FK switches.

Like I said, there are a few things going on that are causing it. In Scarecrow, my guess is that it is mostly because of the old design of the IK/FK switch. Specifically, the parent of the elbow controller is rotating slightly...it wouldn't show up in FK because the elbow controller is not actually controlling anything then. The fix was to add another bone as a parent of the elbow controller, add a similar bone for FK and have them roll like each other when not in use.

I posted a simplified version of the new IK/FK switch on this page (the December 9th entry).

Hello.

I did some further tests. I'm finding problems with my own rig, with IK/FK switching. In hindsight I see that Robert Holmen is correct, but I don't think this is a problem limited to the Scarecrow. I'm not even using the squetch rig, and I'm experiencing similiar issues. I've filed a report.

Robert, if this IK/FK drift glitch is seriously hampering your productivity, you might want to consider reverting back to AMv13.0h for the duration of this animating task. For me version h is one of the "sweet" ones. If you do go back to version h, and if that cures the problem, could you add a note to the comments section my report? ID 0004177. I think it'd be useful for the guys at Hash to know, to help zero in on this sucker.

Thanks,

Carl Raillard

Can someone point me to where I can download A:M13.0h?
I have looked on the ftp site but can't see it.
( Also is there an explanation anywhere as to what the "Stuff" programs actually do? How is anyone supposed to know whether they should install it or not? )

Thanks.

http://www.hash.com/forums/index.php?showtopic=23774

Thanks, Dhar!
There isn't an installer for the Oz disc though.

Oh well. I'll just keep playing with this and key every frame if necessary.

Hello, Paul.

Version n is pretty robust with IK/FK switches, too. That's the latest version where keyframes are reliably added when constraints are set to 0%.

http://www.hash.com/forums/index.php?showtopic=24979

There's an OZ version of this one.

Sincerely,

Carl Raillard

Thanks, Carl!

I haven't tried going back to 13h yet, but I'm wondering... If different versions interpret the same switch differently, what will happen at render time when the animations are all rendered in a different version than they were animated in?

Hello, Rob.

To the best of my understanding, they should render fine. The latest versions of AM (version v13.0o, onwards) are having difficulty creating keyframes when the constraints are set to 0%. This is what happens inside those IK/FK poses. If you use a version of AM where this feature is functioning, those keyframes shall be created in the proper way. If, after you do this, you open the project file in a later version of AM, those good keyframes shall still be there, and things should work fine.

If this problem were not so critical, it wouldn' be worth talking about, because the guys at Hash are busy working on it (source: Noel). I fully expect version r to come out, soon. I'd be surprised if the problem isn't rectified, soon. However, this really is a critical feature, by now. Going back to version h or n is more productive than waiting.

I'd be curious to know if going back to v13.0n solves the Scarecrow's problems. David Simmons suspects the problem lies with the rig? He could be right ... and yet the fact that I'm having similar problems with a different rig suggests, to me, that the problem might lie in the program.

It's amazing how the ability to switch from IK to FK in a seamless manner has become part of my workflow. Now that I've got it, I can't live without it!

Sincerely,

Carl Raillard

If you're having similar problems with another rig, then there's another element in addition to the existing problem in the TWO characters, Carl. I'll see about doing some tests with the latest version of the Squetch Rig tonight, that shouldn't twitch.

Okay, I did some testing with this attached set of files...it is an update of the original simple examples of the updated IK/FK switches for the Squetch Rig. I had to fix the "translate to" on the foot IK controller, that got broken somehow (or something changed), but other than that it's the same set.

It appears to work pretty good to me...there is an extremely small bit of movement that seems to me to be due to a less than perfect placement of targets on my part (it's not very much movement at all). If there is something wrong with the switching, it is so small that I'm not worried about it....at least not in testing on these. I did my testing in v13.0q...anyone see any major problems with these on their system? I left the bones visible in both FK and IK so that it would be easier to see movement.

Hello, David.

I downloaded your zipped files, and tested your arm rig in v13.0n. As expected, everything worked fine. I saved the action file and the model in a project file, and then I reinstalled v13.0q, and then I reopened the project. I got the same periodic drift that Robert Holmen documented on the initial post of this thread. Everytime I toggled the pose to FK, the hand jumped by an annoying degree.
And then, suddenly, it began working flawlessly.
What did I do? I have no idea. Now I can't make it misbehave. I tried your leg file, and I cannot get it to make the precessive jumps. The perfomance is rock solid. That's good ... I guess. I wish it hadn't done it with the arm, on my initial try, zo.

My own rig is more constant in its flaws. I'll still be using using n until r comes along.

Sincerely,

Carl Raillard

Sorry to open up this can of worms. I was just thinking that if it worked seamlessly on one character it would be easily fixable on the others, not realizing the complexity that would involve.

I'm not sure where you're talking about Robert, so I'll assume you meant on the TWO characters? I can update them...the problem comes in when I have to adjust their splineage, it would affect previously finished animation. There are at least a couple of the characters that I would have to move the location of the elbow on. Some of them are more work than others, I don't know how long it would take per character...it shouldn't take long, but I would have to coordinate with anyone that is presently making any modifications. I have offered to update them with v2's so that there could be a point in the production where we could transition to the updated versions. I can work it in if it is decided that it is needed.



Those are the ones that bother me too, Carl...let me know if you see it happen again.

Alright, here's an experiment that surprised me...in a good way. I was debating what I should set the v12 Quad Rig's legs up like. I haven't bothered making the v12 Biped Squetch Rig's arms and legs the same as the v13 with the IK/FK update because I had some problems previously getting it to behave consistently from v12 to v13. Well, I made the identical arm that I had in the previous v13 test in v12...and it worked just as well.

I used v12w for the testing in v12, the only thing different is that you have to key the appropriate bones manually (bicep, elbow_controller, forearm, hand and IK_hand_controller)...I have attached the v12 test project. You can open this test project in v13q and the arm rig will work exactly like the previous v13 test arm.

Give it a test run and see if you get the same results...I'd better add updating the v12 Biped Squetch Rig to my "to-do" list.

David,

I thought you might be interested that we are using a modified version of this arm rig. We have built our own rig using ideas from everywhere and we are just starting to start some test animations now.

I basically used your arm rig, except I have a single null that is the hand/wrist controller and it controls that hand for both the FK and IK modes. We wanted to be able to switch modes without having to ever switch the hand controllers, so that that we can get unbroken animation curves right though a FK_IK switch point.

I also added a third mode where the arm is attached to a rail from the shoulder. It is excellent when you need to animate swinging arms.

I will post the our version of the rig once we have done our testing.

Richard Harrowell.

Sounds very cool, Richard! I'm always curious to see what people are working on...I learn a lot of things that way.