I'm rigging a Poser figure that has several parts that were rotated in construction, that is, their natural axes are rotated from the figure X, Y, & Z axes.  I've adjusted the axes in the joint editor to where they should be so that rotations and scaling acts along the natural axes rather than the figure axes.  However, translation does not follow this.  For example I have a cylinder that I've re-aligned along the Z-axis.  When I z-scale it, it grows in length, that is, along the rotated Z axis.  When I move it using zTran, however, it move partially to the side.  Is there away to make the translation be along the axes as rotated using the orientation controls in the Joint Editor window?

Thanks lots.

am i right in thinking then when you imported the parts, they need to be imported with their axis correctly aligned with poser axis, ie, i know some modelling programs use x for z or y for -x, could this be causing the error, ? or maybe save the parts as props in poser first they should i think be constrained to poser axis before you reconstruct? I may be miles off, if so apologies.......on a positive note, i'm sure someone will correct me and provide you with the solution lol

Changing the orientation has no effect on translation it will always be along a world axis.

What is it that you are trying to achieve? There may be another way of doing it. Would you be able to post a screen shot of your figure?

This is a complex single mesh with many parts (destined as a market product).  One particular set of parts is a landing gear, illustrated here.  The first view shows the stowed position with the joint axes visible.  The scale parameters are hidden, but scaling does operate along the z-axis.  Moving along the z-axis (second view)  is off; the part is angled up 4 degrees, but the part moves as if the angle were zero.  The last view shows the strut rotated down before extending; the extension is off exactly as in the previous view. (The other parts of the gear have not yet been rigged, so they are just coming along for the ride.)  This is one of three gears. The other two are rotated along the y-axis complicating the problem.

I have modified the mesh so all three gear and their parts are aligned on the major axes.  I haven't begun this rigging but I should be able to adjust the part positions to correctly place parts and have them operate correctly in the final figure.

It would be great if there is a way to force the parts to move correctly by simply changing the axes.  Thanks for any thoughts.

(2nd & 3rd views follow)

2nd view

3rd view

I tested the same landing gear shown above using parts aligned with the cardinal axes. The parts now appear extend as I want them to.  I haven't tried the the other, more rotated assemblies, but they should follow as well.

I am still having a problem with some simpler parts.  These are single-part sliding doors.  The reallignment didn't work for these.  No matter how I rotate them, the movement is along the cardinal axis.  Apparently, the parent must be rotated to get the right movement.  These are parented to the top-level figure which I cannot rotate.

Still, more thoughts on this movement for both kinds of parts will be useful.

 

can you post a screen shot of the door set up,you have confused me slightly, are you talking about positioning the doors in the first instance or their actual movement? i would have imagined the movement was purely a z or x axis movement if they are sliding.

One trick that works in some situations  is to use ERC to slave one translation to another. For example slave the ytran channel to the ztran channel, so that when you spin the zTran dial the part also moves in the y direction. You can vary the amount of ytran for a given amount ztran by changing the value in the 'deltaAddDelta' line. For example placing the slaving code below in the ytran channel would cause the part to move one unit in the y direction for every four units moved in the z direction.  

            valueOpDeltaAdd
                Figure 1
                SomePart:1
                ztran
            deltaAddDelta 0.25000

The attached image shows the simple sliding door (red). It's rotated about 6 degrees and is supposed to move along the glide (narrow white rectangle) as indicated by the blue arrow on the left.  Moving in z only, it moves as shown on the right.  The relationship between x and z is simple trig, so lesbentley's suggestion will work and that is what I'm planning.  All movement will eventually be via ERC dials, so all this will be invisible in the end.  However, I usually get lost in the various levels of controls while I'm building them and would prefer them as simple as possible.  It would be so nice if the door would move along its internal axis as shown by the thin black cross hairs in both views. 

Thanks for all the interest.

> Quote - The relationship between x and z is simple trig...

To the mathematically challenged (eg, me), the words "simple" and "trig", have no place in the same sentence. If you are good at trigonometry, you can ignore the rest of this post. But for those who can't tell the difference between trigonometry and Sanskrit, read on.

I prefer to find the correct ratio empirically by using an adjustable ration and eye-balling it. The attached figure demonstrates the setup I use to determine the ratio.

In cube B, the ytran is slaved to xtran at one to one. Thus when the xTran dial is spun, the cube moves at 45 degrees to the horizontal. In the BODY is a channel named 'TMP', it multiplies the amount of ytran by the value on its dial. Thus with the dial set to 1.0 there is a ratio of 1:1, and with the dial at zero there is no ytran. This means that when I find the correct ratio by adjusting the TMP dial, the value on the dial is the value that needs to be used in the deltaAddDelta line of the slaving code. The code in the slave channel (ytran) is like this:

        translateY yTran
            {
            name ytran
            initValue 0
            hidden 0
            enabled 1
            forceLimits 0
            min -100000
            max 100000
            trackingScale 0.001
            keys
                {
                static  0
                k  0  0
                }
            interpStyleLocked 0

            valueOpDeltaAdd
                Figure 1
                B:1
                xTran
            deltaAddDelta 1.000000

            valueOpTimes
                Figure 1
                BODY:1
                TMP

            trackingScaleMult 1.000000
            }
I have the cr2 open in a text editor or cr2 editor. In Poser, when I find the correct ratio, I click on the numeric field of the TMP dial, Copy the value, and Paste it into deltaAddDelta line in the text editor. I then Cut valueOpTimes block of slaving code and Paste it into the next channel I need to determine the ratio for. When I have determined the ration for all necessary channels I Delete the TMP channel from the BODY. Here is what the TMP channel in the BODY looks like:

        valueParm TMP
            {
            name TMP
            initValue 1
            hidden 0
            forceLimits 1
            min -100000
            max 100000
            trackingScale 0.010
            keys
                {
                static  0
                k  0  1
                }
            interpStyleLocked 0
            }

P.S. The cubes in the attached cr2 are props parented to a BODY actor.

les, I gotta say none of my models would work without the master/slave parameter "tricks" I learned from you.  For example, I use a constant delay to open the landing gear doors before the gear starts to move.  Because the rotating linkage in the lowering mechanism is not uniform, I will need intermediate parameters to move them correctly.  There probably is a mathematical relationship between them, but I will be using your try-and-check method to find the values.

Another way to set the orientation of the translations is to interpose a ghost actor (an actor with no geometry) between the part of interest and its normal parent. The orientation of the translation will depend on the rotations of the parent, so rotating the ghost will determine the direction in which its child part moves.

In the attached cr2, the ghost part "B" has been zRotated by 25 degrees, and the child part "C" has been zRotated by -25 degrees to return it to its normal position. Both B and C were then Memorized. The result is that when C is translated, it will move at 25 degrees to the horizontal.

Normally after setting up the ghost actor at the correct rotation, you would hide it from the Poser menus thus:

    hidden        1
    addToMenu    0

In the attached file I have not hidden the ghost, so that you can play around with it.

I think the ghost actor method is particularly good if you need to change the orientation of all three axes.