Biped Character Rig Part 15 - Finalizing the IK FK Blend Setup

The arm already has IK and FK control systems and a blend attribute. This lesson finishes their presentation by showing the controls relevant to the current blend: IK at one endpoint, FK at the other, and both while the arm is between them. It changes control visibility, not the underlying blend constraints.

The existing convention is zero for IK and one for FK, established in the earlier IK/FK blend setup. The exact Maya release is unidentified. The recording includes a failed first visibility test and additional driven keys that correct the observed endpoint behavior.

Choose groups that represent each control system

At 00:00–02:00, the hand’s settings control is loaded as the driver in Set Driven Key, with its IK/FK blend attribute providing the input. The driven properties are the visibility attributes of the two control systems.

The IK controls have been grouped together between lessons so that one group can hide or show both relevant controls. The FK shoulder control is the top of the FK control hierarchy, so its visibility governs the nested controls beneath it.

Toggle each intended driven visibility manually before keying. Check that the IK group affects the complete IK control set and that the FK hierarchy behaves as expected. Loading the wrong group could hide only one control, hide unrelated rig elements, or leave an endpoint apparently unfinished.

The group introduced between lessons is existing scene state at this video’s start. The transcript describes its purpose but does not replay every organizational operation used to create it.

Key opposite visibility states at the blend endpoints

During 02:00–03:00, the instructor keys the FK system visible at blend one and hidden at blend zero. The IK system receives the opposite pair: visible at zero, hidden at one.

Blend state	IK controls	FK controls
0 — IK endpoint	Visible	Hidden
Between endpoints	Intended visible	Intended visible
1 — FK endpoint	Hidden	Visible

The table describes the intended behavior, including the intermediate state that still needs testing. Driven keys relate a driver value to a driven attribute value; setting the driver correctly is only half the operation. Set the driven visibility deliberately, then key that relationship with the intended objects loaded.

This is an on/off display arrangement. It is not an opacity fade between curves, and it does not provide pose matching or prevent an arm from changing pose when the underlying blend changes.

Correct the intermediate behavior with near-endpoint keys

At 03:00–06:02, testing shows that the first endpoint keys do not produce the desired intermediate display: only one system remains visible in part of the blend. The instructor therefore adds extra keys close to the endpoints.

For FK, visibility is set on at a small positive blend value near zero. Its hidden state remains at exactly zero. For IK, visibility is set on at a blend value just below one, while its hidden state remains at exactly one.

The captions include several spoken corrections and inconsistent runs of decimal digits. They establish the strategy—visible just inside the interval, hidden only at the opposite endpoint—but do not justify a definitive pair of decimal thresholds. Inspect the values actually entered when following the recording instead of copying a guessed precision from the transcript.

The initial narration suggests that positive visibility values should keep an object visible, yet the recorded first test still requires correction. Use the observed result as the guide: move the blend through both endpoints and representative intermediate values, then inspect both control sets. Do not assume that two endpoint keys alone establish the intended interior behavior in every configuration.

Check the animator view separately from the skeleton

During 06:02–06:55, the instructor confirms the intended display: IK alone at its endpoint, FK alone at its endpoint, and both systems in between. Joint groups have also been organized between lessons, and the intended animator view will eventually hide the skeleton entirely.

Check the control result with unnecessary skeleton visibility reduced so overlapping joints do not obscure the display test. Then verify that the blend itself still works; visibility and deformation are separate relationships even though they use the same driver.

The lesson finishes the demonstrated control-display behavior. It does not certify the exact transition thresholds across every intermediate value, implement seamless animated switching, or replace the earlier joint-blending setup. Keep the hand/settings control accessible so the animator can still change modes after either control system has been hidden.