...if you don't like railways, track vehicles, bike chains, and conveyor belts. When you make a poseable railway model, track vehicle, articulated bike chain, or a similar model, you connect several elements, which travel at a fixed distance between each other along a curved motion path. A common method to create an accurately curved and timed motion path is to rotate the elements around a fixed pivot along the curves. Depending on the model, the curves of the motion path may be of different radii and may require different rotation centers of the elements. To create different rotation centers in course of the motion, you use either "virtual" joints (additional invisible elements), or variable rotation centers. Virtual joints produce large data overhead, and complicate the animation setup. To keep it simple, you might prefer fewer elements with variable rotation centers. Some animation programs support variable rotation centers, others don't. In Poser, you can't animate the rotation center of a prop or actor. On the other hand, most (if not all) animation programs support only a limited number of transformation channels per object, typically 3 rotation channels and 3 translation channels. If you want to create more sophisticated rotations, you have to use virtual joints (such as "Target Helper Objects" in Carrara, "Null Objects" in Lightwave and C4D, "Effectors" in EI Animator etc.). In Poser, you can use a virtually unlimited number of transformation channels per object. You can add several parallel rotation and translation channels for one prop or a single bodypart. Because of this unique feature, Poser can be a very powerful tool for complex motions of single-body objects and rigid multibody objects. Multiple parallel channels are useful, for example, to create animatable rotation centers in Poser. This tutorial explains, how to implement different origins at the same time, and how to create a variable origin.

Let's start with some well known facts: This example arrow prop is placed on the ground, and points to the sky. The ring at the bottom end of the arrow is at the center of the Poser scene. The coordinates of the center are x=0, y=0, z=0. The length of the prop is about 1 unit, and the upper end of the arrow is at coordinates x=0, y=1, z=0. Before you can rotate the arrow, you define the center of rotation (the "origin", or "Center Point"). The origin can be placed somewhere inside of the arrow body, or at some distance away from the arrow. The center of rotation is the pivot, a (virtual) point, which always stays in place, when the model rotates.

The "Origin" or "Center Point" can be defined either in the Joint Editor, or via the "Display Origin" option of a prop, and the "Origin" dials in the dial palette. If the arrow prop should rotate around the bottom end, the origin coordinates are x=0, y=0, z=0. If the arrow should rotate around the top, the origin is set to x=0, y=1, z=0. You can store the coordinates for one origin of a prop or actor. Once the origin is defined, you can animate the position of the model and rotate the model around the origin. But when you try to use the "Origin" dials to animate the origin of a prop, you will see that the origin setting changes throughout the entire animation. So, a prop has one non-animatable origin.

When you look at the code of a prop (the prop library or a document) you can see the following data related to the origin: - The origin coordinates are stored in the "origin" line (in the footer data after the channels). - The coordinates are also stored in six "Offset" channels. There are two blocks of Offset channels: Three "OffsetA" channels hold the x, y, z values of the origin coordinates. Three "OffsetB" channels hold the negative x, y, z values of the origin coordinates. By default, the OffsetA channels appear first in the code, followed by the Rotate channels (and Scale channels if available), followed by the OffsetB channels. We will see that the sort order of these channels is important, and how we can use it to control the origin. At runtime, when Poser loads the model, the origin coordinates are copied to the appropriate Offset channels. Then, the order of the channels is used to establish the script execution order. Poser will evaluate the channels in the code one after the other, starting with the first channel. The sequence of the channel evaluation is the script execution order. In the default configuration, the OffsetA channels are evaluated first, followed by the rotations (and scale deformations), followed by the OffsetB channels. The "Translate" channels (xTran etc.) are usually placed at the end of the code, before or after the OffsetB channels.

