Hacking TSM2

[itsjustme]

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.

[itsjustme]

What bone in Squetch is it that TSM can't create?

 

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.

[mtpeak2]

For instance, how would you script the IK arm control setup? How would you script the elbow controller and the bicep orient bones placement in the rig? There's no reference for their position. This is something I was trying to figure out for the 2001 rig, the squetch rig has basicly the same setup.

[robcat2075]

For instance, how would you script the IK arm control setup? How would you script the elbow controller and the bicep orient bones placement in the rig? There's no reference for their position.

 

 

Ok, I'm looking at Woot as a Squetch example....

 

 

the elbow controller seems to have an origin point of about 25% of the way from the elbow (a known point after placing your TSM2 Builder bones) and the wrist (also a known point). I could script a bone that starts there by starting it "between" the starting points of the two bones that make up the TSM forearm.

 

the elbow controller points straight back. Normally I'd use an already existing bone as a model for a new bone's orientation, but there isn't one like that in the original TSM2 arm bones so I'd use "with rotation x, x, x" to explicitly point the bone back.

 

The bicep orient bone is tougher as it hangs out in back there. I was about to chicken out and say "add it to the arm component" (a valid solution) but I see now it's about as far back from the shoulder as the forearm is long. I'd script a temporary bone as long as "with length of" the forearm and point it back from the shoulder like I did the above elbow controller. then I could use its endpoint as the starting point of my bicep orient bone and I then give that bicep orient bone the orientation of a forearm bone to make it correctly point outward. The temporary bone could be deleted or just hidden and left in.

 

This is all do-able and I have done similar new bone creation in my own scripts.

[mtpeak2]

Ok, The hinge bone is the parent bone for the setup (easy to script) the origin of the elbow controller would want to be the center of that bone and 90 degrees to it (starting point is easy, after your "between" explanation), but how would you get it 90 degrees to the hinge bone? It wouldn't always point straight back. I guess the hinge could be scripted so it was rotated at 90 degree increments, along with the elbow controller. The end position (aiming at the hand) doesn't matter too much, that gets taken care of with constraints (aim at with scale to reach on). In the 2001 rig, the bicep orient bone could have the same start position as the bicep with added rotation (duplicate of bicep). This wouldn't work for the squetch rig, it also aims the roll. So your solution may be the only answer to it. To bad the translation doesn't work like the rotation, unless there is a way to offset the start position.

 

Temporary bones could be named with INSTALL in it and deleted with the install rig plugin.

[NancyGormezano]

To bad the translation doesn't work like the rotation, unless there is a way to offset the start position.

 

Temporary bones could be named with INSTALL in it and deleted with the install rig plugin.

 

You can offset the start position (look at arm.txt) - it says something like:

 

create a bone called "blah blah"

with the start point of "another bone" offset by 0.12

[robcat2075]

Ok, The hinge bone is the parent bone for the setup (easy to script) the origin of the elbow controller would want to be the center of that bone and 90 degrees to it (starting point is easy, after your "between" explanation), but how would you get it 90 degrees to the hinge bone?

"with rotation x,y,z" will point it anywhere you want

 

 

It wouldn't always point straight back.

do you mean when you are animating or that there will be characters you'd install squetch in where straight back is the wrong way?

 

 

 

 

 

 

 

 

 

 

I guess the hinge could be scripted so it was rotated at 90 degree increments, along with the elbow controller. The end position (aiming at the hand) doesn't matter too much, that gets taken care of with constraints (aim at with scale to reach on). In the 2001 rig, the bicep orient bone could have the same start position as the bicep with added rotation (duplicate of bicep). This wouldn't work for the squetch rig, it also aims the roll. So your solution may be the only answer to it. To bad the translation doesn't work like the rotation, unless there is a way to offset the start position.

 

 

An answer is an answer. even if it's the only one, it's an answer. You only need one. OUtside of expressions and a some poses that have to have specific values at the 0%/OFF position I haven't seen anything in Squetch that couldn't be reproduced with TSM2 scripting.

[mtpeak2]

Ok, I got the elbow controller 90' to the arm hinge (duplicate of hinge with rotation). But after running the rigger, the left side is pointing in the wrong direction, the Y rotation is not being mirrored, I can fix it manually (see image). A work around would be to eleminate the rotation part of the script and just use the roll handle for the elbow controller's rotation. Since it's a duplicate of the hinge, the orientation is the same and the roll handle would work perfectly, but I'm just trying to reproduce it the way it's suppose to be. Not that big of a deal, but for existing actions to work, it needs to be exactly the same (2001 or squetch rig).

 

