View Full Version : This has to be possible! (need an expert)
I wanted to control an orientation constraint's offset value, instead of being stuck with just the initial offset or nothing. So I wrote this simple script controller that does just that (with the help of a custom attribute for the offset that goes like this:
dependson $Dummy01
$Box1.offsetRotation + $Dummy01.objecttransform as quat
where offsetRotation is the custom attribute I am controlling dynamically elsewhere.
This works great with the dummy and the box, but when I apply it to the bone in the rig I'm working on, it will only rotate the bone in its local space. The bone is the end point of an IK chain and so the script controller is under the FK subcontrol/rotation, instead of the direct rotation. I can't find a way to override the tendency of the bone to align itself to its parent. Using "in coordsys world" does not work.
There has to be a way to assign world-space rotations to the bone, right!?
If someone out there can solve this problem, I will be eternally grateful and will bow down before your godlike Maxscript skillz.
|
|
Aearon
07-24-2005, 10:07 PM
the max way of doing this is the list controller (again :P )
you can use a euler controller on top of an orientation constraint to offset the rotation
Right, but the problem is that I need all three controls to be separate. I already have a list controller with a euler xyz and the script controller. A custom attribute elsewhere drives the weights of these two controllers, switching back and forth between them. I need to have the offset value be a third and separate value from the other two so it doesn't interfere when switching between the two controllers. Which is why I used the custom attribute for that.
My main question is, the Orient_Constraint figures out how to convert from local rotations to world rotations on this bone when I do it that way, so the math has to exist to do it, I just can't figure out how.
(Thanks for the reply)
Aearon
07-25-2005, 05:42 AM
Ok i thought what you wanted to was just that:
I wanted to control an orientation constraint's offset value, instead of being stuck with just the initial offset or nothing.
my solution does exactly that thing.
can you explain again what you try to do? which three seperate controls do you mean? three axis? weights?
What I mean by the three controllers is that I want the offset value to be independent of the Euler XYZ values. I want to be able to keyframe blend between (1)the Euler XYZ values and (2) the orient_constraint/scripted orient constraint (as posted above), with the orient constraint offset by (3) the offset value. I want (1) and (3) to be separate, independently key-frameable controllers.
Hmmmmm, maybe I just need two Euler XYZs in the list.... I'm going to try that.
Edit: nope, that doesn't work either. The rotations get all crazy and will not stay at 0.
I think what I really need is a formula to apply the "world coordsys" rotations of the target object to the local (parent) rotation space of the bone. I don't know if that makes sense... I've been trying to find out how to do this with quaternion and matrix math, and it hurts my brain....
Chinwagon
07-25-2005, 11:51 AM
You could orientation constrain an object between a) your constrained/scripted object with an euler xyz on top and b) the world. To have control as to how much offset in each axis you want, you could make each bezier controller in the euler XYZ a float list and wire the weight of each axis to custom attributes, etc.
Failing that, I would look into the expose transform helper (if you're in max 7 that is).
:¬)
mmm... yessss.... the Expose Transform helper.... I will have to look into that; I've never heard of it before. Thanks for the tip.
The best thing for this is use wieghted list controllers and control there weight with a slider or something.
The other issue is that they bone is part fo a hierachy and gains its axis based on its alignment. Where as a point and a box have an axis generally similair.
Right so you have 3 controllers right:
1 and Euler_XYZ
2 orientation constraint/script controller
firstly to blend between these two - have there wieght controller by a slider ala script:
So the first script goes on the first controller weight(eule_XYZ):
depends on $xxx.customAtribute
$xxx.customAtribute/100
The next controllers weight script:
depends on $xxx.customAtribute
1- $xxx.customAtribute/100
This will make a slider blend between the first two controllers weight.
Hmm im thinking if you added a float list to the orientation constraint and have its offset driven by a script. But i dont see why you can just add an euler_XYZ into the list and set active. It will still gain the constrain/script and your be able to move it around.
On top of this: you could drive the Euler_XYZ's with sliders, so you dont have to go into the stack and make them active.
my best bet would be: euler_XYZ[1]
contstraint/script/expression[2]
euler_XYZ[3]-set active
slider blends weight between [1] & [2] via a script on each weight [3] is left because its active. Then you need a controls to access [1] eulers axis'.
But you could even use controller instancing to get rid of the constraints /script if you just want it to follow another objects rotation. e.g
$point01.rotation.controller.X_rotation = $point02.rotation.controller.X_rotation
and so on.
You could even if you were special is to make[2] and euler and put and expression on each axis XYZ, and have something like this: a+b , a being you xxx.x scalar value you want it constrained to and b being the $other.x scalar value eg a point that controls the rotation independently.
This way you only need two controllers:
[1] - euler_XYZ
[2] - euler_XYZ (with an expression on each axis)
Then you blend the weight between each axis' expression and the [1] euler_XYZ
Becareful though and with bones and other object axis' maybe flipped so the bones x may be the points y and so on. So the wieght is driven by a script and the constraint is driven by and expression.
eek
CGTalk Moderation
07-26-2005, 01:42 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.
vBulletin v3.0.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.