View Full Version : Joint "scale compensate" not working.

03 March 2006, 04:52 PM
Using Maya 6.5.

Here's a weird problem. Some skeletons I've developed have scale compensation set to "on". But they don't scale compensate.

However, if I unparent and then reparent the joints, they [i[do[/i] scale compensate. I've tried turning scale compensate on and off without the deparent/reparent technique, to no avail.

It may be something is breaking in the translation to Motion Builder and back through .fbx, certainly a likely culprit. But is there something I'm missing? Has anyone else encountered this and come up with a better solution than running a script to deparent/reparent an entire skeleton? (Easy enough, but not without potential pathologies down the line).

I need scale compensation working because of the stretchy skeletons I'm using, and can't use the "translate joint instead of scale" method because the joints aren't evenly spaced on some of the limbs (I'd have to find time to r&d and alter an established, working script that generates them).

Thanks in advance.

03 March 2006, 04:21 PM
Hey Steph,

I am going to hazzard a guess here...since it sound like it works by reparenting..that there is a connection missing. Check the joints parent... the parent's joint "scale" attribute should be connected into the child joints "inverseScale" attribute. Perhaps this is missing due to FBX issues?


03 March 2006, 04:28 PM
Hey Steph,

I am going to hazzard a guess here...since it sound like it works by reparenting..that there is a connection missing. Check the joints parent... the parent's joint "scale" attribute should be connected into the child joints "inverseScale" attribute. Perhaps this is missing due to FBX issues?


Hmm. That's a good guess that didn't occur to me. If it's not, that's easy enough to script a fix. I haven't had a recurrence of the problem, since everything else I'm using the stretchys on hasn't gone through the conversion process.

BTW, thanks for your help indirectly. Your scripts have been coming in handy answering questions I have about what direction to go in to solve all sorts of problems. You and Hamish. Tell him I said thanks ;)

03 March 2006, 07:33 PM
Cool one of the riggers here at DNA put together a dandy little rigging toolset for Maya also... I haven't played with it yet but he showed me some of it..i'll likely start using it at home...

His site is here:

Go to his scripts page and download the ds_rigToolsPack. It's got a buttload of useful rigging things in one compact interface...


03 March 2006, 09:47 PM
Cool beans. Lots of good stuff in there. Downloaded it and now I'll have to take a look when I get some time.

BTW, I'm now tending to put all my procs in the same script with the interface. Unless there's some heavy duty recursive stuff that deals with all the vertices on a character (I got a couple of those, and they're external at this time). It makes it a lot easier to figure out where the string flow is going and coming from ;)

What's the big downside of having a 10,000 line Uber script, besides maybe speed?

03 March 2006, 01:29 PM
There are a few downsides to having one large script. Mainly debugging. If u have to find errors in your script, whats easier? scrolling through lines and lines of code or dealing with a few in one little utility script. Not a major problem, just makes things more friendly.

If your distributing scripts, its not good because the end user will be sourcing all the scripts even tho they might only want one.

I generally group my scripts. Like all my basic recursive utilities (adding arrays, subtracting, finding paths, etc) are just in one script. As they are used in almost everyone of my scripts that makes more sense.

When u get to having 50-100 seperate procedures it gets a bit messy :) and i like tidyness.


03 March 2006, 01:50 PM
Yeah exactly...typically you will want to organize stuff so it's easier to find/edit later. Even within large scripts I tend to start organzing the procs into logicial groups / areas in the code. The other reason is re-usability.

For example if your code calls a function to say calculate the pole vector direction for an IK setup...rather than leaving that dumped inside of the main could put that out into a proc that just has a library of useful math functions say, and then all your scripts could source that... To more easily share code without duplicating, and once again keeping things neat. But I've written 10,000 line MEL scripts before too..heh.

03 March 2006, 05:02 PM
From the standpoint of making scripts and expecting others to be able to modify them, the big script makes it easier for them. It's hell trying to mod your scripts Mike (and Mac's), as you can sit for days trying to find which script some obscure proc you're calling resides in ;)

I'll have to remember, if I go to a library system and do a proc call, to put a comment above the call telling me which script file the call resides in (because I'll probably forget) ;)

03 March 2006, 08:30 PM
Well usually it's simpler when it's broken down that way since there's less to look at actually.

And I typically recommend prefixing the name of the procs for libs with the name of hte file it is in...hence my usage of sometihng like "libSort_sortByAlpha()" or something like that..tells you to look at libSort.mel. I've started using this convention a lot more lately.

04 April 2006, 03:42 PM
The issue of auxillary scripts would have made a great thread on its own. Since I rewrite a
lot of code I have developed some views on this. While proc lib files are fine, there utility is not great as many of the library procs are very short and could have easily been copied
into the main script. Many scripts I grab on highend come wih multiple lib files, often confusingly named. What makes life hard is when programmers source functions in other
scripts that in turn source functions in other scripts, etc. When I debug/streamline a script the first thing I do is grab all the procs into one script, as usually the aux proc returns, etc. will want to be revised as well.


04 April 2006, 07:36 PM
What makes life hard is when programmers source functions in other
scripts that in turn source functions in other scripts, etc.

Exactly! This is the main reason I favor putting things into one script. Some really long script, I can see using as an external script, as long as there aren't tons of them. But if that, in turn, is sourcing other scripts which source other scripts, it's nigh impossible to untangle where variables are coming from.

It's one reason I've had to write scripts from scratch which duplicate functionality from freely available scripts. I just don't have the patience to try and mod a script to fit the house naming conventions, when I have to first figure out what the library calls are doing, then mod them, and when something breaks it's really hard to track down exactly what's at fault.

If I'm in a house where these things are in use, I don't have much of a choice, but someone around probably will be able to help out with a secret decoder ring. If you don't have access to the original coder, it's a much harder puzzle to solve.

04 April 2006, 04:46 AM
I also like my work to be a portable a possible. Sometimes, a single script is not
feasible, more often than not it is. I don't want to open a script I wrote at an old
job and start hunting for procs that no longer exist in my environment.

In longer scripts, I provide a table of contents that outlines the various code blocks.
Ten thousand lines is a bit over the top, though. I wrote a pose editor that has a
lot of functionality and it ran about 3 thousand lines. About 500 lines of that was
basic file io procs. I could have broken that off, as I use all of the same procs in
a auto rigger, but now I can version easily in one file and publish to common area with
just 1 script.

I once assigned someone to gather all the aux procs for a script into the body of
the main script to simpify analysis and revision. No matter how many times I made
this request, the person just couldnt/wouldn't do it. However they also struggled
with the revision. Makes you wonder...

04 April 2006, 03:46 PM
10,000 lines is a lot. It doesn't get written that way, it gets there by adding 20 to 100 line procs in an existing script. Then one day you turn line nuimbers on and you go "hmmm".

I hadn't thought of a table of contents. That's a really good idea. And if you have external script calls, a secret decoder ring that states at the top which scripts are called, and what procs within them are called within each process, that would be really organized.

It's hard to complain when someone is giving their hard work and brains away for free. But I've been thinking about legacy problems when people develop stuff for work and then leave, and someone else comes along and has to figure out how the heck the stuff works to change it or use it for new purposes.


BTW Comet, if you're still reading the thread, saw yer name on Ice Age 2. Congrats ;)

CGTalk Moderation
04 April 2006, 03:46 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.