Whenever Poser updates the scene, the channels are evaluated according to the script execution order. When you experiment a little bit with the channel order, you can figure out how the offset channels work. When Poser starts executing the channels of a prop or actor, the center of rotation is assumed to be at x=0, y=0, z=0. This means: The channel evaluation always starts with an origin at the center of the scene. In the arrow example, the origin is first at the bottom end of the arrow, which is placed at the center of the scene. When the OffsetA channels are executed, the center of rotation is set to the origin coordinates, which are stored in the OffsetA channels (step 1). Poser uses the OffsetA channels to activate the origin of the prop or actor. In this example, Poser puts the center of rotation to the top of the arrow (the origin coordinates x=0, y=1, z=0). Next, Poser evaluates the Rotate channels one after the other (step 2). The order of the Rotate channels defines the so called "Rotation Order" (a very descriptive term, as you can see). The Rotation Order is only important, if more than one Rotate channel is set (not zero). The Rotation Order defines the gimbal lock behavior of the object, when several Rotate channels are set. In this example, the zRotate channel is set, so that the arrow prop rotates about the z axis, the center of rotation at the upper end. Next, the OffsetB channels are evaluated (step 3). These channels store the negative values of the origin coordinates. When the OffsetB values are added to the OffsetA values, the result is x=0, y=0, z=0. Poser seems to use the OffsetB channels to reset the previous origin (that is the center of the scene). When the last channel has been executed, Poser updates the scene and renders the new position and orientation of the prop. The moving origin and the evaluation of single channels are invisible to the user. Because of this, you can do virtually anything you like during the script execution. Only the final position and orientation of the model will be drawn to the screen.

Following the "script-execution-order" theory, we can insert Rotate channels in the code, which are evaluated, before the origin data is activated. This example code starts with a block of Rotate channels (xRotateA, yRotateA, and zRotateA). The OffsetA channels are next, followed by a second block of Rotate channels (xRotateB, yRotateB, and zRotateB). The code ends with the OffsetB channels. Note that you must rename the additional Rotate channels, so that all channels have unique channel names. The first block of rotations could be named "RotateA", the second one "RotateB", for example. When this code is executed, Poser starts at the default origin x=0, y=0, z=0, and evaluates the RotateA channels (step 1). At this point, the center of rotation is x=0, y=0, z=0. Thus, the arrow rotates around the bottom end, if zRotateA is set. Next, Poser evaluates the OffsetA channels. The origin data activates a new center of rotation, which is now x=0, y=1, z=0 (step 2). Next, the RotateB channels are evaluated (step 3). At this point, the center of rotation is at x=0, y=1, z=0. The arrow rotates around its upper end, if zRotateB is set. Finally (step 4), the OffsetB channels reset the origin (again x=0, y=0, z=0), and the scene is updated and rendered.

When you test the code, you will see it work as expected: You have two blocks of Rotate dials, which rotate about different centers. This tutorial uses the word "Poser Origin" for the official origin, which is defined in the Joint Editor, and stored in the "origin" line of the code. The word "Default Origin" denotes the primary origin at the center of the scene (x=0, y=0, z=0). When you set for example the zRotateA dial of the arrow prop, the arrow rotates around the Default Origin at the bottom end. zRotateA is evaluated prior to the OffsetA channels, so the Poser origin data is not yet activated. When you set the zRotateB channel, the arrow spins around the Poser Origin at the upper end. zRotateB is evaluated after the OffsetA's, so the Poser origin data is activated, and puts the center of rotation to x=0, y=1, z=0. Can you figure out what will happen, when you place the RotateA channels after the closing OffsetB channels? According to the script execution order, the RotateA channels should rotate around the center of the scene in this configuration, because the Default Origin is already restored (by the OffsetB channels), when the RotateA channels are evaluated.

The Default Origin is always at the center of the Poser scene (coordinates x=0, y=0, z=0). If the default position of a prop is some distance away from the center of the scene, and you use the Default Origin as center of rotation, the prop will orbit the center of the scene at a maybe large radius, like the earth orbits the sun. The "default position of the prop" means the position of the geometry stored in the geometry data (that is the vertex coordinates). You can see the default position, when all channels of the prop are at default value (1 for the scales, zero for other channels). The Translate channels ("xTran" etc.) move the prop along the x, y, z axes of the scene. The Tran channels are evaluated according to the script execution order. The Tran channels are usually placed after the Rotate channels in the code. So, Poser first evaluates the rotations, and then moves the prop to the values found in the Tran channels. Because of this, the standard translations carry the prop and the origin. The center of rotation seems to move with the prop. When you set for example a zRotate channel and the xTran channel of the arrow, the prop and the center of rotation move along the x axis. In the script execution order, Poser evaluates the Rotate channels, before the prop is displaced. Therefore, the Rotate channels apply rotations to the geometry at default position. Once the rotation is evaluated, the geometry including the modified orientation is moved to the new x position, the value of the xTran channel. Then the scene is rendered. You could say the Tran channels in this configuration move the prop including the origins (the Poser Origin and the Default Origin). So, a more accurate answer to the above question is: The Default Origin of a prop is at the center of the Poser scene, as long as all subsequent tran channels are zero. BTW, the Tran channels can be placed right before or after the closing OffsetB channels. In the standard prop code, the Tran channels are placed before the OffsetB block. In the standard figure code, the Tran channels of the actors are placed after the OffsetB block.

