Attached Link: http://www.atlantis23.com/bezierpath.zip

The idea was to make a "motion path" figure consisting of two (or more) 3D Bier curves. The motion path figure defines the knots and control points of the curve, and calculates the coordinates of a point moving along the curve. The moving point is body part (actor) "dummy" of the path figure. To move an object on the path, the object is parented to actor "dummy" and then the "Plot" dial is animated.

Two connected Bezier patches are two (cubic) Bezier curves which share one end point. So, we have three "knots" (points) A, B, C placed somewhere in space. A is the start point, B is the end point of the first Bezier curve and the start point of the second Bezier curve. C is the end point of the spline. Each knot has one "control point" ("CP") aa, bb, cc placed somewhere in space. The CP defines the direction and shape of the curve. The connection (knot B) is tangent continuous to create a smooth transition between the patches. Therefore, the middle CPs are always symmetrical relative to knot B. The user adjusts CP "bb" to define both CPs and the shape of the curve in the region of knot B. To plot the curve, the code calculates the curve coordinates from knot A to B and then from knot B to C. The calculation is based on 7 parameters, that is 7 sets of (xyz) space coordinates along the entire curve, starting with "a_parm" for the first knot, ending with "g_parm" for the third knot as shown in the picture. I tried to avoid angles as far as possible, because the angle/coordinates conversion requires complicated calculations. Hence, the user sets the (xyz) coordinates to define the curve parameters and the shape of the path.

The user can rotate the entire motion path about the starting point, knot A. Knot A defines the parameter space of the curve. At the default position (no rotation angles), the curve space is the world coordinate system. The path starts at the origin and moves to the right (along the x-axis). To define the path, you rotate the curve if necessary and enter the (xyz) coordinates of the knots A, B, and C. All dials are on "BODY". The knot-coordinates are distances relative to the previous knot. For example, coordinate "B_x" defines the x-distance between knot A and B. Coordinate "C_z" defines the z-distance between knot B and C. Each knot has one associated control point "aa", "bb", "cc". To define the CP's, you enter the (xyz) coordinates of the CP. Note that the CP coordinates are distances relative to the associated knot. For example, to create a nice curved path in the xy-plane between knots B and C, you choose a positive "bb_x" coordinate and a negative "cc_x" coordinate as shown in the center of the above picture. The CP coordinates define the position of the CP, i.e. the distance from the knot *and* the rotation angle (direction) of the curve tangent in the knot region. Some models have additional dials "aa_scale", "bb_scale", "cc_scale". The CP scale dials can be used to adjust the distance between the CP and the knot, and preserve the direction of the tangent.

To plot the path, you move dial "Plot" from 0 to 2 or animate the "Plot" channel. This moves actor "dummy" along the curve. "dummy" is just a moving little arrow so that you can see how the motion path looks like. In the end, you parent a more interesting prop or figure to actor "dummy" and hide "dummy" to animate the motion of the parented prop or figure. "Scale" scales the motion path. Higher "Scale" creates longer distances between the knots. "ScaleBits" scales the geometries of the knots and handles and preserves the distances. "ScaleBits" does not modify the shape of the motion path, it's only used to adjust the size of the bits in the scene when you are developing the path.

There exist different versions of the code. And frankly, I've lost track of the versions when I left the unfinished project last year. Basically, there is a simple code variant. According to my notes, the latest version seems to be used in model "BCPolyCode3.cr2". It's made of three parametric functions ("Bernstein" polynomials) to compute the (xyz) coordinates of a point P on the Bezier curve, and the derivatives of the curve. The code is simple and straightforward. The formulas for the first Bezier patch are Qx = 3 * (x1 - x0) Rx = 3 * (x2 - x1) - Qx Sx = x3 - x0 - Qx - Rx Qy = 3 * (y1 - y0) Ry = 3 * (y2 - y1) - Qy Sy = y3 - y0 - Qy - Ry Qz = 3 * (z1 - z0) Rz = 3 * (z2 - z1) - Qz Sz = z3 - z0 - Qz - Rz where Q, R, S are coefficients for the polynomials, (x0,y0,z0) are the coordinates of the first knot "A", (x1,y1,z1) are the coordinates of the first CP "aa", (x2,y2,z2) are the coordinates of the second CP "bb", and (x3,y3,z3) are the coordinates of the second knot "B". The parametric functions are cubic polynomials, the parameter "p" moves from 0 to 1 for each Bezier patch: x(p) = Sx * p^3 + Rx * p^2 + Qx * p + x0 y(p) = Sy * p^3 + Ry * p^2 + Qy * p + y0 z(p) = Sz * p^3 + Rz * p^2 + Qz * p + z0 The derivatives are then: dx(p) = 3 * Sx * p^2 + 2 * Rx * p + Qx dy(p) = 3 * Sy * p^2 + 2 * Ry * p + Qy dz(p) = 3 * Sz * p^2 + 2 * Rz * p + Qz. Since the first knot "A" is always at coordinates (0,0,0), factors x0, y0, z0 can be removed from the formulas. Unfortunately, the auto-bank mechanism of this model is not very reliable. The slope of the curve based on the dy/dx and dz/dx derivatives is analytically accurate. But the calculation yields poor result under some conditions, as you will easily notice if you try out the "BCPolyCode3.cr2" model. Errors become obvious when you set up a curved 3D path like the irregular helix shown in the picture.

