[Closed] Access and monitor IKChain controller enabled state
Hi all!
I’m curious if any one knows of way to set and monitor a IKChain controller’s enabled state.
I know you can access the enabled state via ik.controller.enabled and switching this state via an assignment seems to work, but i’ve not yet found a way to setup a wired parameter solution.
Basically, I’d like to create a control, add a custom attribute to it and allow it to control the state of the ik enabled flag AND have that state updated when you slide the time slider and obviouslly animate against it.
Doesn’t sound to hard does it
Cheers
Shane
Can you explain a bit more in detail what you’re trying to do?
The ik.controller.enabled value is a boolean represented as a float. That float can be a custom attribute parameter that is wired to…<you fill this in>…using an expression in the wire params, or by some other means. It should be doable, but you need to give more info. If it’s sliderTime dependant, then you could us a on setTime rollout handler, or a script controller. Need more info to give a better answer.
-Dave
Hi Dave!
Okay, basically I’ve been asked to investigate a means by which we can switch between ik and fk on a rig.
After playing around a little, I found that a ik solution can be enabled and disabled, and what’s more, it can be keyed. Success!
Now this is all cool, but as an animator, I tend to hide as much as possible in the scene when animating so I’m not clicking on elements I don’t want and keep the scene running smoothly.
So I thought I would add a custom attribute to a control that would toggle the state for me.
Basically, I want to wire the state of the custom attribute to the “enabled” controller on the ik, so that when you set the key on the custom attribute, it also provides a sudo key on the ik enabled state.
So I wrote my self a quick custom attribute applied to my control as thus:
(
with undo on (
local modIKSwitch = EmptyModifier name:"IK State"
addModifier $cntIKSwitch modIKSwitch
-- Construct the custom attributes
attEffect = attributes IKSwitchControls (
parameters main rollout:IKSwitch (
fState type:#float default:1.0 ui:spnIKState
)
rollout IKSwitch "IK Enabled" (
spinner spnIKState "IK Enabled: " range:[0.0, 1.0, 1.0] type:#float scale:1.0
)
)
-- Add the custom attributes to the center of gravity control
custAttributes.add modIKSwitch attEffect
paramwire.connect $cntIKSwitch.ik_state.ikSwitch[#fState] $ikswitch.controller[#enabled] "fState"
)
)
Now, most of this works, except the paramwire call, which returns false
At this stage, I thought I’d done something wrong in my code, so I thought I’d try and manually wire them together, except, “enabled” is not an avaliable option in the wiring parameters…??
Now I’m kinda stumped
Two quick updates:
-
I have A solution that keys both the state of the custom attribute and the ik’s enabled state when ever the user changes the state via the custom attribute (this is currently done via a checkbox). This works kinda ok, but I now have the problem of how to monitor the changes in the keys…
-
I’ve discovered that the spinner control has a “controller” property, with which I can connect directly to the ik.controller.enabled.controller and this seems to work, exepct i have to say a spinner is not my prefered method for displaying essentinally a boolean value (on or off)…so any other ideas here would also be welcome.
Hope all that makes some kind of scense…
Cheers
Shane
Sorry, the “controller” property of the spinner does not seem to want to work…or work the way I expected it
Well, first off, the spinner does not have a controller by default. You have to manually add it.
This controller can be any type of controller that returns a float. Usually, you’d use the bezier_float controller.
Here’s an example:
def = attributes testDef
(
parameters main
(
val type:#float animateable:true
)
)
custAttributes.add rootNode def --we add the definition to the rootNode of the scene
bfc = bezier_float() --we create a default bezier float controller
rootNode.testDef.val.controller = bfc
rootNode.testDef.val.controller --now returns Controller:Bezier_Float
So you can see that adding controllers to the customAttributes parameters is pretty easy. You could now wire that controller if you wished, or do something else with it.
One thing to remember is that customAttribute rollouts are very much like rollouts in dialog rollouts. They can have event handlers too. They will only work if the rollout is open, though, but if they are setting keys with animate on, and the parameter is keyable, the keys will be set and will work regardless of whether or not the rollout is visible.
The following code should do exactly what you want:
bx = box()
def = attributes testDef
(
parameters main rollout:params
(
val type:#float animateable:true
)
rollout params "On/Off" width:162 height:45
(
checkbox chk_1 ""
on chk_1 changed state do
(
if(state == true) then
(
$Box01.val = 1.0
)
else
(
$Box01.val = 0.0
)
)
)
)
custAttributes.add bx def
So notice that I have added checkbox to the rollout. This check box has a event handler that simply changes the value of the val parameter of the customattribute to 1.0 if it’s on and 0.0 if it’s off. Since booleans are manipulated using floats, either 1.0 or 0.0, just about any float controller can be used, but note that the if the float is not 1.0 or 0.0 it will be rounded to fit. This is simply one menthod, but it might get you headed in the right direction.
You’re “enabled” property is really accessed using a float that acts like a boolean. Remember that.
-Dave
Hi dave! Thanks for the ideas! I haven’t yet had a chance to look at them.
Very quickly, while there are some errors in the code i submitted earlier (i was taking test
code out when posting), the CA is not the issue…
I can’t seem to find away to “wire” the attribute from the CA to the “enabled” controller on the ik chain controller. “Enabled” does not appear in the wired parameters menu nor does paramwire seem willing to connect them (regardless of what type of connection i attempt to make).
I will look at it as soon as i can, but for the moment, we have a more pressing issue.
A big CHEERS for your help!
Shane