Tran channels, which follow the Rotate channels, move the prop geometry and the origins. To move the prop, but keep the origins at a fixed position, we can use a different configuration of the Tran channels. In this example, the Tran channels are placed at the very beginning of the code. When the xTran channel is evaluated, the prop moves for example to x=1. At this point, the Poser origin data is not yet activated (because the OffsetA follow), and the prop is at the default orientation (because no Rotate channel has been evaluated yet). Next, the OffsetA channels activate the Poser Origin (x=0, y=1, z=0 in this example), and the RotateB's are evaluated. If zRotateB is set, for instance, the prop rotates around the Poser Origin. The center of rotation is still at x=0, y=1, z=0, whereas the prop geometry is already at x=1 (because of the xTran channel evaluated before). When the scene is updated and rendered, the orientation and position of the prop is calculated from the new position of the prop after the x-translation, and the rotation about the Poser Origin. As a result, the prop always orbits the Poser Origin, wherever the prop geometry may be. The xTran channel in this configuration moves the prop geometry, but leaves the origin alone. The same is true for the RotateA channels in this example: The RotateA's are evaluated after the OffsetB's, when the Default Origin has been reset (to x=0, y=0, z=0). So, zRotateA always rotates around the center of the scene, wherever the preceding xTran has moved the prop before. Such initial Tran channels could be a bizarre method to create a variable origin. This is exactly what we're going to do a bit later. To sum up as far, the following rules are very likely to be true: - Rotate channels placed between the OffsetA and OffsetB channels rotate about the Poser Origin (official configuration). - Rotate channels placed before the first, or after the last, Offset channel rotate about the Default Origin, that is the center of the scene. - Translate channels placed before the first Offset and Rotate channel move only the geometry, not the origin. - Translate channels placed after the last Rotate channel move the geometry and the origin (official configuration).

Once you have two or more blocks of Rotate channel, which rotate about different centers, you can combine parallel rotations, to vary the resulting orientation and position of the prop. "Parallel rotations" means two or more rotations in the same dimension, for example two zRotate channels. Examples #1 and #2 show the arrow prop with the channel configuration RotateA - OffsetA - RotateB - OffsetB. In example #1 on the left, you first set zRotateA = 45, to bend the arrow. The prop rotates around the Default Origin (center of the scene). Then you set zRotateB. You "stack" two parallel rotations. The zRotateB rotation is added to the "preexisting" zRotateA rotation. The tilted prop rotates around the Poser Origin (center of rotation at x=0, y=1, z=0). In example #2 on the right, you first set zRotateB = 45 to bend the arrow. The prop rotates around the upper end (the Poser Origin). When you set the zRotateA rotation, you stack zRotateA onto the preexisting zRotateB. The tilted arrow rotates around the re-positioned Default Origin (center of rotation at bottom end of arrow). As you can see, the resulting motion of the prop is completely different, because your "sequence of use" is different: In example #1, you first use the zRotateA dial, then the zRotateB dial. In example #2, you first use the zRotateB dial, then the zRotateA dial. You apply the opposite sequence, to set the parallel Rotate dials. The word "preexisting rotation" denotes the first zRotate channel, which is already set (not zero), when you are going to set the second zRotate channel. In example #1, zRotateA is the preexisting rotation. In example #2, zRotateB is the preexisting rotation. Don't mix up the "script execution order" with the "sequence of use": The script execution order is the order of the channels in the code. The sequence of use is the sequence you apply, to set the Rotate dials. Therefore, you can choose a channel configuration (script execution order), and a sequence of use, to create four rotation variants. Examples #3 and #4 have the "opposite" channel configuration OffsetA - RotateB - OffsetB - RotateA. In example #3, you first use zRotateB, then zRotateA. zRotateB is the preexisting rotation. In example #4, you first use zRotateA, then zRotateB. zRotateA is the preexisting rotation.

