View Full Version : IKBooster feature requests

Ryan Roye
02-10-2013, 09:54 PM
As someone who uses IKBooster exclusively in their workflow for just about everything, I'm going to list things in this thread which I think could improve its workflow even further. Keep in mind that I am using 9.6, but I don't believe it has been updated much since then:

-CTRL+LMB (IKBooster's multi-select function): Currently, the only area in which CTRL+LMB seems to work with IKBooster commands is for the fix command. It would be cool if one could use CTRL+LMB to manipulate various other things for IKBooster such as "IKStop", axis locking, and setting the "mode" for multiple items (what if you want 10 items to be "FK control"?, currently you have to do that by hand unless you cloned the item).

-For "Controller Size" (misspelled as "controler" in LW 9.6) in the IKB menu options, there really needs to be an "autosize" option. Objects that are large will render the controller guides invisible, and objects that are small will have over-sized guides (which get in the way). Note that I'm not referring to what the user has selected, but the "circles" and other symbols that appear when IKBooster targets a specific hierarchy. I leave them off only because otherwise I'd be forced to constantly visit the options menu to work with objects of different sizes.

-XYZ movements currently ignore the keyframe mode entirely... they should work with the keyframe mode. I don't think this is technically a bug, but rather a feature that was never implemented, which is why I'm putting it here. It would be really handy to be able to get complex IKBooster XYZ-based controls working without needing plugins to make keyframing the hierarchy work.

I'll post more as I get ideas... some of them fall into the grey area though, as some of them could be considered features or bug fixes depending on how the person interprets it.

Ryan Roye
02-15-2013, 06:25 AM
GLOBAL AXIS ENABLE/DISABLE: A major problem that most people using IKBooster will run into is that the LW interface gives you absolutely no clue regarding the fact that these buttons....


Do something different when in IKBooster mode. These buttons need to change in some way when in IKBooster mode! For those who don't know, these buttons, when in IKBooster mode, stand for global axis/channel disabling for IKBooster movements (IE: click X and Z, and you can restrict IKBooster movements to the Y/H channels).

So, instead of XYZ, perhaps it could say "ON/OFF" using the channel's color.

02-15-2013, 07:14 AM
Nice pitch excuse that pun!
Seriously ,I read in Genoma
Traffic that Mr . Lino is pushing
for Spline based IK to hook
into Genoma II?

Me ,a littlespline lattice in both ,would
give me a good Chuck Jones stick to
Waggle! Good luck

02-15-2013, 11:50 AM
Thanks in part to efforts from users like you (loved your series & your tutorials!) I've added IKB to my toolset & am in the midst of working how best to leverage it between my LW/Messiah/MB animation setups. I hearilly agree with your suggestions!

Ryan Roye
02-15-2013, 01:26 PM
HOTKEYS: Some of IKBooster's functions would be made much faster if one could hotkey them. The most useful ones in my opinion would be:

-Fix (This is a frequent-use command!)
-Set Keyframe Mode
-Set Movement Mode
-Pose/Motion Load/Save

It'd be really cool to have a branch just for IKBooster functions in the edit menu/keyboard dialogues.

POSE/MOTION LOAD/SAVE DIALOGUE INCONSISTENCY: The dialogues between pose/motion functions in the timeline versus when right clicking an object are not consistent, yet the perform the exact same function. This is important because most people discover pose load/save via the right click menu first, but don't realize the relationship between the keyframe mode and these functions... it makes things worse as the user does not get the option to set the keyframe mode when using this command. See image for example.


POSE LOAD DEFAULT FRAME VALUE: The default frame value when doing a pose load needs to be set to where the playhead is currently at (all the other pose/motion load functions do this!). When loading poses via the 3d window, it currently defaults to wherever the user last touched the dope track, which means a user can easily accidentally apply a pose to the wrong frame. This could also be considered a bug? Not sure.

POSE/MOTION SAVE SHOULD ADD .TXT TO EXTENSION IF MISSING: If the user chooses to enter in a new name for their saved motion/pose and forgets to add ".txt" for the extension, the file will be without an extension and will not appear in IKBooster's load pose/motion file dialogue. The extension should automatically get added if not present.

ADD AN OPTION TO DISABLE IKBOOSTER AUTO-ACTIVATE: When selecting a rotation object that has IKBooster applied, IKBooster will automatically activate. When I want to do a bunch of non-ikbooster movements, I find myself having to switch out of IKBooster every time I select something... we need an option to disable auto-activate.

Ryan Roye
02-15-2013, 08:09 PM
ADD AN OPTION TO HIDE 3D WINDOW XYZ/HPB CONTROLS: Sometimes, when items are clustered tightly together or the viewport is oriented in a way that makes objects overlap, the XYZ/HPB single channel controls can make selecting an object troublesome. See below image:


In this case, the null to the right can't be selected without moving the viewport. This also makes placement of items to the right of any other item an IKBooster workflow hazard. It would be highly beneficial to be able to toggle visibility of these controls on/off via the 3d window right click menu under options (a per-item option toggle would be best). There are many instances where display of these controls are not necessary.

02-16-2013, 01:25 AM
Sure, Chazriker, your tutorials help a lot :) Thank you

