itsjustme

Controlling an arm (or any other limb) using "FK" (forward kinematic), the controls work from the top down...bicep to forearm to hand. Meaning that if you move the bicep, everything below it in the chain moves and if you move the hand, it doesn't affect anything higher in the chain (forearm and bicep). If you use "IK" (inverse kinematic) controls, moving the hand will move the entire arm. "IK" limbs generally use the "kinematic" constraint on the end bone of a chain of bones, that will make the chain attempt to reach the IK target (which is generally another hand controller in the case of an arm). To keep the chain from twisting in ways that an arm or leg aren't supposed to move, the IK setup will use a few other constraints as well. In A:M (after v13), you can set up the FK and IK constraints in a way where they will make the switch without the arm or leg moving. In FK, you make the IK controls move like the FK controls. Then, in IK, you make the FK controls move like the IK controls. I have attached a ZIP containing cut-down versions of the arm and leg setup from the Squetch Rig as examples. Hope that helps, Muster. v13_IK_FK_switch_examples.zip

As Mark said, if we haven't purchased Barry's tutorials, we wouldn't be familiar with the rig you are installing. Without an example of the rig and your attempt at installing it, most of us would have trouble helping you, Jason. I'm not sure of the percentages, but I think most people install a standard rig...there are also people that roll their own though. The three most common rigs are the 2001 rig, TSM and the Squetch Rig.

That's one of the things I want to do with him...the way he's dressed now is for a series that I want to do with him working in an office environment. I've got a lot of things I want to do, but I'm not sure how many will actually happen yet.

Thanks Mark! I was going for stumpy fingers on sort of "ham hands"...having only three fingers might make it look too extreme. I haven't done any experiments to make sure he can grip things well yet, just some quick guess-work. The hair has a couple of maps, several length maps just to define the hairline and a density map for the stubble so that it fades in as it gets to the main section of hair. Thanks, Ken! He is harsher than the avatar...I wanted a little frown built into his relaxed face. I'll be doing some tests with the fingers before I consider them final, but I wanted "ham hands", so that's the way I'm leaning. His face may be a little flat, I was going for sort of a "bulldog" type appearance...I'll do some double-checking, maybe I went a little too extreme. He'll get a little more color once he's textured. LOL! I think you're right, Nancy...he could probably use some "love handles". Thanks for the constructive criticism! When you're looking at the small stuff a lot, it helps to have a few other sets of eyes. I'll give him another going-over tonight and see what happens.

Here are some stills and a turnaround Quicktime (H264 encoded video) of Bertram. The only texturing at this point is the iris' and hair...everything else will be done after he's rigged. Modeling isn't really finished until the character is rigged, and any modeling changes would affect decals. I've had previous versions of Bertram, but my modeling wasn't as good when I made them...the last version was made about four years ago. I started over and free-handed most of it, used the previous version of Bertram to get the facial proportions similar and used a rotoscope from an online catalog for the boots. One thing to remember if you use a catalog picture of a boot as a rotoscope...the toes will be flatter if there is a character/person with weight in them. When I initially modeled the boots, I made them like the catalog picture...which had Bertram's toes way too curled. Bertram_turnaround_07_04_2008_H264.mov

The "Project Bertram" area is where I'll post all things related to the character "Bertram" (I've been using an old version of him as my avatar, I'll update that soon)...he's the main character in several small animations that I want to try to get done. Bertram is a chain-smoking, beer drinking Texas redneck (if you're familiar with the comedy of Jeff Foxworthy, Ron White, Bill Engvall or Larry the Cable Guy...that's what I mean). I think of him as being like Yosemite Sam, in that he's always the same guy no matter what the setting or costume. This project, actually it's several small projects with a common main character, is what I'm going to use to try to push what I know and try a lot of things that I've never done...I'm not sure I'll be able to do all of them, but I'm going to try. Questions, comments and suggestions/critiques are always welcome. As the project progresses, I'll be releasing things that might be helpful to other members of the community...tutorials, models, examples, etc. The first tutorial will be an update to the Squetch Rig installation tutorial...which I'm thinking will be posted in the "Rigging" section of the main forum. Thanks to Martin for providing this sandbox...I'll try to keep the area clean.

I'm really liking the style, Mark!

Sorry but don't know what is meant by 'geometry' as opposed to 'model' but whatever - it's not important. I just thought someone may have encountered the same problem and had a quick fix. I'll rip it out again and see what happens. Is there a reason you can't attach the actual model to a post in this thread, Paul? If we could open the model in A:M, it would be very helpful in finding the problem.