The Default Origin is especially useful, if you want to rotate about two centers at the same time. When you set or animate parallel RotateA and RotateB channels together, you can create very interesting motion paths. However, you rarely need two rotation centers at the same time. And the Default Origin requires a specific default position of the prop geometry in the scene, since the center of rotation is based upon the center of the scene. Because of this, the Default Origin is not always helpful. You can use parallel channels to create a variable origin, that is, one animatable center of rotation. A property of a prop or actor is animatable (in Poser 4), if you can use a parameter dial (other than an "Origin" dial) to modify the property. Suppose you make a poseable railway model. The train should first rotate clockwise at radius R1, to move along a curve. The rotation center lies on the right at distance R1. Next, the train should rotate counter-clockwise at radius R2, to travel along the next curve. Now the rotation center is on the left at distance R2. The origin should be variable, to support different radii and rotation directions in course of the motion. If you try to modify the Poser Origin, the modified origin will always affect the entire animation (this is a static, non-animatable property). The train actors are not positioned at the center of the scene (and different wagons are at different default positions), therefore the additional Default Origin won't help. What you need is a variable origin, derived from the Poser Origin.

The Poser Origin is very sticky: The OffsetA channels always evaluate to the Poser origin data. Once the Poser Origin is set, it's the center of rotation for all subsequent Rotate channels. Since we cannot move the Poser Origin, we will move the prop geometry instead, to fake a new center of rotation. The picture shows on the left the arrow prop and the Poser Origin at x=0, y=1, z=0. This arrow rotates about the upper end. On the right, the prop geometry has moved by y=0.5, and the origin is still at x=0, y=1, z=0. This arrow rotates about the center of the arrow body, so we have a different rotation center. We already know, that the prop can move without the origin. And we know we can do virtually anything, before Poser updates and renders the scene. Only the result of all channel evaluations will be visible in the end. So, all we need are some channels, to - translate the prop geometry temporarily without moving the origin, - evaluate the rotations, - and reset the prop to the previous position.

This code example creates an origin, which is variable in the y dimension. You can see the coordinates x=0, y=1, z=0 of the Poser Origin in the "origin" line of the code. The Poser Origin is again at the upper end of the arrow. To create the variable origin, we include two common "yTran" channels with unique names, "yCenterA" and "yCenterB". Both yCenter channels are linked with ERC slave-code, because they should always move together. The ERC code is not really required in an animation, you could as well move both dials manually to the proper keyframe values. When the code is executed, Poser first encounters the yCenterA channel. yCenterA moves the prop geometry without the origin. When you set yCenterA, you create a new y distance between the origin and the prop geometry. Then, the OffsetA's activate the Poser Origin. Next, the rotations are evaluated. The new y distance between the prop and the origin defines the radius of the rotation. "Radius of the rotation" is just another word for "the rotation center in local coordinates". Therefore, the yCenterA translation defines a new center of rotation. Then, the yCenterB channel is evaluated. yCenterB is the opposite of yCenterA. You don't want to see any y translation in the end, so you need to compensate for the yCenterA translation. yCenterB is the negative value of yCenterA (that is the value of yCenterA with opposite sign). yCenterB resets the prop to the previous position. The two yCenter channels work in the same way as the Offset channels (OffsetB is the negative value of OffsetA, to reset the Default Origin). The ERC slave-code moves yCenterA to the negative value of yCenterB. Usually, yCenterA (the first yCenter channel) is the ERC slave, and yCenterB (the second yCenter channel) is the ERC master. The user can move the dial of the yCenterB master, to set the variable origin. The channel value of yCenterB is the vector, which starts at the Poser Origin and points at the new origin. "Vector" means, the value and the sign (plus or minus) of yCenterB describe the way from the Poser Origin to the new origin: Negative yCenterB values place the new origin below the Poser Origin. Positive yCenterB values place the new origin above the Poser Origin. If you make the origin variable in the x dimension or z dimension, the motion direction of the origin expressed in the sign of the CenterB channel is equal to the motion direction of the model expressed in the sign of the standard Tran channel.

