Hi, guys! I’m trying to improve LowMax rig from Peter Starostin to use it in an animation test. Using Custom Attributes, I’ve built some finger controls, and the next thing I’m trying to do is a button called “Match FK > IK” and, if possible, “Matck IK > FK”. What does this button do? If you ever tried CAT (Character Animation Toolkit) for MAX, it has a button that makes the FK arm position align with the IK one. I mean, when using “FK/IK Blending” slider, you can animate using FK or IK, but when you go from one system to the other, the arm changes its position.
What I’m trying to achieve is a “magic button” that aligns the FK helpers with the position (it would be more correct to talk about “orientation”) of the IK arm. And once it’s aligned, you continue animating with FK. I’m doing it using Rotation List controller in the FK handlers: one is Orientation Constraint (to match the FK objects “position” with the IK), and EulerXYZ to continue animating with FK. Each one works perfectly, and I’ve created a CA button to do this… but what’s the problem? The action done by the button. It would be this way (I wonder):
0.- You have EULER XYZ FK controllers, to rotate them where you desire.
1.- Align the FK controllers with the IK bones —> EULER XYZ - 0%; ORIENTATION - 100%
2.- Save those modifications, and go EULER XYZ - 100%; ORIENTATION - 0%. Or said in another way, go to step 0, but SAVING the modifications done in step 1.
The step 2 is the one that I can’t get in MAX. I’ve searched through this and other forums for several days, and I’ve found nothing related to this. Maybe it’s a script line, but I’m learning still MAXScript, so there are several things I can’t still afford. So if anyone can help me out, it would be very appreciated.
there are varous things to take into consideration when rotatiing with maxscript -
if you rotate in world space(default) bear in mind that this affects the position also - so you should also add in a line to set the position AFTER the rotation is set -
depending on how you are doing it and where you are pulling the rotations from you may need to do some extra math to get the correct rotations i find it easiest to add point helpers with the same orientation as my control objects(always world space) and then link them to the object those controllers are being aligned to… this way the rotations are clean when pulling them (instead of using offset rotations or using relative rotaitons)
Lowmax im assuming was derived from Lowman the maya rig which could do automatic seamless swapping of ik to fk and back again. (with a touch of a mel script) with that pipe they had 3 chain setups and some cheeky aligning/hide/swap/create key/create key after/change blend value technique. And yes it can be done in max the scripting is a little complex:
The basic premise is that you have three standard chains and ik an fk and a deformer chain.
The deformer chain is orientational constrained between the ik and fk and a slider controls this value.
The script with a checkbutton pressed (for ik), aligns the hidden ik chain end control (i.e the handle) to the fk end control (i.e the hand). It creates a key for the ik at the current frame.Also it creates 2 keys one at the previous frame with a slider value of 0 and one at the current frame of 100 - i.e constrained totally to ik chain. The fk chains now become hidden and unhides the ik.
Then depressing this checkbutton does the exact opposite. The hidden fk matches the ik, the slider swaps and creates 2 keys again, value of 100 at the previous and 0 at the current.
And a key for all the fk bones at the current frame. Hides the ik and unhides the fk.
As to the swivel angle well thats pretty much the same, the ik swivel matches the fk swivel i.e a fake swivel angle. And you dont need to worry about the fk swivel as the fk bones are matching the ik bones previously.
**To make this swivel simply add:
a point constrained positionally to the hand and upper arm bones of the fk. Then a look-at control pointing at the elbow.
create another point align it to the last in both position and rotation. Then go into local mode and move it along its local access away from the last point.(it should follow the look-at controllers line of sight) And parent it to this point.**
And heres some of the script(well the key stuff)+plus it controls the fk controls and has a function to pin the ik:
I did love this method to start, but found issues with it. Mainly being able to move keys around. change timings etc etc it became fiddly. So moved onto a keying script instead which is far flexible. But it was good to find out.
Thanks a lot, Eek. I’m going to analyze your post and your script. After searching a lot over the forum, I found a little scene that you posted some time ago, with a script for matching IK>FK and FK>IK. That was what I was looking for, and after doing some tests, I understood the code, and tried to do the same with LowMax (yes, the “LowMan” version for Max), but it seems there are a few problems with aligning the FK helpers.
I’ll keep trying, and I really appreciate all your help, Mark and eek
I’ve tried to reproduce the setup of LowMax character: the visible bones are constrained with position and orientation to the FK helpers and the IK bones. It works OK if you use a slider to blend between FK and IK (I used Reaction Manager in MAX 7).
The “problem” comes when using a little script to match FK helpers to the IK bones. I don’t want to overcomplicate it, because I’m introducing myself with scripting and controllers, and for the moment I only need a button that align them. So searching and looking several files, I end up with this code for that ‘magic button’:
… so when I press the button (it’s a CA located in the FK shoulder helper - Torus01), the FK helpers align correctly with the IK bones… but it seems to me that only the position is working, because the orientation is not. Before matching FK to IK, all worked nice. But after pressing the button, it happens what you see in the scene. I guess there are some conflicts with controllers, but I didn’t notice…
Excuse me if it’s a basic question or a basic problem, but I’ve searched a lot about these kind of issues, and I’ve found very few info about this
Firstly sorry for the delay,(pretty tied up atm) and i probably didnt explain enough all that well.
Ok, with matching fk to ik , i constrain both Positionly and orientationly a point for each of the ik bones. Then i use these for the fk to reference. It just seems to work better rather than trying to reference the ik bones themselves.
As to the problem with alignment of rotation its due to the order at which they happen in the script, it a case of trial and error. (i had tons of problems of bones flying off all over the place). Also im not referencing the controllers directly in the script, by that i mean im refering to another name for them e.g
fkboneP = $fk1.pos
fkboneR = $fk1.rotation
$ik1.pos = fkboneP
$ik1.rotation = fkboneR
I hope this helps. Im more than happy to send you the actual file, for you to break apart and play with. hehe i did it in max 4, so im pretty sure it will work your version of max.
the lowman rig contains many little features that make the script difficult to work (some controler objects have been mirrored ect…) i have made a quick scene to demonstrate part of the process… it is by no means complete you should be able to fill in the gaps from whats there… if you wanna add ik>fk snap to lowmax rig i would think you would be best off re rigging it as it was not built with this in mind…
here it is and the maxscript that does the snapping - this is only the code to snap fk to ik
Thanks again for interesting in this thread, Mark and Charles. I’m pretty busy in my studio, and as soon as possible, I’ll use your advices and scripts to continue improving myself and my rigs (and LowMax if possible). I’ll post the advances
Nice job on that. I just figured out for myself how to set-up and IK/FK rig like that. A tutorial on it would’ve been really nice. Was thinking of even writing one myself.
I actually have one suggestion. Why not just have a button for IK and a button for FK and scrap the spinner and snapping buttons. Is there really any need to ever have the FK and IK be in different positions? Seems to me it would be better just to hit a button and be in IK mode without the arm changing position and to do the same switching to FK mode. If you’re just going to snap the controls before each time you switch you might as well just make it into 1 button for working in either mode and not worry about having to snap the controls before switching.
The author of the rig have given me permission to make the modified rig public So be ready for it in a couple of days, and in a week, a tutorial about how I’ve set up this system.
Hollowmind, I was thinking about the same thing than you. I have to consider it, and see if it works. I think Reaction Manager does not work with true/false values, but only float. Gotta check it If you have any suggestions, feel free to contact me.