Am I missing something in the script?

 

 

create a bone called "arm hinge"

with parent "arm"

with the start point of "upperarm1"

with the end point of "lowerarm2"

with roll of "upperarm1"

 

 

create a bone called "elbow controller"

with parent "arm hinge"

duplicate of "arm hinge"

with start point between "upperarm1" and "hand"

with rotation 0, -90, 0

with length of -35%

 

Thanks Robert, your help is much appreciated.

[robcat2075]

Ok, I got the elbow controller 90' to the arm hinge (duplicate of hinge with rotation). But after running the rigger, the left side is pointing in the wrong direction, the Y rotation is not being mirrored, I can fix it manually (see image). A work around would be to eleminate the rotation part of the script and just use the roll handle for the elbow controller's rotation. Since it's a duplicate of the hinge, the orientation is the same and the roll handle would work perfectly, but I'm just trying to reproduce it the way it's suppose to be. Not that big of a deal, but for existing actions to work, it needs to be exactly the same (2001 or squetch rig).

 

Am I missing something in the script?

 

 

create a bone called "arm hinge"

with parent "arm"

with the start point of "upperarm1"

with the end point of "lowerarm2"

with roll of "upperarm1"

 

 

create a bone called "elbow controller"

with parent "arm hinge"

duplicate of "arm hinge"

with start point between "upperarm1" and "hand"

with rotation 0, -90, 0

with length of -35%

 

Thanks Robert, your help is much appreciated.

 

That's a poser...

 

If we knew the character would always be modeled with straight arms we could base the orientation of elbow controller on "body" and not need to use "rotation" which is doing some funny mirroring.

 

If we knew the character would always be modeled with bent arms like the above we could start elbow controller from the middle of arm hinge and place the end point at the start of the lower arm, also eliminating having to use "rotation".

 

 

If I were trying to debug the script you have I would find some way to not use duplicate of "arm hinge" because when arm hinge gets flipped by rigger it's XYZ view of the world is flipped also. Just a theory, I haven't tested that. And there really isnt' anything about elbow controller that is a "duplicate" of arm hinge after you're done with it.

 

 

How important is the initial roll of arm hinge? is the roll handle pointing up, forward or back in the view you posted?

 

It's possible if arm hinge were created with a different initial roll position, the apparent flipping of elbow controller wouldn't happen.

[mtpeak2]

You couldn't have the elbow controllers end point at the start of the lower arm, characters are not always modeled with equal length upper and lower arms (controller not 90' to hinge). Not an option.

 

The roll on the arm hinge doesn't matter, I don't think. But, the duplicate gives me a starting rotation that it rotates 90' from.

 

The roll of the hinge is pointing back.

 

I'll do more experimenting. Thanks

[robcat2075]

You couldn't have the elbow controllers end point at the start of the lower arm, characters are not always modeled with equal length upper and lower arms (controller not 90' to hinge). Not an option.

 

since it doesn't matter that the upper and lower arm are of equal length and therefore it doesn't matter that the elbow controller is not pointing directly at the elbow, does the exact 90° angle matter?

 

what does bicep orient influence? If I make it visible and drag it around nothing moves.

[mtpeak2]

Yes it matters. The 'elbow controller' is the parent of the 'bicep orient' bone. The 'bicep' orients like the 'bicep orient' bone and aims roll at. Rotating the 'elbow controller' rotates the 'bicep orient' bone around the 'bicep' (orbits), which rotates the 'bicep' around the Z axis and maintaining the X and Y rotation, thus positioning the elbow geometry. If the 'elbow controller' is not 90' to the hinge, it will cause the 'bicep orient' bone to wobble around the 'bicep', which may cause problem.

 

[EDIT] Sorry the bicep doesn't aim roll at in the 2001 rig. In the squetch rig it's more complicated than that.

[robcat2075]

Here's the last dirty trick I'd try after absolutely all else had failed...

 

you could put the relevant scripting for that problem bone in a body part that isn't mirrored like "spine" or "neck". You'll have to explicitly script the left and right versions but that will solve the probelm of rotation being different on left and right sides.

 

I'm not sure what order the scripts are executed, if "spine" is executed before "arm" and your bones will need some parents that "arm" was going to create, then you might create some temporary bones in the correct position that are then later duplicated by "arm" then discarded. If "Spine" references bones that "arm" hasn't created yet it will crash.

 

