Help - Reactor Controller

[tonygib]

hmmmm, now don't everyone all answer at once :shrug:

[tonygib]

OK, here is a little sample max 5 file that shows the problem.

With the animation driven by the IK control the Bone_Bottom object doesn't react to the rotation of the Lowerbone and hence doesn't move in order to re-shape the pinching of the skin modifier. So what can I do?

Test file:
http://antgib.f2o.org/3dimagery/shoulder.zip

[Reality3D]

You are right. The objects cannot react to indirect movements. So we need a workaround. The object will react to the angle between the two bones. How to get the angle?. There are different ways to do that, and there is a script that gets it for you here:
http://www.scriptspot.com/download.asp?ID=1279

This script creates two objects and using coordsys gets the rotation of the other. That value is all we need. But how to point out the reactor controller to this value. There are different ways. For example creating a custom attribute and assigning to it a script controller with the code that appears in the Angleextractor script, then react to this customatribute value

See the example below(i have quit the animation and the meshmooth to enter in the 20k limit)

[tonygib]

DUDE, thank you so very much, I've got the files and will have a play around. Not exactly an easy thing to do, but anything that makes it possible and hence automatic is a god send.

Out of CGtalk, 3dbuzz and the discreet forum you are the only reply I got. So once again, thank you.

[michaelcomet]

Yes this is correct. Max only allows wiring or reacting from controller to controller. The problem is as you mentioned the arm itself isn't FK animated...so you can't wire from the FK control. In addition, the IK system does not expose it's calculated rotation at all as a controller. So you can't directly react/wire from it.

The second slightly different issue is also that sometimes you want to know the rotation of an object relative to another object. For example if you want to do automated wrist-twist, then you need to know the hand controls rotation relative to the lower arm. In fact in most cases though the hand control is NOT a child of the lower arm. In that case you'd need to get world rotation data of both and kinda subtract it out.

I've actually been working on an Advanced Rigging tutorial about this stuff. It actually shows how to setup a Shoulder Pad Bone that rotates when the arm is above a certain point, even with IK. And also automated Wrist Twist. Both pretty much the same.

Grant's Angle Extractor sounds like it will do the job but does so with extra nodes and I am assuming a script. At that point you might as well just use a direct script which is what I teach, using basic Matrix Math that Max exposes.

To give a quick answer (you'll have to wait for the tut for the full thing, or ask questions back here and I will try to explain) Max does provide MAX Script abilty to read an objects world tranform matrix.

Basically this is the data that holds the FINAL version of the world space position, rotation adn scale. What this means then is regardless of how many controllers, IK, etc are on an object, you can find out it's rotation in the end....in world space.

Typically you need to know the rotation in "parent" space or relative to something else. For example if you just read the upper arm of the character in world, up down might be Y, but then if the character rotates forward it would be world X. You really want to know the rotation of that arm relative to the bone or spine it is parented to. To do that you get BOTH objects transform data, and then do the proper inverse math on it, and then extract the rotation.

Here is the basic code you will need.

$arm is the bone you want to read
$parent is the object or bone that you want to use as if it was parented to it. It doesn't HAVE to actually be the real parent. It could be another node somewhere else in the scene. But the code will calculate the rotation as if it was a child regardless.


dependsOn $arm $parent ;
matParent = inverse $parent.transform ;
matBone = $arm.transform ;
matResult = matBone * matParent ;
rotQuat = matResult.rotation ;
rotEuler = quatToEuler rotQuat order:1 ;
degToRad rotEuler.y ;

This will read the rotation in an XYZ ordering (order:1) and then return the .y rotation. Look up the MaxScript help for quatToEuler to see other orderings. Typically if you need to read a rotation, the stable axis will be the last one, or the middle one. Also be warned that in this case the order XYZ, so the rotEuler.y has the Y rotation. However quatToEuler actually not only figures out the rotation in the order you want, but also stores it into .x, .y and .z in that order. For example reading with Rotation Order of YZX, would mean that Y gets saved first, then Z and then X. Therefore the rotEuler.x = Y, rotEuler.y = Z and rotEuler.z = X. So if you wanted to know the true X rotation in that ordering, for say wrist twist, you'd have to use rotEuler.z to actually get at the real X rotation.

Hopefully this helps.

-comet

[michaelcomet]

BTW I forgot the idea here is that you assign this as a MAXScript controller to some other object's rotation...or to a custom attribute.

Then you could "react" to that attribute. The other thing to note is that the rotation will ALWAYS only return a value from -180 to +180. So you can go a full 360, but you may get a pop at the back, or if the object isn't properly aligned to the $parent ro zero'd out, it might flip earlier.

You could also for example add an if statement into the expression as well, and make it the actual rotation controller for the other object. For example:

dependsOn $arm $parent ;
matParent = inverse $parent.transform ;
matBone = $arm.transform ;
matResult = matBone * matParent ;
rotQuat = matResult.rotation ;
rotEuler = quatToEuler rotQuat order:1 ;
if (rotEuler.y <= -10.0) then
degToRad ( rotEuler.y - -10.0 );
else
0


Would make it so that the returned value is only rotating when the driving bone is above 10 degrees...

[Reality3D]

Good dissertation Michael :thumbsup:

[boomji]

thanks comet,
nice one ;)
hmmm... now where'd ah keep ma math book. :scream:
b