The origin of this example arrow is at the upper end of the arrow (x=0, y=1, z=0). You want to place the new origin (the yCenter origin) in the center of the arrow body, at y=0.5 (instead of y=1). When the script is executed (execution order from left to right in the picture), yCenterA lifts the prop geometry by y=0.5. The center of the arrow body moves from y=0.5 to y=1. Next, the OffsetA channels are evaluated, and the Poser Origin becomes the center of rotation. Next, the rotations are evaluated. Since the center of this rotation is also the center of the arrow body, the arrow rotates around its center. Next, yCenterB is evaluated, which resets the yCenterA translation. So, yCenterB lowers the prop geometry by y=-0.5, and the center of the arrow body moves back to the previous position from y=1 to y=0.5. Finally, the OffsetB channels reset the default origin, and the scene is rendered. The yCenterA and yCenterB translations are invisible: They are both evaluated, before the scene is rendered, and both motions cancel each other out, so the prop is at the same y position before and after the scene update. When you look at the arrow after the channel evaluation (rightmost in the picture), you cannot really see where the rotation center was. Could be the green cross, or the green dot. You can't see the center of rotation in this picture, because you don't see any "world coordinates", so you can't decide where the arrow is in the end. The rotation center depends on your point of view, and it's all a question of positioning the prop in the scene. The green cross displayed by the Joint Editor and the "Display Origin" option is the Poser Origin. The green cross doesn't move, when the new yCenter origin is set. The green cross reflects the origin data stored in the "origin" line of the code, which is not modified by the yCenter channels. When you display the green cross, and rotate the prop around a new yCenter origin, the Poser Origin seems to orbit the new center of rotation. What you see is in fact an optical delusion caused by the yCenter translations during the script evaluation.

At first glance, the yCenter channels work very well. The picture shows different settings of the yCenterB master, and the resulting zRotations. At yCenterB = 0, the Poser Origin is the center of rotation. You can set yCenterB between 0 and -1, to move the yCenter origin between y=1 and y=0. Or you set yCenterB to positive values, to move the yCenter origin from y=1 towards the sky. However, the yCenter origin only works, if zRotate is zero: To use this variable origin, you have to rotate the prop to the default orientation (all rotations are zero). Then you can choose the yCenter origin. Then you can rotate around the new center of rotation. When you set a Rotate channel, and then try to modify the origin, you can see some displacement of the prop. If there is a preexisting rotation, the yCenter channels will create a visible translation of the prop.

The displacement side-effect mentioned above is not a bug in the yCenter channels. The same occurs, when you modify the ordinary Poser Origin. Suppose you have carefully arranged your arrow prop in the scene. Then you want to modify the origin a little bit. So you change the origin data just a little bit, but the stupid prop drifts from its position, and you can start all over again. This annoying "phantom motion" is not a Poser bug, it's the effect of re-evaluated rotations (or scales). The phantom motion occurs, whenever a rotation (or scale) channel is set, and then a new origin is defined. The preexisting rotations (and scales) are differently evaluated, to reflect the new center of rotation. Because of this, the prop is displaced and re-positioned, which looks like a spooky translation. The example arrow shown has a preexisting rotation, that is, zRotate is 45. The origin is at the upper end of the arrow (y=1). When you move the origin to y=0.5, the center of rotation moves towards the ground. Since the new center of rotation (y=0.5) lies in the center of the arrow body, the arrow moves, to bring its center to the position of the new origin. In this case, the phantom motion looks like a translation along the y and x axes.