and all the vice versas for the above.

[robcat2075]

another idea... the arm hinge seems to be on an unoffset aim at constraint from the shoulder to the wrist.

 

What if the arm hinge and its child bones were created in the orientation of the upper arm, then you could easily use the orientation of "body" for that elbow controller.

 

THEN after those have been created the scripting does the aimat constraint and pulls the arm hinge into position, I presume its child bones will follow with it.

 

make sure any constraints that target these moved bones are scripted after the above.

 

 

Alternative I'd consider... is there some other mechanism to control the IK arm besides this particular scheme? Something that would appear similar to the animator but do its job without this exact arrangement of bones? there have to be a dozen variations on IK arm out there.

[mtpeak2]

If I recreate the 2001 rig, it needs to be the same setup.

 

Creating them in the orientation of the upper arm wouldn't work either. You don't know what the orientation will be in relation to the unprefixed "body".

 

I could add the IK setup to the component model and let flipper mirror it, but I was trying to avoid that. Then script a target bone (child of shoulder with start point of bicep) for the hinge to translate to with an aim at constraint. The target bone created in the script would eleminate any user positioning after running the builder.

[robcat2075]

I thought you were doing squetch. I didn't know AM2001 could even be installed in anything other than a T pose.

 

Creating them in the orientation of the upper arm wouldn't work either. You don't know what the orientation will be in relation to the unprefixed "body".

 

Ok, add a dummy hidden bone to the arm component that is pointing straight out. The user never moves it, never attaches anything to it, but scripts can reference it for any straight out orientation needed. If some one runs a script that is not AM2001 the bone will be ignored.

 

There may still be a pure scripting solution.

[mtpeak2]

I thought you were doing squetch.

Back on track, a good test would be to convert the 2001 rig to component models and scripts (with some modifications). Adding bones and constraints to TSM rig is one thing, but building a new rig for TSM to install is another.

 

I know you'll enjoy that project. If you have questions, ask me.

Well, the 2001 rig comes first, while keeping the squetch rig in mind or a new rig all together.

 

I didn't know AM2001 could even be installed in anything other than a T pose.

Why would you think that? It's alot easier in a T pose, but it doesn't have to be.

 

It wouldn't matter if the setup was in the component model, it would be a different file with the same name to be swapped in/out. TSM rig wouldn't be able to use it anyway, bone names would be different.

[robcat2075]

Why would you think that? It's alot easier in a T pose, but it doesn't have to be.

 

I've never installed AM2001 since TSM did everthing AM2001 did and more.

 

 

It wouldn't matter if the setup was in the component model, it would be a different file with the same name to be swapped in/out. TSM rig wouldn't be able to use it anyway, bone names would be different.

 

Well, if your changing the component bone names then anything goes as far as adding bones to the components. My reason for finding a pure scripting solution was so that AM2001 could be installed on the same geometry bones that you would put in for TSM2. Bone your model once and rig it with different rigs with different scripts.

 

The scripts would create control bones that looked like AM2001 control bones to the animator but they'd be driving TSM2 geometry bones. Transparent to the user.

[mtpeak2]

Interesting idea, but the geometery bones in the 2001 rig are the FK controls and the spine doesn't have the same configuration. So, making a script to create a 2001 control rig just became a little more complicated. I would now have to script creating the 2001 rig geometry bones to use as the FK controls and constraint TSM2 geometry bones to them. This would be a problem with the Squetch rig as well, the Squetch rig has more geometry bones than TSM2 rig.

 

There are other possibilities too. Having TSM2 control rig control the 2001 rig geometry bones. Strip out the control bones of the 2001 rig (saving cp assignments, weighting and smartskin) and run rigger with a modified script.

 

So, for now I'll stick to creating new component models and scripts. Then, the 2001 rig scripts could be modified to work with TSM2 component models, but why would you want to do that?

 

Converting the 2001 rig to TSM2 will help newbies install a simple rig to learn with (less geometry bones to deal with). They will only have to position one side, assign cps to one side, right? and not worry if control bones are out of place or constraint issues, if the scripting is correct. Just think, the 2001 rig with multiple arms.

 

I'm still learning how the scripting works, so who knows what possiblities will come of all this. Thanks again for all your help.

[robcat2075]

