Scripting rigging setups....Advice?

#1

I have been working on a rig and am now pretty happy with it. I’ve tried to keep it simple, but in setup terms quite a few areas are getting a little tricky to apply to new models.(lots of things to keep track of that need to be precisely positioned). It’s not that involved, but there are many steps and I worry that If I come back to it in a few months I’ll have prblems

As only a few areas are “master” positions, there are lots of other elements that could be positioned by a simply rule based system.

I did quite a bit with L script back in the day, but am a complete novice with Messiah script

I’d like to see if any of you have any advice on the following;

[ul]
[li]Where’s the best place to start? The manual turorials are really basic and theirs a big gulf from that to the more “reference” based stuff[/li][li]Is there a way to apply a setup from the pallette in a script?[/li][li]Is there a way to add expressions to the comand tab from a script? I’ve heard that you can’t.[/li][li]Does anyone have any pointers on how to alter the setup positions of an item in a script?[/li][/ul]My most basic plan would be to load a setup by hand that contains some named referance nulls. These would be moved into position to map out all the important positions (I’m thinkingHip, knee, heel, ballof foot, toes, ankle, clavicle, shoulder, elbow,wrist, neck, head, chest end and pelvis.) (maybe I’ll add pectorals. shoulder blade, chest width, pelvis width etc. later…

Once I’ve put these in position for one side of the body I’d load the setup of the actual rig with all of the expressions, control structures etc.

I’d then like to run a script that uses a naming convention to move all of the elements of the actual rig be corect for the positions from the placement setup.

Has anyone done anything similar? does anyone have any tips about the challenges I might face in Messiah script?

#2

Hi Michael,

a few hints on scripting within messiah:

  1. I personally found messiah:script rather primitive, even by comparison to LScript, which isn’t the most advanced scripting language either. There are many thinks lacking and the script language is also a bit akward (a limited kind of the C language). Eventually I decided that for my own projects I would do my programming with the SDK.

  2. If you nevertheless want to do scripting, take a look at the ‘\messiah\modules\scripts’ folder. There are plenty scripts about anything. Start with ‘motlib.msa’ to get an overview of what is possible.

  3. There are scripts that can be run as a command and some that can be run as expressions. The ‘Command’ scripts usually have a ‘main()’ function.

  4. A setup script as you intend should be very well possible.

Hope that helps.

#3

I’m not a messiah user, but I was under the impression that messiah used Python for scripting, is that not correct?

#4

Well, at some point Python scripting was on the agenda and indeed AutoRig II was done using Python. However, there seemed to be some big technical problems and it was pulled out again. I have no idea whether Python support will come back at a later date.

#5

Thanks, Christopher, It does. I’ll probably be back when the problems start flowing!

#6

Thanks for the info on the scripts folder. What did you find limiting? And what could be improved?

#7

My main two gripes with using script languages vs. using the SDK for programming are the following two reasons:

  1. Script languages usually have their own syntax, which might lead to unexpected errors and endless recompilation of scripts. I prefer using the SDK with standard C/C++, when I clearly know why my my plug-in doesn’t compile, rather than searching the docs for some syntactical obscurity. Surely, most scripts can be recompiled with the host proram (the 3D app) still running, while a recompile of of a plug-in usually means shutting down and restarting the host. Nevertheless, for me developing with the SDK is faster.

  2. The functionality of script languages is usually a few versions behind the SDK, so some functions or commands are simply not there, even though they exist in the SDK. For example, it was only in v2.2 of messiah:studio that the command ‘SetCurObj’ (a command for selecting an object) was introduced. Without such a command, it isn’t really possible to write e.g. an autorigger.

Please note that in my arguments against script languages, I didn’t single out messiah. I have also been using script languages in LightWave and C4D and it’s essentially the same problem. Whenever I thought: “This can be done in a script”, I soon hit a brick wall and reverted to prgramming with the SDK. Of course, using the SDK has also its disadvantages: You have to setup your compiler (which can be quite a hassle, but it usually has to be done only once) and you lose platform-independence (not a big deal for messiah, but LW and C4D also exist on a Mac), but for me writing scripts hasn’t been very successful.

#8

Ok, Here we go…

For moving stuff around I was shocked that after reading a few of the scripts from the scripts folder I knocked up a script that worked first time!

after a bit of testing it didn’t work if my objects were parented, but I can see how I might fix that.

The trouble comes where things need to be oriented a certain way, and in their parents coord system.

The obvious functions to solve this (Move to, Align, Target etc don’t work in Setup mode)
Question 1) Is there a way to use these functions in setup mode automatically with a script?

