two things... after i use the blink control, I can no longer reopen the eyes all the way.

And... if I slide the blink control back and forth enough, the eyelids shut tighter and tighter and then roll sideways.

[attachmentid=23153]

(ouch!)

Just open some windows to air out the room.
Damp straw can actually ferment I've heard.

The "Blink" pose is having keys made for the eyelid bones that shouldn't be made, if you delete the references to them in the Action or Choreography it should work fine.

Hope that helps, Robert.

how can we fix it so that isn't necessary each time?

I don't know, Robert...it appears to be something that I would be unable to fix, I could be wrong though. Here's a very simple example project...it exhibits the same problem. There is only one pose, the pose has two "aim at" constraints on the "eyelid" bones to aim at the blink target...that's it. This isn't set up to do anything other than illustrate the problem, so it's not a fully functioning eye setup by any stretch, but, the more you move the slider, the less the eyelid bones move and the more "shut" they become...there are also keys made for the eyelid bones that, when deleted, make the pose work correctly.

Let me know if you solve it...it bothers me too.


-----------------------------------
EDIT
-----------------------------------

It is report #0003267 on AM Reports.

very clever setup, changing the interpolation between the keys on the pose.

When I recreate that in V11 no keys get created on "lower_lid" and "upper_lid" and the eyelids always return to their expected position, no matter how often I move them.

[attachmentid=23170]

This is very troubling for the notion of bringing in pre-V13 models. I'm going to hazard a guess this has something to do with the changes made to V13 to accomodate "FK/IK switching".

When I've tried animating TWO models I've always been dumbfounded that unexpected keys would appear on things I had never touched. And I'm wondering how this affects channel editing. (For example: If I want to change the inbetweening between two keys do I need to adjust the curves on the unintentional keys in addition to the pose slider curve?)

This is the problem I brought up when the auto force keyframe was added to v13. I was hoping it would have been an on/off option in the constraint itself. I'll look at how David has it setup, I may have a solution.


The problem is that the offsets keep getting recalculated, another set of eyelid control bones should fix the problem. Right now there is only one set of control bones (for the blink) and the geometry bones, the geometry bones have no reference to go back to. They need a set of bones to orient like for the normal position and orient like and the control bones for the blink (which are there already)this way they have a set position to go back to.

Is somebody manually changing between IK and FK? No keyframes are supposed to be inserted unless someone personally pushes the button, (meaning a rig isn't supposed to be able to do it.)

When the contraints are turned on and off, bone positions are now forced keyframed automaticly. This is the whole idea behind the ik/fk switch and the key groups feature of the rig.

The problem isn't in the IK/FK switch, but, like Mark said, may be caused by it. The "aim at" constraints on the eyelid bones is creating keys that it shouldn't, this causes the "Blink" pose to work less and less as it is used. Deleting the keys fixes the problem, but, it was asked if there was a way to eliminate the need to do that every time.

This problem also affected the "orient like" constraints...I tried that as well when putting in the "Blink" pose. I went with the "aim at" constraints because it used fewer bones and I was confident that it would be fixed. I reported the problem as #0003267 on AM Reports.

This is not the same issue, (in fact, Error Report #0003267 is "resolved").

Hi Guys,

I looked at issue #3267, and didn't observe the described behavior in the latest software, but I may be missing something. This issue appears to be different from that one though.

This problem is very annoying. However, I hate to add another layer of bones just to avoid it. More bones means less speed.

I changed the Blink pose to run the enforcement of the constraints from 0.01% to 100%, rather than 0% to 100%. Now sliding the slider up and down many times, never turns the constraints OFF, so no keys are ever created, and no problem occurs. This is an easy workaround for now.

However, there still may be times when we just don't want to auto-key certain constraints, when they are turned OFF. For this I could add a new property to constraints which would allow it to be disabled. I considered this when it was written in Alpha, but couldn't come with a concrete example of a constraint which you would not want keyed when turning it OFF. So, following the usual AM philosophy, I didn't add the property, since I couldn't determine a real use for it.

Thanks all for discussing this problem,
Bob

Good solution Bob. This will have to be applied to the neck squetch slider as well, I noticed this problem also that the head would not return to the original position. I'm sure there are others.

My mistake on the AM Reports number...in my head it was the same problem somehow. I should have re-checked instead of assuming...I know, don't assume. Sorry for the inaccurate info, I'm going to blame senility...it's better than stupidity, at least.

Very cool and easy solution, Bob...I would never have figured that out. I'll do some updating as I can get to them.