# Thread: Pivot Rotation and Compensation...

1. ## Pivot Rotation and Compensation...

I have a small problem.

I have a Motion modifier lscript, which targets and poles with blending quite nicely... if there isn't a pivot rotation involved. Once I try compensating for the pivot rotation, things, to quote RH, "...Go rather wrong." I'd like to be able to use it in some CA projects, overcoming a lack of internal support for blending targets and poles in lightwave itself.

If I am understanding how Pivot rotations work, they are added to the HPB values internally before the rotation transformation is computed, and subtracted from the rotation information before it is displayed or reported back. (IE, a bone with HPB of <0,0,0> and a Pivot Rotation of <0,0,-90> is acutally @ to <0,0,-90> WRT it's parent).

The problem is the axis are now 90 degrees off. Heading is now equal to Pitch, Pitch is equal to Heading. Rotating the rotation value doesn't appear to work - I get it pointing in the right heading, (towards the target, in the xz plane) but nothing else.

I'm using targetobject to point towards my target (which works rather nicely, but it only gives me a heading and pitch value - bank appears to always return ~0 - and it doesn't compensate for the pivot rotation. A little bit of vector math and some rotation gives me a pole angle (there is probably an easier method than what I do - get the actual pole vector, make it perpendicular to the target vector, and rotate it back to <0,0,0>, to get my bank angle, using dot3d and acos...) trying to compensate for the pivot rotation makes thing go rather weird from there.

Any ideas? Can someone who knows the math / how it really works give me a few hints in the right direction?

2. While I am still interested in the math behind Targeting and Pole Vectoring (It must be an interesting solution...), I came up with a rather simple solution to my problem...

I thought, Lightwave already does the computations, is there any way I can set the target and pole, get the values, and reset them, and not cause things to flicker and flip around? As a matter of fact, there is...

Code:
```	SelectItem(my_obj.id);
if(targ){
//Turn On the Target, if we have one...
TargetItem(targ.id);
HController(2);
PController(2);
TargetItem(targ.id);
}
if(pole){
//Turn On the Pole, if we have one...
PoleItem(pole.id);
BController(6);
PoleItem(pole.id);
}
//Update Motions, but do not refresh screen
UpdateMotion();
//Grab the computed H,P,B rotations!
tv = my_obj.getRotation(time);
if(targ){
//Turn off the target
TargetItem(0);
HController(1);
PController(1);
}
if(pole){
//Turn Off the pole
PoleItem(0);
BController(1);
}```
Does it quite nicely, without mucking around in all that trig and vector math. You do have to remember to re-select whatever object you're manipulating before you exit the process UDF, but it works! ~yay!~

3. Unfortunately, while the above does work, it does so with some serious jerkiness involved. I've since cracked the problem, using the Up and Forward vectors. A neat little bit of math, which works wonderfully.

Why am I going through all this trouble? I want blendable pole vectors and targets. Lightwave doesn't have them natively, and one means of getting them has issues of it's own (PLG_IK has some refresh issues, which may be related to what follows...)

However, this brings up another question...

I have an item acting as a target. I'm using effectedby() to let the motion modifier know that this item directly effects the lscript. However, this item is part of a hierarchy (heel -> ball - -> tip -> pivot -> goal -> target). Do I need to include the entire chain to effectedby(), since all the items higher than target effect it?

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•