Post the actual model. If you don't want to post the model with geometry, make a copy with that deleted and post it. It will take some actual messing with the rig to find out what's wrong, Paul.

It's hard to tell without seeing the model. You could post it without the geometry so that it can be tracked down.

Yessir, I'm thinking the same thing. Not a bad bit of exploring though, I've learned a few things.

that's a lot of nulls. A dedicated textprocessing app is the most likely solution. We just need to find someone with some free time to write it. I can't get to it for a couple months Another problem I had with jEdit was that I got an out of memory error if I tried to do all of them at once in a macro. I gave the program as much memory as I could and still had the problem...from the reading I did, I think there's a memory leak in jEdit (related to Java) that shows up when you do that much at a time. I have thought about doing a purely macro solution (which is possible), but it would be even more events than the Diff/Merge I was trying, there would have to be a different version for each type of Squetch Rig installation and contain no extra or fewer bones. Which also means, in jEdit, it would have to be several macros so that the memory leak problem is avoided. Another text editor that can record a macro could be used if it is cross-platform. What's the moving of bones for? At the end of the process, I have the original positioned Squetch Rig and the same model without Nulls that has extra bones that TSM adds for the compensates. Comparing the two, I can either copy the Nulls into the TSM result or copy the extra bones into the original model. At this point, either way presents merging problems using the Diff/Merge method. ----------------------------- EDIT ----------------------------- I just snapped...it's actually 311 Nulls (I was counting tags, two for each), it is 76 bones though (I was counting the characters "->", which is in each compensate bone).

Well, I've hit a wall. The problem comes in when trying to automate converting bones back to the Nulls in the Squetch Rig. I can do it manually (there are 622 nulls), but using a macro and a Diff/Merge program is proving to be problematic. I can also manually move the compensate bones created by TSM (there are 76 of those), but getting the Diff/Merge to do it correctly would take some manual editing on each of them. The problem is that Diff/Merge programs assume that you want all of the things that have changed in a file to be transferred and I just need parts...it would take splitting up differences manually in quite a few instances because things get lumped together. One direction would be to transfer the Nulls to the model with the compensate bones and the other direction would be to transfer the compensate bones to the model with the Nulls. I don't think an XML editor will do the job because the names of the bones/nulls are inside the tags and the tags are either ", " or ", ". I haven't come up with a way to automate the process where it will work without some kind of error in the final model yet (without extensive manual editing)...I'll have to do some more thinking.

The one example of an "advanced Property" I see enabled in TSM2 is "with lag". I guess you tried "with apply before action" and got nothing? It probably isn't in there if they didn't need it for TSM2. I don't remember all the different ways I tried to do it, but I think I did all the variations of "with apply before action"...I could be wrong though. I tried adding it as a separate line and in the constraint line like the "no roll" option...several hours worth of attempts. I'll try some more tonight.

I got a little side-tracked trying to see if I could script turning on "Apply Before Action" in a constraint using scripting...it doesn't appear to be possible. I checked the included TSM rigged characters and didn't find any constraint with that turned on, so I'm guessing it's not scriptable...it may be, but nothing I've tried so far has done the job. I'll just include in the instructions to turn that on where necessary...I think it's nine times in the Poses that need their compensates reset. If I'm lucky, I might have an example late tonight/early tomorrow.

It can make the bones (the nulls would have to be converted though), but the built-in limitations make things more difficult to build a complete Squetch Rig. I've outlined them in previous posts. Most of them can be worked around, there are a couple of them in what I'm doing to just reset the compenates, but for the face rig I can't see TSM handling that any easier. I would have to put in markers that I'm not sure yet if they would be rejected by TSM, and the Pose installation makes it pretty easy. There are a couple of other hurdles that I haven't tried to work around yet...at the moment, I'm just trying to get the first thing accomplished.