Ryan Roye
03-15-2013, 07:19 AM
CTRL+LMB continued: Extend IKB multi-select to also work with keyframe management commands (copy keys, delete keys, apply keys, copy key from current, etc). This would not only greatly improve the amount of keyframing control a person has over their entire IKBooster rig, but would also make certain tasks much faster to do.

Example: Say you want to delete all the keyframes in both your character's arms using the "Delete Keys" command, but you don't want to touch any other parts of the rig. If the above were implemented, one would be able to just set their keyframe mode to "Child", hold CTRL+LMB to select both shoulders, and initiate the delete keys command instead of having to do the arms individually.

03-16-2013, 11:04 PM
Chazriker, are you submitting these through fogbugz?

Ryan Roye
03-17-2013, 06:19 AM
Chazriker, are you submitting these through fogbugz?

I had thought that fogbugz were for bugs, not feature requests. I have submitted various bugs on IKBooster already though through there (IE: Parenting/Unparenting an IKB enabled object will make Lightwave do weird things).

03-17-2013, 09:04 AM
Nope, fogbugz is for feature requests too. It's the better way to get the devs eyes on things.

03-17-2013, 09:01 PM
I would really like IKB to get rid of the need to bake when items are fixed. Set the Bake zone as you do now, but use whatever system it uses interactively deforming the hierarchy to deform it between keys, so you never have to bake. If that was fixed, it would make using IKB less destructive and more easily editable.

Ryan Roye
03-18-2013, 12:36 PM
I would really like IKB to get rid of the need to bake when items are fixed. Set the Bake zone as you do now, but use whatever system it uses interactively deforming the hierarchy to deform it between keys, so you never have to bake. If that was fixed, it would make using IKB less destructive and more easily editable.

Easier said than done of course, but I too would like this.

The problem with bakespots is that if you have multiple areas of baking, the orientation of your bone/bones will only respect the first frame of the first bakespot upon using the "rebake all" command. So if they are going to make it better and more useful, they first have to fix the issues tied with it.

Ryan Roye
04-04-2013, 09:47 AM
I have submitted the content of each feature request in this thread to Lightwave's fogbugz.

Ryan Roye
04-30-2013, 06:38 PM
-Allow Boosterlink to work in conjunction with the Fix command while editing.

Currently, when you use Boosterlink to automate controls, it will not work with the fix command while you are positioning the character.


Your character's torso bones are controlled by a null via boosterlink. When you fix the character's arm, the arm will act is though it were never fixed when rotating. Yet if you bake the fixed hand it will stay in place like normal. It would be immensely useful if boosterlink could work with the "IK" of fixed items while editing, and not just when the item is baked.

The only workaround to this that I know of involves creating another null and making it a goal to the fixed hand; it would be nice if this step was not necessary as IKBooster's goals are better reserved for constraining your characters to moving/rotating objects/surfaces.

Ryan Roye
07-08-2013, 12:36 PM
Currently, it is possible to generate an IKBooster-enabled rig straight through Genoma. But I'd like to see things be taken a step further. Here is a suggestion which will enhance Genoma's integration with IKBooster:

It would be extremely helpful to be able to determine the following properties of IKBooster bones through Genoma:

-Rotate (default)
-Quaternion booster
-User Axis (not typically used for character animation)
-Controller Position


- Take the Genoma's spider rig for instance. It has many controls, and highly benefits from having its nulls set to IKBooster's "move" mode for faster editing. However, setting all these nulls to move mode via IKBooster can be a lengthy process (as in, it would take around 60+ clicks to get all the nulls/controls set to move mode). Being able to assign this property via Genoma would ensure the user only ever has to set the "mode" of the control or bone once, and not every time the rig is generated. IKBooster's settings get decimated upon rig updating as well.

Ryan Roye
07-23-2013, 05:55 PM

Currently, record motion's usefulness is stunted by the fact that it completes "recording" the moment the user lets go of the left mouse button. It really should only de-activate when the user either clicks on the red bar, or reaches the end of the time range.

Ryan Roye
07-30-2013, 08:26 AM
There are ways to control the amount of keyframing when baking, but this would still be nice to have within IKBooster:


For example, when animating at 24+ fps, it is not necessary to bake IKBooster "fixed" items at 24 fps... the difference between baking at 12 fps and 24 fps is negligible. Even at 8 frames per second the baked items hold well enough for non-closeup shots. Having a stepped option whilst baking would simplify the process of reducing the amount of keyframing that happens.