Usually, the displacement effect is not at all welcome. When you modify, for example, the rotation centers of the train model, so that the wagons can travel along the next curve, any displacement effect would ruin the motion. What you want is - to rotate the wagons to an arbitrary orientation, - then choose a new origin, avoiding any errant phantom motion, - then go on rotating the wagons, now using the new origin as center of rotation. The improved code is basically the yCenter-origin-method. The new code has a second zRotate channel, and an additional xCenterB channel. This post explains the channels and the script execution order. The following post will show how to calculate the values. The code starts again with the initial yCenterA channel. This is a common yTran channel, which moves the prop geometry to a temporary y position. Then the OffsetA's are evaluated, and the Poser Origin is activated. Next, the rotations are evaluated. This time, there are two parallel zRotate channels. Both zRotate channels rotate about the Poser Origin, which is activated at this point. Next, the xCenterB and yCenterB channels are evaluated. They reset the prop geometry from the temporary y position to the previous y position. The "sum" of the xCenterB and yCenterB channels is the opposite (the negative value) of the yCenterA channel. Finally, the OffsetB's reset the default origin, and the scene is rendered. The parallel zRotate channels are used, to rotate around the Poser Origin, and the new variable origin. But how can these channels rotate about different centers, as they are both evaluated at the same point in the script execution order? Well, the rotation center depends on the values of the three Center channels, when you are going to set one of the Rotate channels. Your "sequence of use" makes the difference. Thus, to rotate around different centers, you must apply a specific sequence when using the dials: 1. Set all Center channels (yCenterA, xCenterB, and yCenterB) to zero. 2. Then use the first rotation, that is channel zRotateA, to rotate around the Poser Origin. Since all Center channels are zero, they have no effect. So, zRotateA is an ordinary z-rotation around the ordinary Poser Origin. You could even use the zRotateB channel at this point, which works exactly like zRotateA. The first rotation, zRotateA in this example, is the "preexisting rotation". This means, zRotateA is already set (not zero), when you're going to switch origins. The second parallel rotation, zRotateB, must be zero, when you're going to switch origins. 3. Then you switch origins. To define the new origin, you choose appropriate values for the three Center channels. The Center channels activate a new origin, such that further rotations use a different center of rotation. In the script evaluation, the yCenterB channel simply resets the prop geometry to the previous position. Therefore, yCenterB should be the opposite of the yCenterA motion. But this time, there is a preexisting rotation (zRotateA is already set, when you switch origins). So you get a phantom motion. The CenterB motion must create the opposite of the yCenterA motion, and at the same time compensate for the phantom motion. We need two channels, xCenterB and yCenterB, to create the proper reset translation. 4. Next (in your sequence of use), you set the second zRotate channel, zRotateB, to rotate around the new origin. At this point, you can no longer modify the preexisting rotation (the value of zRotateA), because the Center channels create the proper reset motion for one specific zRotateA value. Therefore, you have to use a second parallel zRotate channel, to rotate around the new origin.

The variable origin is made of two Rotate channels, which rotate around different rotation centers. The first center of rotation is the standard Poser Origin, i.e. the origin coordinates you define for example in the Joint Editor. The second center of rotation is defined by the values of the three Center channels (yCenterA, xCenterB, and yCenterB). When you use the model, you apply the dials in a specific sequence: You first set the zRotateA rotation, next you set the Center channels to switch origins, then you use zRotateB to rotate around the new origin. The first rotation (zRotateA channel) rotates around the Poser origin. In the arrow example shown, you use zRotateA, to rotate the prop by 45 around the Poser Origin (the bottom end of the arrow at x=0, y=0, z=0). zRotateA is the preexisting rotation, when you switch origins. We express the preexisting rotation in angle "alpha". Alpha is the angle between the default orientation of the prop and the preexisting zRotateA rotation. If you make an animation, angle alpha is the value of the RotateA channel at the point, where you want to switch origins. In the railway example, alpha is the RotateA value of a wagon, which has finished the first curve, and is about to move along the next curve at a different radius. To define the new origin, you calculate the value for the yCenterA channel. The formula is: yCenterA = PoserOrigin - yCenterOrigin To calculate yCenterA in the arrow example, you find out the y coordinate of the Poser Origin. This is the y value of the origin data displayed for example in the Joint Editor (y=0 in this case). Then you define the y coordinate of the new origin, the yCenter origin. You want for example the yCenter origin in the center of the arrow body at y=0.5. As the Poser Origin is y=0, and the yCenter origin should be y=0.5, you find yCenterA = 0 - 0.5 = -0.5 Be careful with negative values: If the Poser Origin is y=1, and the new origin should be y=-0.5, the formula evaluates to 1 + 0.5 = 1.5. The result is the value of channel yCenterA at the point, where you switch origins. Then you calculate the corresponding values for the xCenterB and yCenterB channels. The equations use the value of the zRotateA channel (i.e. angle alpha), and the value of the yCenterA channel: xCenterB = yCenterA * sine(alpha) yCenterB = -yCenterA * cosine(alpha). In the arrow example, alpha (that is zRotateA) is 45, and yCenterA is -0.5. Therefore, the formulas evaluate to xCenterB = -0.5 * sine(45) ? -0.3535 yCenterB = 0.5 * cosine(45) ? 0.3535. The formulas work with positive and negative alphas. The resulting values are the channel values of the CenterB channels at the point, where you switch origins. Once the three Center channels have the proper values, you can rotate the arrow using the zRotateB channel. In this example, the new center of rotation (the yCenter origin) is at the center of the arrow body (the green dot). So the tilted arrow rotates around a new center without any errant phantom translation. You can set the variable yCenter origin to any value, and switch at any preexisting zRotateA rotation. However, once the Center channels are set, further zRotateA rotations will generate phantom motions. Your Center channel values match a specific angle alpha (zRotateA value). If you change zRotateA, you get a new angle alpha, which requires different values of the three Center channels. The picture maybe helps you to better understand the math of the two CenterB channels: When the rotations are evaluated, the yCenterB channel should reset the geometry to the previous position. yCenterB is the opposite (negative value) of yCenterA, such that the yCenterA and yCenterB translations cancel each other out. To compensate for the phantom motion, the yCenterB reset motion is a motion vector consisting of an x component ("delta x" in the example) and a y component ("delta y"). Delta x is the value of the xCenterB channel, delta y is the value of the yCenterB channel. Only the sum of both components creates the exact opposite of the yCenterA motion. When yCenterA is evaluated, the prop geometry is at the default orientation, so the yCenterA motion vector is a vertical line along the y axis. A vertical line is one motion component, that is one yTran channel. When the yCenterB channel is evaluated, the prop is bent (because of the preexisting zRotateA rotation). Now, the yCenterB motion is a diagonal line between the y axis and the x axis. To create a diagonal motion, you need two Tran channels, therefore you have yCenterB and xCenterB channels. Some preexisting rotations, for example zRotateA=90, have a horizontal reset translation along the x axis. Thus, you need only the xCenterB reset translation, but no yCenterB reset translation. If you wish a variable origin for yRotate instead of zRotate, the Center channels are different dimensions: The Center channels are the axes of the rotation plane. For a zRotate channel (the arrow example), the x and y axes are the axes of the rotation plane, so you have xCenter and yCenter channels. For a yRotate channel (the railway example), the x and z axes form the rotation plane (this is the ground plane). So you use xCenter and zCenter channels, to animate the origin of the yRotate channel.