The point P (actor "dummy") moving along the path should be oriented on a tangent relative to the curve. The simple code variant calculates the derivatives dx, dy, dz of each Bezier patch and then uses "arcustangent" functions to derive two rotation angles "alpha" and "beta". The atan() function is the continued fraction shown in the picture which approximates the function result. Angle "alpha" is the rotation angle of the object about the z-axis of the curve space (pitch orientation). Angle "beta" is the rotation angle of the object about the y-axis of curve space (yaw orientation). The ERC code of the atan() function for angle "alpha" is listed below. All names are internal channel names. Each equation means a channel. The right side of the equations are the valueOp operators. Numeric values mean dial values or deltaAddDeltas. The left side of an equation is the name of the embedding slave channel. // lines are comments: // atan(tanalpha) // dy_var and dx_var are derivatives of the curve tanalpha = dy_var / dx_var xz_atan_mult = tanalpha xz_atan_sqr = tanalpha * xz_atan_mult xz_addat_1 = 21 + (xz_atan_sqr * 1.21) xz_atan_1 = 100 * xz_atan_sqr / xz_addat_1 xz_addat_2 = 19 + xz_atan_1 xz_atan_2 = 81 * xz_atan_sqr / xz_addat_2 xz_addat_3 = 17 + xz_atan_2 xz_atan_3 = 64 * xz_atan_sqr / xz_addat_3 xz_addat_4 = 15 + xz_atan_3 xz_atan_4 = 49 * xz_atan_sqr / xz_addat_4 xz_addat_5 = 13 + xz_atan_4 xz_atan_5 = 36 * xz_atan_sqr / xz_addat_5 xz_addat_6 = 11 + xz_atan_5 xz_atan_6 = 25 * xz_atan_sqr / xz_addat_6 xz_addat_7 = 9 + xz_atan_6 xz_atan_7 = 16 * xz_atan_sqr / xz_addat_7 xz_addat_8 = 7 + xz_atan_7 xz_atan_8 = 9 * xz_atan_sqr / xz_addat_8 xz_addat_9 = 5 + xz_atan_8 xz_atan_9 = 9 * xz_atan_sqr / xz_addat_9 xz_addat_10 = 3 + xz_atan_9 xz_atan_10 = xz_atan_sqr / xz_addat_10 xz_addat_11 = 1 + xz_atan_10 atan_alpha = tanalpha / xz_addat_11 // atan_alpha is angle alpha in radians deg_alpha = 57.29577 * atan_alpha // Convert to degrees

In the simple code version (model "BCPolyCode3.cr2"), the translations and the two rotation angles are distributed among two actors: Parent "pivot" moves on the curve and adjusts the yaw orientation. This is angle "beta". So, we have a rotateY channel "yr_beta" on actor "pivot". Child "dummy" follows the translations and y-rotation of "pivot" and adjusts the pitch orientation, that is, the rotateZ channel "zr_alpha" on actor "dummy". Actually, the code sets the zRot channel "zr_alpha" to zr_alpha = deg_alpha for positive dx and zr_alpha = deg_alpha +180 for negative dx to deal with negative dx values. The channel code on "BODY" is: dx_sign = -dx_var * 1e10 {dx_sign: 0, 180} where "dx_var" is a derivative of the curve and channel "dx_sign" will be set to 0 or 180 depending on the sign of dx_var. The "zRot" channel on "dummy" is: zr_alpha = deg_alpha + dx_sign. This setup works with negative dx values, that is, the CP aa can be placed "behind" the first knot A, and CP cc can be placed in front of knot C. However, if dx is negative, there is a special condition when dx changes the sign. The slope of the curve becomes undefined for a short time. This means, the model flips by 180 degrees about the y-axis. I didn't try to fix this glitch, and it's not the worst problem of this model, anyway.

Model "BCPolyAtnInk.cr2" is a more complicated code variant which seems to work better. To find the tangent, the code calculates points "T" of a second Bezier curve with identical parameters moving a little bit ahead of the first curve. The connecting line between points P and T creates a vector of small constant length along the entire curve which is an approximation to the tangent at points P. The vector is used to derive a rotation angle "alpha" as shown in the picture. The square root implementation is the "Bhaskara-Brouncker" algorithm. Model "BCAtan22.cr2" is the same figure setup, but the Bezier code is based on the so called "de Casteljau" algorithm (instead of the parametric polynomials). The ERC code is less efficient, but the resulting "alpha" angle is much more accurate. You can see the difference, when you set the CPs to a steep pitch tangent ("aa_y" and "bb_y" values). For some unknown reason (maybe a bug in the code), the parametric functions make a noticeable error in this case.

