AH_ikfkMaster.ls
downloads:
download AH_ikfkMaster.ls and AH_ikfk.ls, download demo scene
Disclaimer: My tools are provided as is as a courtesy to other users. I claim no responsibility for any damage to your system or files as a result of use of these tools. By downloading these tools you agree to these terms.
Version Compatability
This plugin was developed in Lightwave 2019, and it works in Lightwave 2019 and 2018. I have also tested it in Lightwave 2020 and it seems to work just fine there too. As far as older versions are concerned, this is an lscript plugin, and lscript hasn't been updated in forever so it may also work in 2015 and possibly 11.6, but probably not earlier versions.
If you find my tools useful please consider paying a little something for them, thanks!
Using ikfkMaster
This minimal interface contains all of the functions of the plugin. ikfkMaster can manage multiple characters in a scene without issue as long as the names or tags are correct. It will add some sluggishness to scrubbing the timeline while it is on, but you can turn it off at any time, and it does not affect playback speed, only scrubbing.
The IK/FK Switch Button
This button is the heart of the plugin. When you click it, it will choose the correct IK/FK switch based on your currently selected items, and toggle it. If you have multiple groups selected it will toggle the switch for each group. If your rig is set up for it, and you have posematching or step keyframing active, the the IK/FK Switch button will also perform a pose matching procedure for the defined sync group. It will leave you with a new item selection that is logical (since your original selection will now be hidden). For example, if you have the ikgoal of an arm selected when you click the button for example it will try to select one of the fk controllers in the same group for you. It doesn't always give you the perfect item selection, but it tries its best.
The Sync IK/FK Button
This button performs pose matching on the defined match group but will not switch from IK to FK or vice versa.
If you have made changes and have the warn function active, the border around the "IK/FK switch" and "sync IK/FK" Buttons will turn yellow indicating that your ik and fk rigs aren't synced.
Keyframe Type
This button selects The keyframe type for the switch (the controllers themselves will be keyed with whatever you have set as default in the graph editor.) you can choose between:
- "Step" for on/off IK/FK switching
- "Linear" IK/FK blending
- "TCB" IK/FK blending with tension set to 1.
If you do not have match nulls for pose matching you should stick to the last two modes.
Warn Button
One of the issues that I came across in developing this plugin, is that unlike normal keyframing, when you are dealing with pose matching, particularly when using step keyframing you can run into trouble if you make too many edits in different parts of the timeline, and forget to match your IK and FK setups. It is very easy to accidentally add ugly jumps in your animation. For this reason I have added a warn function. simply tap the button to activate it.
A slight yellow outline around the button will tell you that the function is active. While the warn function is on ikfkMaster will double check to see that your IK and FK rigs are matched before letting you move to another frame. You will receive a warning telling you how many of your ikfk Chains are not synced. and recommending that you sync your ik and fk.
Pose Matching Dropdown
Often you want to have the option of turning off pose matching. This is useful if you don't have pose matching set up or if you would rather use traditional ik/fk blending, but would like to use ikfkMaster's visibility and keyframing features.
It is also useful for many other purposes.
You can set pose matching to the following settings:
-
Match None. ikfkMaster will perform no poase matching when you switch ik or fk or tap the sync ik fk button.
-
Match Chain. ikfkMaster will perform pose matching on the currently selected chain ONLY.
-
Match Pose. ikfkMaster will perform posematching on the entire character.
Channel Button
If you tap this little "c" button next to the IK/FK Switch button it will open the graph editor with with every motion channel associated with the current ikfk chain in the channel bin. The switch channels will be selected.
This button also provides information at a glance about the current state of the ik/fk switch for the selected item (currently only the first selection). If there is on border it means that the switch is at either full fk or full ik. If there is a green border around the button it means that there is a keyframe on the switch at the current frame. if there is an orange border around the button it means that the frame is in between its max and min states. This can be important to know particularly if you are not using step keyfraing for ikfk.
AH_ikfk.ls
This simple little plugin (included in the download at the top of the page) launches and removes ikfkMaster, and I recommend adding it to your menu. It is important to understand that closing the ikfkMaster window won't remove it from the scene, It is designed to come right back like a bad penny as soon as you do anything. If the plugin is in the scene and you no longer want it there just click on AH_ikfk to make it go away for real. You can also remove it directly in the master plugin window, however this is not recommended, because it will leave the item visibility in the state that it was when you last used it, and you will have to manually change the visiblility settings of the hidden controllers.
Troubleshooting
Even if everything is setup correctly it is still possible in some cases that ikfkMaster will not do what you expect. here are some things to
If Pose Matching is not working correctly at all.
An important step in ikfkMaster's Pose matching preocess is to run through all of the affected items and perform Layout's CreateKey command on each one. Currently the channels on which it creates a key are determined by your Create Motion Key settings. Make sure that Layout is set to create Keys for all affected channels. Press enter to open the Create Motion Key dialog. If you do not have all of the relevant channels filled in here ikfkMaster will not be able to match the pose correctly. Remember that the settings in this box are based on the selection, so make sure to select the controller or bone that is misbehaving and check that all affected channels are selected.
If Pose matching is not 100%
In some ikfk setups 100% pose matching might not be possible in all poses. A typical example, that you can see in the demo scene, is when you bend the elbow backwards in fk. because the ik rig has a pre-bend built in it will always bend the elbow forwards.
In other setups, such as for example the fingers in the Demo scene, the ik is directly applied to the fk controls and there is no separate IK rig. In this case you may have some discrepancies between your IK and FK if the IK solver is set to "Base on First Keyframe" in these cases you can solve any missmatch by setting the IK to "Base on Current Time".
If the sync ikfk button doesn't do anything when I have a controller selected.
All of your controllers must have a name or tag that is "Owner_Type..." with type being "IK" or "FK" or "Bones" in order for ikfkmaster to treat it as part of the ikfk system. pose matching won't happen unless the selected item is part of the ikfk system.
My Interface Is Flickering
While ikfkMaster is active it performs a visibilty toggle function each time you move to a new frame, to do this it must select each item and toggle the visibility. This causes flickering that is most apparent in the timeline and certain panels, and I haven't found a good solution for this. If this bothers you simply turn off ikfkMaster when not using it.
Some weird error message popped up.
ikfkMaster may show you an error message that is meaningless. If this happens repeatedly try restarting the plugin, it may have just gotten stuck in some weird state, please contact me if this happens repeatedly
Setup
Before you can use ikfkMaster on your own rigs, you need to set it up.
You can use my AH_makeIKFK.ls script to create simple rigs that work with AH_ikfkMaster, but you are not limited to that, if you want to start from scratch or want to adapt an existing rig follow the guidelines below:
Rig Requirements
In order to use ikfk Master you need a rig that has IK and FK controllers and nulls that function as switches to blend between IK and FK. In other words your ring must already support IKFK blending and have a null as a switch.
ikfkMaster does not make IK/FK. It only manages an existing setup.
You can use any motion modifiers or setups you like, and as few or as many switches as you want, but generally one switch per IK/FK switchable bone chain is recommended.
Currently, there are a few limitations in how rigs can be set up that I am aware of. There may be more that I haven't discovered, however.
- The rig must include bones or joints. They don't have to do anything, but they need to be there.
- Bones should not be used as IK controllers, Bones used as IK controllers will be hidden when you want to see them and visible when you cant use them.
- Different motion channels of a single null cannot be used to manage multiple IK/FK Chains. You cannot for example have a single switch null with the heading controlling the IK/FK blend on one chain and the pitch controlling the blend on another chain. For ikfkMaster one null = one switch.
- pose matching will work best on three joint ik setups with a proper "rotate plane" setup (to borrow maya terminology) and Ik controlling one axis per joint. If you have more bones in your chain or you have multiple axes controlled by IK there are more factors that determine where the affected bones wind up, and you might see imperfect pose matching. For best results with ikfk master on 4+ bone ik chains or 3 bone chains chains that do not have a full "rotate plane" setup with a pole vector you should set the ik mode to "Base on Current Time" in the ik settings this should provide something close to 100% accuracy.
The Genoma2 biped rig is one example of a rig that meets the requirements of ikfkMaster.
The ikfkMaster Demo rig is another.
Getting a functioning IK/FK blend rig to work with ikfkMaster.
ikfkMaster relies on item names or tags in order to understand the rig and determine which bones and nulls are controllers that the plugin should manage. Whichever option you use, the rules are mostly the same, and your names or tags must look something like this:
Example null name: Character_FK_RightArm_1
Example bone name: RightArm_1
Example null tag: IKFK=Character_FK_RightArm_1
Example bone tag: IKFK=Character_Bones_RightArm_1
Notice that bones don't need the first two parts of the name. These are inherited from the object to which they belong. However, If you use tags, you do need to include the first part in the tag.
Tags or Names?
This is entirely up to you. If you have your own preferred naming conventions, and you don't want to use ikfkMaster style names, use tags. If you want to be able to see from a glance in the scene editor how ikfkmaster will manage your items, use names. There are advantages to both methods.
In order to use tags you will need to use the Item Comment Tool included in layout, or better yet, my tagMaster tool. (Unless of course you want to manually add tags to the scene file in a text editor like a crazy person.)
for ikfkMaster to recognize them, tags must be prefaced with IKFK= this is to ensure that they don't interfere with other tags you may have on your items. The Genoma2 biped in the screenshot above has over 100 tags on the item containing the bones. i don't know what happens to the rig if you get rid of them, so ikfkMaster tries to coexist with them, by only using one clearly labeled tag. When testing I just added the IKFK=Dude_Bones tag at the bottom, and it worked fine.
I don't know what happens if you add multple IKFK= tags on a single item, but it probably isnt good so don't do that.
You can freely mix tags and names in the same scene and setup, but It is probably a good idea for your own sanity to stick to one solution per character at least.
Tags have Priority
If a tag starting with IKFK= exists ikfkMaster will ignore the item name and use the tag instead.
Naming/Tagging Rules
ikfkMaster parses the name or IKFK= tag of the item and uses _ to separate the name or tag into the following Attributes:
- Owner
- Type
- Identifier
- Switch definition (optional)
- "match" (optional)
First Attribute: Owner
Character in Character_FK_RightArm_1
Because Lightwave scenes don't really have name spaces (bones sort of live in the namespace of their object, but that is the exception), names are unique and scene-wide, so I find it is generally good practice to put a label at the front of the name so that items that are part of a specific character rif can be easily identified, and minimise naming confusion when load from scene is used. ikfkMaster depends on this. in order for ikfkMaster to know which character is the owner of a particular controller you need to tell it specifically by including that at the beginning of the name (or tag). You can use any name for the owner attribute as long as it doesn't feature the following characters @ or # , but it is important that every controller null in your character's rig and the object or null containing the bones all share the same Owner Attribute.
The bones themselves do not need to have the Owner Attribute as part of their name they will inherit this from the object to which they belong, but if you are using tags the owner must be included.
Second Attribute: Type
FK in Character_FK_RightArm_1
the Type attribute tells ikfkMaster what function the controller has. These types are case-sensitive and must be spelled exactly as shown below in order to work. There are four types:
Type 1: Bones
if you are using names, Only the item that contains the bones of your rig should have the Bones type.
The bones themselves do not need to have the Bones Type Attribute at part of their name they will inherit this from the object to which they belong.
If you want to use names instead of tags it is not a good idea to have your bones parented to the character mesh. instead you should use a null instead and have the mesh use the bones from that null.
If you are using tags you do need to explicitly declare that the bones have the Bones Type Attribute, but on the other hand there is no problem using the mesh itself as the bone parent if you use tags.
Type 2: FK
Any controller that is used to control the rig using Forward Kinematics (direct manipulation of the bones for example) is FK type.
Type 3: IK
Any controller that is used to control the rig using Inverse Kinematics (an goal item or pole item for example) is this IK type.
Type 4: IKFKSwitch
Any null used as a switch to blend between IK and FK is IKFKSwitch type.
Third Attribute: Group
RightArm in Character_FK_RightArm_1
The Group Attribute tells ikfkMaster which ikfk chain the null or bone is part of. This means for example that if you have a rig with FK controllers named something like Character_FK_R_UpperArm_R and Character_FK_LowerArm_R the plugin will not work correctly, because it sees one controller belonging to a group called UpperArm, and another belonging to a group called LowerArm. These are of course common naming conventions and if you want to use them while also using ikfkMaster you will need to use tags instead of names for ikfkMaster.
You can name your groups whatever you like, so long as they don't contain the following characters: @ or #
Fourth, Fifth, Sixth... Attributes (optional if using tags): Identifiers
1 in Character_FK_RightArm_1
These identify the individual null or bone. How you identify your nulls is up to you and you can use as many identifiers as you want Character_FK_RightArm_1 is valid and so is Character_FK_RightArm_Upper_Part in the first example the Identifier id "1", and in the second the identifiers are "Upper" and "Part".
Note when using tags not all items need Identifier Attributes, only the items that are counterparts to a match item need unique identifiers, Otherwise you may get some odd behaviors when ikfk pose matching is used. . Also, do not add identifiers to IKFKSwitch type items.
You can use any string for identifiers as long as you don't use the following characters: @ or #
Fourth Attribute for Switches only (optional): Switch Definition
@Rotation.B(100,0) in IKFK=Character_IKFKSwitch_RightArm_@Rotation.B(100,0)
The Switch Definition is an optional Attribute that can be added to nulls that have the IKFKSwitch type. This tells ikfkMaster not to use the default settings for manipulating and interpreting the switch.
The default setting is @Position.Y(0,1) meaning that ikfkMaster will move the switch to 0 on the Y axis when going from FK to IK and will move the switch to 1 when going from IK to FK. if this is how your switch works, congratulations! You don't need to use switch definitions.
Otherwise the rule is: @"Channel"("Full IK","Full FK")
So in the example tag IKFK=Character_IKFKSwitch_RightArm_@Rotation.B(100,0) ikfkMaster will rotate the switch null to 100 degrees on the Bank angle to switch to IK on and to 0 degrees to switch to FK.
Last Attribute: match
match in Character_FK_RightArm_1_match
This is a special optional attribute that identifies a null that is used for IKFK pose matching.
If an item has match as the last attribute there must be another item that has exactly the same name or tag minus match on other words it must match another item in the scene. That item is its counterpart
if an item has the match attribute and ikfkMaster cant find a valid counterpart is will give you an error.
"#" is Special.
I use # in my rig names for specific setup purposes which is why I treat it as a special case. For the purposes of ikfkMaster's "match" Attribute the # itself and anything after it are ignored. So if you have an item named Character_FK_RightArm_1_match another item in the scene named Character_FK_RightArm_1 or Character_FK_RightArm_1_#_minZ are both valid counterparts.
If you don't intend to use pose matching you do not need to use the match attribute.
Lock it all up
Any null or bone in the rig that is not locked will have its visibility taken over by the ikfkMaster script. So it is important to lock any null or bone that is not a controller that you want the script to manage. ikfkMaster will ignore locked nulls when showing or hiding nulls and bones, but it will still key locked items if they are part of a defined group.
When you use AH_ikfk to remove IKFKMaster from the scene. All of your unlocked nulls will become visible.
Setting up Pose Matching
Pose matching is a little more complicated to set up and it includes adding new nulls to the scene and using Same as Item constraints.
If you do not know how the rig itself functions you may have difficulty setting this feature up, and even if you do understand the rig it is possible to make mistakes that will give you unreliable or incorrect pose matching.
The Basic Idea
ikfkMaster handles pose matching by copying the local positions of the "match" nulls to their counterparts in the rig when you click the ikfk Switch button.
The purpose of a match null is to tell the corresponding controller where it should be to keep the bones in their current position when switching from ik to fk or back. Depending on how you have set up your rig you may need match nulls for IK controllers, FK controllers or both. The match null for an IK goal for example should follow the bone that has the ik goal assigned as a goal.
There are a couple things to remember:
- Match nulls must never be parented to a controller that has its own match null in the same group.
- Match nulls only send their local position and rotation to the corresponding controllers.
This means that Match nulls need to be in the same relative parent space as their counterpart controllers. If the controllers are in a hierarchy the match nulls must also be in their own identical but separate hierarchy.
So, for a simple IK chain, the match null for the ikGoal controller XX_arm_ikgoal would be in the same parent space as the ik goal and be called XX_arm_ikgoal_match. It would be "same as item" constrained to the the bone that has the ik goal assigned as the goal.
Examples
Example 1
In this example I am using names and not tags.
This is a simple arm bone rig with the following bones Arm_Upper Arm_Lower and Arm_Hand these bones are the child of a null calledCharacter_Bones.
Arm_Hand has a goal item called Character_IK_Arm_Goal that is in world space. There is an envelope applied to the IK/FK Blend setting of the bone chain. This envelope is controlled by the y position of a null called Character_IKFKSwitch_Arm with a simple expression.
This setup already works for ikfk switching and controller visibility functions of ikfkMaster, but in order to get pose matching to work on this setup you need to do more.
To get this setup to work with pose matching you must first create a null called Character_IK_Arm_Goal_match, and this item must be "Same as Item" Constrained to Arm_Hand. It must also be in world space. Now there is working pose matching for this simple ikfk setup. When you use ikfkMaster and click the swic the IK/FK switch button the bones will no longer jump from one postion to another.
This is the simplest possible setup. Most useful IK/FK setups will be more complicated. You will need to figure out which "match" nulls you need and how they must be parented and what items they should follow using "Same as Item" based on the rules described above.
Example 2
This example illustrates what happens if you dont follow the rule: Match nulls cannot be parented to a controller that is controlled by a match null from the same group
In this example of what I call a reverse ikfk setup (where the IK is driven by an FK rig). Take a look at the hierarchy of the controllers.
here is a bad setup:
This setup is incorrect. the match nulls are children of controllers that are counterparts of match controllers from the same group. this setup generates double rotations and posematching will be completely broken.
here is a good setup:
This is the correct setup. The match nulls are in a hierarchy among themselves that mirrors the counterpart nulls. download scene file
I recommend downloading the lightwave scenes i have linked to here and analyzing how they work.
Good Luck!
I know that was a lot, but it's worth it when you have it all set up!