Interesting idea, but the geometery bones in the 2001 rig are the FK controls and the spine doesn't have the same configuration. So, making a script to create a 2001 control rig just became a little more complicated. I would now have to script creating the 2001 rig geometry bones to use as the FK controls and constraint TSM2 geometry bones to them. This would be a problem with the Squetch rig as well, the Squetch rig has more geometry bones than TSM2 rig.

 

I didn't say it was easy, i just said that was the ideal.

 

 

 

 

So, for now I'll stick to creating new component models and scripts. Then, the 2001 rig scripts could be modified to work with TSM2 component models, but why would you want to do that?

 

Bone your model once and rig it with different rigs with different scripts.

 

Maybe someone found a killer action done in AM2001 that they wanted to use with a character they had boned in TSM. If the scripts used the same components. I'm just brainstorming here. Who knows what crazy stuff pepple will do if you make something possible.

 

Converting the 2001 rig to TSM2 will help newbies install a simple rig to learn with (less geometry bones to deal with). They will only have to position one side, assign cps to one side, right?

TSM FLipper won't flip CP assignments, but perhaps Stephen Gross' Mirrorbone can be used instead.

[mtpeak2]

I do see the advantage of using TSM2 geometry bones with a 2001 control rig, more reusable actions available to TSM2 user base. But, I do see an advantage to having a 2001 rig geometry component model as well.

 

Since TSM2 is now free to all, it would be nice to see a repository of reusable actions for it.

 

It's too bad the flipper doesn't flip assignments and weights. Since flipper doesn't, it's really not needed in the rigging process anymore. Mirrorbones will flip/mirror the bones as well as cp assignments and weights in one step.

[itsjustme]

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.

[robcat2075]

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.

 

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.

[itsjustme]

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.

 

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.

[mtpeak2]

I tried a few too, with no success. It may not even be "apply before action", "store roll" is "no roll", so it could be anything.

[itsjustme]

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.

[robcat2075]

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.

 

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

 

 

 

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.

What's the moving of bones for?

[itsjustme]

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.

 

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.

 

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.

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).

[robcat2075]

I think the macro or diff/merge solutions are going to be too case specific and you're going to spend too much time on them.

 

I would say table this until we have time to write a little program that covers all situations.

[itsjustme]

I think the macro or diff/merge solutions are going to be too case specific and you're going to spend too much time on them.

 

I would say table this until we have time to write a little program that covers all situations.

 

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

[robcat2075]

This hypothetical program could probably insert the Apply before action tag

 

beforeaction=true

 

 

as well.

[robcat2075]

Apparently when TSM2 was written it was not possible via the SDK to directly create an offset constraint. So, TSM2 does a clever trick when it needs to make one.

 

If it needs to offset constrain Bone A to Bone B, TSM2 creates an exact duplicate of Bone A that is a child of Bone B. It then can exactly constrain original Bone A to duplicate Bone A and the effect is the same as an offset constraint to Bone B.

 

However, I've found that it doesn't do this when I try to script a "compensated roll like" constraint. I just get a "roll like" constraint with no offset. It makes sense considering the unique nature of "roll like" but I'm wondering if there's way script around this.

 

hmmm....

[itsjustme]

Apparently when TSM2 was written it was not possible via the SDK to directly create an offset constraint. So, TSM2 does a clever trick when it needs to make one.

 

If it needs to offset constrain Bone A to Bone B, TSM2 creates an exact duplicate of Bone A that is a child of Bone B. It then can exactly constrain original Bone A to duplicate Bone A and the effect is the same as an offset constraint to Bone B.

 

However, I've found that it doesn't do this when I try to script a "compensated roll like" constraint. I just get a "roll like" constraint with no offset. It makes sense considering the unique nature of "roll like" but I'm wondering if there's way script around this.

 

hmmm....

 

I'm probably not understanding what you're thinking, Robert. I do know that a "roll like" wouldn't need a compensate since its' position and present rotation doesn't matter.

[robcat2075]

I'm probably not understanding what you're thinking, Robert. I do know that a "roll like" wouldn't need a compensate since its' position and present rotation doesn't matter.

 

I'd think so too, but there is an offset value in the roll like constraint properties and I have a set of bones now that I had to go and poke in numbers for that offset to get the bones back to where they were before the contraint was turned on.

[robcat2075]

I'm finding that the "with rotation x, y, z" statement seems to apply those transformations in relation to the "world" and not by regarding a bone that was duplicated as a 0, 0, 0 starting point.

 

Would have been cool if it had worked the second way.

 

 

Somewhat related, I think the "roll like" offset problem I mentioned above was an illusion caused by a small error that rotation statement created.