Models "BCAtan22.cr2" and "BCPolyAtnInk.cr2" use two different methods to adjust the pitch and yaw orientations. The pitch orientation is a rotation angle "alpha" which sets the zRot channel of actor "dummy". This is the method used for both angles in the simple code variant. To adjust the yaw orientation, models "BCAtan22.cr2" and "BCPolyAtnInk.cr2" implement a non standard IK-chain which serves as a special constrain operator: When you translate the goal of an IK-chain, the upper links are re-oriented because they follow the movement of the goal. Children of an upper link, which are not part of the IK-chain, are also re-oriented because they follow the movement of their parent. When you establish an IK-chain from the tip of the index finger (goal) to the forearm, and then move the goal, the hand and all fingers will be re-oriented. Because of this, the IK-chain can be (ab)used to constrain a branch of the hierarchy to a target. You cannot do the same with the PointAt command. The model has an additional actor "tangent". "tangent" is translated to the coordinates of the second Bezier curve (points "T") and moves on the second curve. "tangent" is the goal of a very short IK-chain. When "tangent" is translated, the upper link "pivot" rotates and child "dummy" follows the rotation of its parent. Therefore, "dummy" and all children of "dummy" will be re-oriented automatically, i.e. point in the direction of "tangent". For several reasons the standard IK-chain doesn't work in this example. I used a non standard 2-bones variant. As you can see in the picture, the inkyParent of the last link (actor "tangent") is "pivot" (instead of "BODY"). This makes the IK-solver of Poser a little bit nervous at times, but the model works quite well. If you try out model "BCPolyAtnInk.cr2" or "BCAtan22.cr2", be sure to parent your object to actor "dummy". When you scale the parented object, Poser sometimes rotates the object. This effect seems to be a conflict in the evaluation order due to the incomplete IK-chain. You can sometimes see a similar effect when you deactivate a standard IK-chain. To clean up the scene, move the "Plot" master channel a little bit, then reset all rotate channels of actor "dummy" and of your object (or root actor) to zero, then rotate your object if necessary.

Dial "PitchOnOff" can be set to either 0 or 1. PitchOnOff=1 activates the pitch control. The model will move with a tangential pitch orientation along the motion path. This is typically used for vehicles on the road. PitchOnOff=0 deactivates the pitch control. The model will move with a constant pitch orientation. This setting is maybe useful when you have a walk along the motion path.

Ha ha ha.... It took me two months to figure out your tank track programming, so would I be able to figure this out in six months... or 12 months.... or ever.... Seriously, thanks VK, I have a good idea, will IM you when I have thought it out better. PS New tracked vehicle soon, with 73 moving parts. Will send you link in about a week.

Thanks A LOT for taking the time to post this :)

Attached Link: arcbeta (3.1 MB)

Helgard, if you need background information about the code, you can download a beta version of the ARC tutorial. It covers the syntax of the valueOp operators (so called "ERC slave code"), basic information about functions, and tips & tricks to develop and debug ERC functions. There is also a collection of code examples of some elementary functions like abs(), sign(), modulo(), floor(), ceiling(), round(), power(), exp(), ln(), squareroot(), some trigonometric functions, parametric and polar functions. The tutorial is a beta version. There are no real code examples and no example models included.

Thanks VK. Almost finished with the M3, so I can get to this by Monday or so. I have been trying some other things, but I was wondering about these - Any idea what this is in Poser 6, James CR2: useZBuffer 1 algorithm 0 And in the Geometries folder in P6 there is a folder called Balance, with com.mtl and com.obj, but I can't find any Cr2 or PP2 that references them, so what are they for?

than my own to tackle this stuff. signed clueless in Arizona

That Seems awful complicated to me.
All I do is Place a car on the ground. What ever curves you need you put in your walk path. Then from the top camera pull away so you can see the whole scene. (the numbers are for Example only.) a thirty frame animation. Frame 1 the car looking from above. line the car up with the walk designer path. Then at frame (between 10 and 12 - and 18 and 20) depending on how tight of a curve you want to make it. For example sake, use frame 12 which is before the curve using the Y Rotate and and X & Z Trans. pull your car to that position and line it up in line with the walk path. and I use spline break then go to frame 18 and again line the car up with the path and spline break it again. finaly the end frame pull the car to that point and line it up again and your done.
I have as smooth of a turn as you could want and can do the hole thing in less than a minute.

If the subject should be a rocket going up, then down. the same applies as when you are looking down from above only I use a side view camera. I all ready have the turns completed, now all I have to do is bring the walk path in the air while Im in the side view camera.
From there I use a side view to raise the craft in the air lining it up with the walk path then use the Rotate X to line up with the arch with the peak of the path. using the same steps as above and bring it down.

When you get into math that becomes confusing. If it looks correct to the eye. that is what counts in animation. I wish I was good at the calulations use use. I could sure use them on other things!