The "InstallRig" plugin was coded by Noel...without it, it would be a lot more work installing the Squetch Rig (lots of re-parenting because of its' design). What it does is ignore everything before the word "INSTALL", then uses the hierarchy after the word "INSTALL" to parent the bones together, deletes all bones with "INSTALL" in the name and then unhides any bone with "geom" in the name. The one variation is that if you need a bone to be attached to its' parent, you need to put "(attached_to_parent)" in the name...without the quotes. I made a tutorial that shows how to build a rig that uses the "InstallRig" plugin...here. As for converting Nulls to bones, I can do that using jEdit, the JDiff plugin and a macro. I should be posting something in the next day or two...I just have to clean things up a little and do a complete run-through.

Nosir, it has to be a v12 model without any nulls in order to have the TSM rigger work. This is not correct. TSM rigger works on a model that has already been loaded. It doesn't matter what version the model came from. Have you noticed that it prompts you to save your work after TSM Builder and TSM Flipper? That would be pointless if you couldn't reload those files for use by TSM2. You're right, Robert...I had the replacement script in there and it confused me. I'll cross that off the list. So, that's one step I don't have to do. Thanks! I'm still feeling my way around with TSM, sorry for the mistake. I'll go back and edit that post. The other listed limitations seem to be valid though.

Nosir, it has to be a v12 model without any nulls in order to have the TSM rigger work. I'm using a macro I made in jEdit to convert the bones and nulls and then pasting them into a dummy v12 model to get around that. Then, I'm using jEdit, another macro and the "JDiff" plugin to do a comparison between the original v13 Squetch Rig model and the one that TSM resets the compensates on to get the nulls back to their original state (which would also have to be done if I scripted all of the Squetch Rig bones and nulls anyway). Robert's next post helped me figure out that I had a script changed out that caused some problems, sorry for the inaccurate information on that one. TSM compensates constraints when it makes them, it can't compensate an already existing constraint that I am aware of...unless I'm missing something.

is the detour thru V12 so the Posable installation rig can be used? I still dont' understand the need for that detour, and it sounds like anyone who wants to install the Squetch rig is going to have to have V12? I've done a Squetch installation once and I dont' understand the advantage of the pose slider driven installation. It seems to me that using the sliders to rotate and scale the squetch rig into place is no fewer steps that using the regular rotate and scale manipulators in A:M to rotate and scale the TSM2 rig into place. What am i missing? You won't need v12, there's a dummy v12 model that things pass through though...I would include that along with a couple of macros for jEdit. This step isn't necessary. There are a couple of reasons to use the Posable installation to position the Squetch Rig. 1. It's already put together and does the job. 2. It has a few dummy-proofing things built into the Pose installation. 3. I'm not sure if TSM would reject the markers I would need to add to get the face rig (and possibly a few other areas) to install using its' method...still an experiment that I need to try. 4. There are about a thousand bones in the Squetch Rig (if I could make the Poses using TSM, that would be several hundred of those, but it's not possible to build them as they are)...that's a lot of scripting, even if I don't run into a limitation that I have to work around. 5. And the things Mark listed....he posted while I was typing this. So far, the limitations that I've found in TSM are: 1. It can't handle nulls. 2. You can only hide a bone in a percentage Pose. 3. You can only make one level of Pose folders (maybe you can make more, but I haven't found a way to do it and TSM doesn't use more for its' rig). 4. You can only put a Pose in a folder if it is a percentage Pose. 5. It can't make both sides of an FK/IK switch Pose without editing it in A:M. 6. It can't make Expressions. The Pose making limitations can be worked around by importing them as is presently done in the Squetch Rig installation...I have made some modified versions of the "FINAL_INSTALL" models that have the compensated constraints taken out. There would still have to be some editing of the FK/IK Poses and any on/off Pose needing compensating that hides bones. There are a few hoops to jump through no matter how TSM is used for the Squetch Rig. TSM wasn't designed to do what I'm trying to do with it, it was made to install a specific set of rigs with specific needs in an older version of A:M. If this experiment fails, I can always resign myself to scripting everything and see if I hit a hidden wall...which is not my first choice and will still require several hoops to be jumped through during an installation even if things go well. However, the job of getting the compensates to work would have already been done, so I wouldn't be losing anything by trying what I'm doing now.

What I'm presently trying to do is use TSM2 to do the resetting of compensates for the Squetch Rig...which does include the bones rig for the face (the standalone FACE setup compensates will be able to be reset this way as well because of that). Different combinations of rigs are also possible, as Robert has mentioned, but I'm just concerning myself with one task at the moment. Eventually, it will probably branch out into being able to make different combinations of rigs. There are a few hoops to jump through when getting this to work, so I'm trying to map out steps that will make it the least difficult. Last week was the first time I ever looked at TSM, so I'm still finding a few things out...I'm pretty close, I can reset all of the compensates outside of the face rig now. One of the things I haven't been able to do is to get TSM to make both sides of an FK/IK switch, but, what I've done is make the "on" side of the Poses with the "off" side having the constraints set to "0%". That means that a little editing in AM will need to be done on those Poses. There are a few other bits of editing that are necessary because of how TSM deals with things, but I don't think they are "deal breakers". To minimize the editing, I'll be using the Posable installation for the Squetch Rig, convert the bones to v12 so that TSM can reset the compensates then add the Poses and bones from TSM to the original model...or some slight variation of that depending on how things work out. I'm trying to get this accomplished so that I can make the updated installation tutorials for the Squetch Rig...I didn't want the tutorials to be outdated before I finished them. Hope that helps, Jake.

A couple of things I found in my testing so far might be helpful to others, so I thought I'd post them. First, if you want to script a compensated "orient like" constraint that has "store roll" turned off, the scripting looks like: Second, it appears that hiding and unhiding a bone in a Pose doesn't work in an on/off Pose, but it does in a percentage Pose. Here is a portion of a percentage Pose to illustrate (it's actually an on/off in the Squetch Rig, I just change it to an on/off in A:M afterward): The "hide" and "show" affect the bone when the Pose is at "100%", so, "hide" will unhide a bone when the Pose is at "0%". I went through several Diff/Merge programs, but none of them would merge files the way I wanted. I figured out that I can get the job done using jEdit with the JDiff plugin and recording a macro. It's kind of a low-tech hack, but it appears to do what I need. I still have a few things to work out, but I'm making progress...still a lot of testing and assessing to do.

When I've crashed TSM2 it's always been because my script referenced a bone that didnt' exist. Typically because I slightly mispelled the bone name. When TSM2 has not crashed but not completed all of a script it has been because I had a stray character or mispelling in some place other than a bone name. Thanks for the info, Robert! I'll do some more experimenting tonight.

I was concerned with altering it because I still am not sure what TSM is looking for in all instances...I've had it decide it didn't like a few things. I'm still feeling my way around. I completely understand, everyone has their preferences. I'm pretty happy with the latest Squetch Rig spine myself (of course, I'm biased), but I realize there are just as many reasons someone would want TSM's spine...it's very nice. this converting back to V12 stuff I don't see the need for? TSM Rigger (the last TSM step) doesn't read any model files at all. It operates on what is in your model window which means it could have been a V13 model by that point. the only Pre V13 things TSM needs is "components" You can run Builder in V13 and save its result in V13, close A:M, reopen A:M, reload that V13 model and TSM FLipper and TSM Rigger work just fine on it. I've had TSM disagree with me plenty, it wasn't made to do a few things I've attempted. I don't remember what I was trying the times I crashed it, but it could very well have been something silly. Breaking things is a good way to figure them out though. I'll have to illustrate what I'm doing, I guess...it may only make sense to the voices in my head. I'm sure there are several equally valid solutions and hundreds of individual preferences. I'm just working on one, but that doesn't mean it won't open up other possibilities.

That's what my app proposal above was about. I can almost see the code in front of me, but I haven't done any real programming in about 3 years so there'd be a certain time spent getting back up to speed on the little details. If anyone out there is enough of a programmer to read and write text files and do search/slice/insert type operations on strings, I can tell them what they need to do. My thinking was that if you have a v13 file that has the nulls in it and a v13 file (after running TSM and then saving using v13) that has every bone with the same name except for the added compensate bones, a program like KDiff3 could be used to set to over-ride the "" or "" tags with "" and "" tags from the original file that had the nulls. I think I'm close to getting that done...I'll do some more documenation reading for KDiff3 tonight. As I see it the only things that are hard-coded in TSM2 are the names of those component and Script files. Inside those it's wide open. The TSM spine has five segments at the standard setting...I forget if it can be set to three, it probably can. Also, there would have to be a bunch of markers added for the FACE controls...personally, I like the posable installation placement of bones (of course, I would though)...it would definitely make the face rig easier to install. That could be added pretty easily as an imported model, but, once it got exported, it would have to be converted to a v12 model to run the last step of TSM. I haven't quite deduced the proper workflow for creating them but the TSM2 rig has poses in it that contain information on both the On and Off positions, so I suspect this can be done. Just a theory. I do expect that some things for Squetch will have to be dragged into the model after TSM is done but that will still be a lot faster than having to manuallyreset all those compensates. I'm thinking that the only Poses that TSM would need to be able to make for the Squetch Rig would be the ones that need compensates reset, the others can be imported. That would save a lot of time on the development end of things. It will all get worked out, it's still early in the process.