Attached Link: arrowprop.zip (4 KB)

The above formulas are very handy, once you know, where you want to move the variable origin. But when you test many different origin settings, you have to calculate and adjust the channel values again and again. Sooner or later, this will become an annoying task, even if you are a very patient being. Fortunately, the formulas are simple enough, so we can use ERC code, and let Poser calculate the values and adjust the channels. The picture shows the channel scheme for the arrow example. The code is made of the same Center channels again. I have added ERC slave-code for the CenterB channels, and some more channels, to evaluate sine and cosine of the zRotateA value. This time, the yCenterA channel is the ERC master. When you work with the model, you can set the yCenterA dial, to move the variable origin along the y axis, and create different rotation centers for the zRotateB rotation. Note that yCenterA moves in the "wrong" direction: Negative yCenterA values lift the origin. Positive yCenterA values lower the origin. To make a more user-friendly interface, you can add an extra master dial, and slave yCenterA to the new master, specifying deltaAddDelta -1. Thanks to the "new" valueOperators (valueOpPlus etc.), we can write code to evaluate sine and cosine of zRotateA. As the algorithm calculates with radian values, the value of zRotateA (degrees) is converted to radian. Then sine and cosine are evaluated. The code needs 20 channels (not shown in the picture). Finally, the xCenterB slave is set to yCenterA * sin(rad(zRotateA)), and the yCenterB slave to -yCenterA * cos(rad(zRotateA)). You can download the example arrowprop.zip (4 KB) to test the code. Use dial "zrotA" (channel zRotateA) to rotate around the Poser origin. Move dial "SetOrigin" at any time, to choose a new origin. "SetOrigin" is the master of yCenterA. Once you have set the preexisting zRotateA rotation, and the new origin, you can use dial "zrotB" (channel zRotateB), to rotate around the new origin. This version of the code can be used for -90 < alpha < 90, i.e. zRotateA can be set between -90 and 90. If you want an automatic variable origin for a wider range of alphas, you need more code.