I’ve had this problem before and overcame it in Lscript by writing a target function, but I needed the Up At and Right vectors of the parent and a worldspace vector to target along.

Question2) How can I get the Up At and Right vectors of the parent in Messiah script?

Question3) how do you access a single vector component in a script? does vector.x work for example or do I have to access them with a function as I would if writing an expression?

Hope that someone out there knows… Suricate?

#9

We approached repositioning/rotating/scaling etc. by using a manual sequence of switching to animate mode, applying “motLib_Current2Setup” then back to Setup mode.
I also suspect that this might be an effective way of creating a “poor man’s autorigger” by p[lacing joints which then effect move to’s and aligns.
Unfortunately, I have no idea if a script can access the switching of modes etc.

#10

Interesting…

I think that there’s an “execute command” function in the scripting… and the key command manager is run from commands and there are keys for changing mode…If i look up the command in the keymanager, maybe my script can get this automated…

In Lightwave if you try this sort of thing you often need to add the “refresh now” command Hope mMessiah doesn’t need this as I have no clue there…

In theory this may work… I must try this when I get home.

#11

Yep, this works!

//#messiahscript

int main()
{
SetCurrentMode(“Animate”, 0);
motlib.CurrentToSetup(1);
SetCurrentMode(“Setup”, 0);
return(1);
}

Unfortunately it seems that if you run the target function from a command, it evaluates but no keyframe is created.

The above is a good step though. I’ll have to try some other workarounds…

#12

For targetting an item, you might have a look at the ‘TargetSetup’ function in ‘motlib.msa’. Depending on your needs, this might be easier than switching between ‘Animate’ mode and ‘Setup’ mode.

#13

Ha, I can’t believe I missed those! That should make the whole thing much simpler!
I was just getting depressed at the amount of hoops I’d have to jump through and now it all looks much simpler again!

Edit
No wait, I’ve tested that and the targetsetup function seems a little broken…

#14

Yep, I can confirm that, the math is a little bit messed up. As the description of the function says : the function ‘needs work’. :slight_smile:
I have to brush up my knowledge of vector math a little bit, about two years ago I wrote a plugin for LW that was targetting things and was using this kind of math, now I only have to find my code …

#15

Hope this works out.
It would be great to have a simplified way of re-fitting more complex rigs.

#16

I did one for Lightwave too… I’d be able to port it if I could get the Up, At and Right vectors from the parent (It’d need to work in any parent space…), but to do this from first principles looks like it’s getting on for 12 steps (to convert to Quaternians, do the vector stuff, sort the special cases, all of which will be difficult to test , and even then I’d have to convert back to Eulerangles to apply the rotation, which can be flaky…
(I’ve been talking to some of the coders from work and they were looking scared… The Euler angles always make them shudder)

If anyone knows an easy way to get Up At and Fwd vectors for the parent orientation or how to apply a quaternian rotation to an object without converting it to HPB this could all be a lot easier… as it stands I’m looking into dirty mode switching and ‘copy to Setup’ etc…

Another saver would be if there’s a workaround for the following:
If I use copy to setup in animate mode on an object with a target expression I get the result after the expression…

If I run teh Target function from the command line it evaluates ‘true’ but doesn’t move the object.

If anyone knows how to evaluate this function and update the keyframe without having to make it an expression (ie from a script or the command line) then my dirty hack from a couple of posts back could feel very elegant and make creatig all sorts of autorigs trivial.

It’s frustrating that in animate mode there are functions for pretty much everything, but to use them in setup seems to be a no go.

I’m begining to think a simple skeleton or world space nulls targetted to each other but not parented are looking favourite for the positioning rig. Not quite as nice as free floating nulls, but simple enough really

As a quicky tho… how do I “Add to selection” in a script?

I’m having a night off tonight tho…Tired.

#17

I’m not sure I understand what you want to achieve, but can’t you get the Parents WorldRotation and from that info calculate the vectors? And if you need the sum of the parents parents, can’t you scan through the hierarchy and collect all needed ParentCoords and sum them together?? But what do I know…:shrug:

/ Svante

#18

Yeah, my LW plug-in also made use of the world matrix and I understand your troubles now. I don’t think you can access the world matrix with messiah:script (you can do this with the SDK :)), but you can access the world rotation of an object. Have a look at the TargetSetup2() function of ‘motlib.msa’. There are some calculations to account for the parent’s rotation, maybe that helps. But it seems that this function doesn’t work either …

You can use ‘SelectObj’ to add an item to an selection. That function was added in v2.2/v.5.2, check the ‘What’s new’ section of the docs.

#19

AFter closer inspection it seems to me that the function motlib.TargetSetup2() does indeed work, but only when the original roation of the slave object is zeroed out, because otherwise using its world rotation leads to wrong results. Therefore the world rotation of the parent (if it exists) of the slave must be used.

Following is the corrected code of TargetSetup2():


  int TargetSetup2()
  {
  	object master;
  	object slave;
  	object parent;
  	object it;
  
  	vecd3 mpt, spt, pt;
  	
  	double h, p, wh, wp;
  
  	if(GetNumSelectedObjs() != 2)
  	{
  		MessageBox("Must have two items selected!", 0);
  		return(0);
  	}
  
  	it = GetFirstSelectedObj();
  	while( it )
  	{
  		if( IsCurObj( it ) ) 
  			slave = it;
  		else
  			master = it;
  	
  		it = GetNextSelectedObj( it );
  	}
  
  	// the following lines are new;
  	// rather than the world rotation of the slave object,
  	// the world rotation of the parent should be considered
  	// in case the heading/pitch rotation of the slave is <> 0.0
  
  	parent = GetParentObj( slave );
  	if( parent )
  	{
  		wh = motchan( parent, wheading, NOW );
  		wp = motchan( parent, wpitch, NOW );
  	}
  	else
  	{
  		wh = 0.0;
  		wp = 0.0;
  	}
  	
  	//wh = motchan( slave, wheading, NOW );
  	//wp = motchan( slave, wpitch, NOW );
  
  	mpt = SetVecD3( motchan( master, wxpos, NOW), motchan( master, wypos, NOW), motchan( master, wzpos, NOW) );
  	spt = SetVecD3( motchan( slave, wxpos, NOW ), motchan( slave, wypos, NOW ), motchan( slave, wzpos, NOW ) );	
  	
  	spt = vectlib.invert( spt );
  	pt = vectlib.add( mpt, spt );	
  	
  	// re-orient the delta point to account for parent's orientation
  	pt = vectlib.rotatePoint( wh, vectlib.up(), pt );
  	pt = vectlib.rotatePoint( -wp, vectlib.right(), pt );
  
  	h = atan2( GetVecEntry( pt, 0), GetVecEntry( pt, 2) );
  	
  	pt = vectlib.rotatePoint( h, vectlib.up(), pt );
  	
  	p = -atan2( GetVecEntry( pt, 1 ), GetVecEntry( pt, 2 ) );
  	
  	SetSetupValue( slave, 3, h, 1 );
  	SetSetupValue( slave, 4, p, 1 );
  	
  	return(1);
  }
#20

Thankyou, Christopher, that works an absolute treat!

It’s autorigger time!

Btw, I love your symmetry tools, a fantastic plugin!