IK/FK auto visibility embeded in the switch. #76913

New Issue

Luciano Muñoz Sessarego · 2020-05-20T15:02:39+02:00

2020-05-20 15:02:39 +02:00

Currently under the way rigify is built, when switching from IK to Fk and vice-versa you need to also turn on and off specific layers that contain both parts of the same limbs as illustrated in this picture:

The idea is that there would be either a default way or an option in the IK/FK limbs like arms and legs to put them only in 1 layer, but when you have your final rig and switch between IK and FK the controllers hide and appear respectively.

To the user, in the rig type you'll get a tick box that activate this feature for the final rig so you'd only have to chose the layers for the tweak bone as both IK and FK chains would live in the same layer. (if you ask me i would only do this version instead of the current one)

On the other hand in the final resulting rig, the only difference for the user would be that he'd have 1 layer per limb instead of the current way (2, 1 for FK hand one for IK ) and the visibiity of the corresponding controllers would switch automatically when switching between one and the other.

The slider that goes from 0 to 1 to blend these chains so in 0 we'd get only the IK controls, in 1 we'd get only the FK controls and in any value in between 0 and 1 we'd get both visible, which would aid at troubleshooting i guess.

here is the final result:

Thank you!

Currently under the way rigify is built, when switching from IK to Fk and vice-versa you need to also turn on and off specific layers that contain both parts of the same limbs as illustrated in this picture: ![Capture-Blender-2020-05-20 13_51_08.png](https://archive.blender.org/developer/F8544787/Capture-Blender-2020-05-20_13_51_08.png) The idea is that there would be either a default way or an option in the IK/FK limbs like arms and legs to put them only in 1 layer, but when you have your final rig and switch between IK and FK the controllers hide and appear respectively. To the user, in the rig type you'll get a tick box that activate this feature for the final rig so you'd only have to chose the layers for the tweak bone as both IK and FK chains would live in the same layer. (if you ask me i would only do this version instead of the current one) On the other hand in the final resulting rig, the only difference for the user would be that he'd have 1 layer per limb instead of the current way (2, 1 for FK hand one for IK ) and the visibiity of the corresponding controllers would switch automatically when switching between one and the other. The slider that goes from 0 to 1 to blend these chains so in 0 we'd get only the IK controls, in 1 we'd get only the FK controls and in any value in between 0 and 1 we'd get both visible, which would aid at troubleshooting i guess. here is the final result: ![ikFk.gif](https://archive.blender.org/developer/F8544804/ikFk.gif) Thank you!

Luciano Muñoz Sessarego commented

2020-05-20 15:02:39 +02:00

Added subscribers: @LucianoMunoz, @icappiello

Loïc Pinsard commented

2020-05-21 10:14:09 +02:00

Added subscriber: @Muream

Ovionis commented

2020-08-08 06:36:23 +02:00

Added subscriber: @Phigon

Ovionis commented

2020-08-08 06:36:23 +02:00

If Rigify used Bpy.Props instead of manually set custom properties, a function could be added to the property's update, to hide visibility at a frame.
This could be added to the rig_ui file for people that don't have it installed.

If Rigify used Bpy.Props instead of manually set custom properties, a function could be added to the property's update, to hide visibility at a frame. This could be added to the rig_ui file for people that don't have it installed.

Ivan Cappiello commented

2020-08-08 12:30:46 +02:00

In my opinion this design proposal seems to join two separate threads:

Remove clutter creates by multiple controls in viewport.
Address some armature layers limitation.

As for point 1 i am strongly against hiding bones (expecially through drivers). Doing this will probably make easier for experienced or pro animators to switch, but will create more issues for standard users (and riggers too):

Hidden bones became unselectable in the viewport and can only be found scrubbing in the outliner that’s not really handy for complex bone hierarchies such rigify limbs
If the driving property gets keyed (that’s what often happens in animation) reviving hidden bones becomes even more difficult since the keyed property gets in the way.
Accessing keyed hidden bones in graph editor and dopesheet/action editor is tricky by default and requires having a mid-pro user knowledge about how to show and edit hidden channels

About point 2, i believe that we are running against a really old limitation realted to old hardware (32 layers) that has no more reason to exist in modern blender releases, except for the fact that no active developer has yet had time to take care of designign an armarure system upgrade that can remove this 32 layers limit. I believe that a “collection” system for bones would be beneficial.

My advice is to trigger on/off the FK/IK layer visibility to hide the undesired bones. This will let the user more easily understand what’s going on and how to change the status manually if he needs to.
Encoding this in rig-ui should as safe as easy enough to, but i’d leave final words on this possible implementation to @angavrilov.

In my opinion this design proposal seems to join two separate threads: 1. Remove clutter creates by multiple controls in viewport. 2. Address some armature layers limitation. As for point 1 i am strongly against hiding bones (expecially through drivers). Doing this will probably make easier for experienced or pro animators to switch, but will create more issues for standard users (and riggers too): 1. Hidden bones became unselectable in the viewport and can only be found scrubbing in the outliner that’s not really handy for complex bone hierarchies such rigify limbs 2. If the driving property gets keyed (that’s what often happens in animation) reviving hidden bones becomes even more difficult since the keyed property gets in the way. 3. Accessing keyed hidden bones in graph editor and dopesheet/action editor is tricky by default and requires having a mid-pro user knowledge about how to show and edit hidden channels About point 2, i believe that we are running against a really old limitation realted to old hardware (32 layers) that has no more reason to exist in modern blender releases, except for the fact that no active developer has yet had time to take care of designign an armarure system upgrade that can remove this 32 layers limit. I believe that a “collection” system for bones would be beneficial. My advice is to trigger on/off the FK/IK layer visibility to hide the undesired bones. This will let the user more easily understand what’s going on and how to change the status manually if he needs to. Encoding this in rig-ui should as safe as easy enough to, but i’d leave final words on this possible implementation to @angavrilov.

Ivan Cappiello commented

2020-08-08 12:40:09 +02:00

Added subscriber: @angavrilov

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

IK/FK auto visibility embeded in the switch. #76913