[pff]

Thanx Comet.

You have restored my faith in of the 3ds community :)
Looking forward to that tutorial!!!
Much needed in the community!

Btw, how´s the performance issue with script controllers compared to your Mayian-Constraint-Shoulder-Trick? Faster ya think?

Anyway fingers crossed for performance improvements in r6 :)

pff

[michaelcomet]

Well in Max r5 you would do what I posted above.

In Maya you could simply use an orient constraint, parented to the right thing and because Maya DOES report the proper values given whatever XYZ order you specify, it will work. And also that means it's all done via maya's own internal plugs/api. So obviosuly for that the maya version is faster.

You can't actually do matrix mult in a script in Maya like you cna in max. They do have a node for it, and actually in Maya the new "pointMatrixMult" commadn is actually just calling a script that creates a node, sets's attrs based on what you passed, then gets the attr back and then deletes the dunno.

I haven't really done any comparisons directly from r5 to Maya... but overall I think Maya does have faster, and more extendable and stable rigging ability.

imho.

[tonygib]

WOW, thanks very much for that Michael, I'm not at my system right now so will have to work through all that and give it a go.

As you guess, it is pretty much for a shoulder set-up of my little "extra" bits added on top of your charRigger.

I have given Grant's Angle Extractor a try and while it works fine on single rotation joints, like the elbow or knee, when I tried to use it on the upper arm/shoulder joint I got funny rotation readings. Like it was going from an increasing number to dropping back to increasing again all while the rotation was only going in one constant direction. It sounds like your solution will not have this problem :)

At the same time I can't wait for that tutorial, but I guess you are pretty busy.

I can see by a some of the other replies, that a few ppl had interest in this but just didn't know the answer, hence the lack of info.

It should be noted that I contacted Michael directly, as a last despreate option as I didn't want to interupt his busy work load, so it was great of him to spend the time and give such a full answer :beer:

PS. Yeah lets hope max 6 fixes some of this more complex rigging stuff and that skin modifier.

[Dave Black]

Over my head for the most part, but had to step in and say:

Ain't CGTalk great?!

:beer:

-3DZ

:D

[michaelcomet]

It sounds like maybe the axis order isn't or wasn't right for the grant tool maybe. Even the script I gave only returns values from -180 to +180. So at the back end you will get a flip problem...though usually if you set things up right that isn't a problem. Also using the proper axis order is critical. Depending on your joint alignments etc you may have to play with all 6 values and then al 3 x y or z components to find the match you need.

-comet

[tonygib]

Don't worry 3DZ, I don't understand any of the code either :) i'm just pleased as hell that it was even possible.

And I can report that based on initial tests it works a treat and doesn't seam to slow down low-poly animation/viewport feedback.

So, thanks again for that Michael and yeah, CGTalk rocks :buttrock:

EDIT

hehe, as I was first writting this, Michael was posting his last reply. To which I think you are right, I had something mixed around, wrong axis or something. Still, it all seams to be working so its all good. Now if I can just work out why the skin modifier keeps losing its Morph Angel deform Gizmo's or stuffing them up then I can get the knees and elbows to keep working correctly.

[pff]

tonygib:

also check out this thread i started a while back ;)

http://www.cgtalk.com/showthread.php?s=&threadid=71563&highlight=smart+skin


-->3DZealot "Over my head for the most part, but had to step in and say: Ain't CGTalk great?!"

yepp. it´s kinda difficult to grasp. trust Comet on good explanations in his upcoming tut tho i am sure he will perform at his best, right Michael :)?

pff

[tonygib]

cool, thanks pff.

Can't speak for 3DZ, but I sort of grasp it, guess I kinda had to, to be able to ask the right question in the first place. And to be able to apply what was posted to get the result that I was looking for.

However, there is no way in hell I would ever had come up with that code, my maths and understanding of max's interworkings don't go that far :) guess we are just luckly that Michaels understanding does go that far :cool:

[Dave Black]

*Puts on imaginary specticles to look more intelligent*

Eh hem.

While I do understand the overall concepts regarding this workaround, the higher level code eludes my somewhat limited mind. I will, of course, understand it with time.

Thanks for all the info, guys!

-3DZ

:D

[CGTalk Moderation]

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.