This post isn't an explanation, but a warning of a potential pitfall. The track model shown is made of many track elements, which move along the track shape. It's not very obvious, but the elements need two slightly different origins, to travel properly along the rollers (radius R1 is 0.17362, radius R2 is 0.16982). This track model needs more consideration, because the elements have a specific default orientation. Some of the elements are neither vertically nor horizontally oriented. The variable origin method works for models, which rotate around the main axes of the Poser scene. The "local coordinates" and the "world coordinates" should be aligned. You can easily rotate the local coordinates in relation to the world coordinates, when you set "Orientation" angles in the Joint Editor, or modify the "orientation" data stored in the code. If you modify the default orientation (use "Orientation" angles other than zero), the variable origin will not work. So, if your model really requires special default orientations, you can't use this technique to create variable origins. Whenever your model will work at default orientation, don't modify the default orientation. In the track example, you should not modify the default orientation of the elements, although this might appear to be useful. The above code is a basic variant of the method. It works for simple models like the arrow prop. When you develop variable origins for the track elements, or for the links of a bike chain, you need to adjust the code due to the odd default orientation of some elements. The CenterA translation of such element is always a motion vector of two components (a yCenterA and a zCenterA channel in this case). Thus, the CenterB reset translation also consists of two channels, even if there was no preexisting rotation. Since each element has its own preexisting rotation, when you switch origins, the CenterB reset motion of each element should also compensate for a different phantom motion. You don't need additional CenterB channels, but different formulas to calculate the reset motions.

Attached Link: flagprop.zip (73 KB)

That's it. If you were so courageous and took the time to wade through the above stuff, you can download this poseable flag freebie (hero not included). Use dial "Wave" to wave the flag. "Amplitude" adjusts the amplitude, "Turbulence" adds some turbulence. "Falloff" decreases the wave amplitude towards the attached end of the flag. If you want to texture the flag, you need to retrieve a texture template: Rename "flagprop.pp2" to "flagprop.obj". Open "flagprop.obj" in UVMapper. Use menu "Save Texture Map" to save a texture template. Choose a square bitmap format (Width = Height) and save the template.bmp. Be sure you don't save the model to "flagprop.obj" in UVMapper, otherwise you lose the prop data. Rename "flagprop.obj" back to "flagprop.pp2" when you're done. Paint on the texture template to create a texture map, and apply the texture map to the flag prop in Poser.

Thank you so much for this, I had to print this one out...truly a keeper. Sharen

Aw man, I haven't even finished reading it and now I have to go to work. This is just what I've been looking for. Thank you

Head hurts. Must - lie - down - in - darkened - room. :) Thank you VK. Can I download the prop now, or do I have to demonstrate that I understood everything first?

EnglishBob, when you arrive here, you are entitled to download the prop. Congrats to you and the 8 folks who made it :))

VK, I'm sure more have come, they are probably still unconscious.

lol! hey, vk, want to write the sequel to my book??? ;) now with the tread-thing, somebody got a cylinder to work in that instance, by parenting magnets to the gears. as the cylinder rotates through the magnet zones, the magnets pull it into the proper shape. also, as the there gear things move, they pass their magnets and zones through the cylinder to keep it in the right shape. of course, this wouldn't work with your train track example. :)

I've copied & pasted this thread into Word and saved it case I ever need it. Thanks VK!

WOW!!! This is awesome stuff, VK. Thanks for posting it :-)

Awesome work! I'm used to poking around inside the mathematics of CR2 channels - but this definitely extended my knowledge of what can be done in Poser :-) And you have such patience to make all those tutorial diagrams...

...but I do know that this bodes well for some neat new products. Thanks VK! I'm bookmarking this one so I can go though it after some vitamins, a good nights sleep, a pot of coffee, and an evergy drink. I think there are more implecations to this than just treads....

Wgrmkquoky - I mean wow, that scrabbled the grey cells. :O)

I just love this sort of thing. I just finished Denis's (allstereo) tuts on Poser's Dependent Parameters and got a ton of in depth understanding out of it. This is one of the reasons I stay with Poser (despite it's instability, goofy interface, lack of new content, etc). You never see technical discussions of this depth for Daz. I guess they want folks to guess how it all works. This will go a long way with helping me rig my you-really-don't-want-to-know-but-it'll-be-for-sale-on-pervertosity-soon gizmo. Have you folks ever considered writing a book? B.L. Render's "Secrets of...for Poser 8" is still topical but getting long in the tooth.
Thanks for taking the time to write this.