da2020

Jack, Thanks very much for this updated plugin and the fast response. I did a few test runs with the new plugin, and backed out the rotation matrix set statements that I added per Jamie's solution, and it does work now as I was originally expecting and as you said it should -- on repeated runs, the first non-AR tweens run with the original non-rotated orientation of the object, rather than "backwards-inheriting" the initial rotation of the first AR tween. Switching gears to what happens AFTER an AR tween (I think this is the same with both the old and new plugin, and is really a different question), when there is a transition from an AR to a non-AR tween, the non-AR tween inherits a fixed rotation that equals the amount of rotation that existed at the very end of the preceeding AR (vs starting with 0 degress rotation that might have been set on the object at the time that non-AR tween was declared and appended). Is that the expected behavior, in that the non-AR tween simply accepts the existing object rotation, as left by the preceeding AR tween, and just moves it along with no other rotational initalization? I guess that makes sense as the default behavior... I notice though that if I apply Jamie's suggested "set" method to set the object to 0 rotation prior to the append declarations, any non-AR tween that follows an AR tween will shift the object to 0 degrees regardless of how the preceeding AR left it... is that what you'd expect? And, one more gear switch on the subject of auto-rotation if you don't mind.. In my path authoring app when the object has been chosen as the path object and has become "attached" to the path starting point (meaning that if that point is dragged around, the object moves with it), and the first tween happens to be set to be an AR tween, the behavior I want is for the object, in the static state before the timeline runs, to assume the inital rotation for path orientation (ie, to assume the initial amount of rotation that the AR tween will apply at time zero (for the current displayed curves) when the tween runs -- you can imagine why this is nice... it allows the author to shape the curve and have the rotation of the object (in pre-run, when not moving) always update in realtime as the path shape changes to match the initial tween's AR orientation to avoid a jump in rotation and to allow for proper positioning of points, etc. Anyway, I've made this work using this somewhat crude but seemingly effective approach: when ever the points affecting AR tween 1 are moved or its curves are changed in editing, I run a short tweenTo for some very small time interval, like .0001 or so, which is enough to make the object rotate to the starting orientation of the path.... so, when the points are being dragged, or curviness is being adjusted, etc.. this fires repeatedly, which makes the object's rotation smoothly adjust to match the departure angle of the path from the first point. So, this works but is kind of an ugly and somewhat flawed approach -- it requires that very short "init" tween that is short enough that it does not noticeably move the object, but is long enough for the tween code to set the initial rotation (ie, tweenTo zero is too "short" --- so, I'm just running this by you to see if you'd agree that this is the best/maybe only way to do this, or if you could suggest a better way... as I see it now, what would really be cool is a "getInitialRotation()" method that would run the necessary calcs and return that initial auto-rotation value without the messiness of having to actually run a short tween... (note I'm also running a bunch of curve distance approximation calcs to support constant speed settings across all the tweens that make up the full path, and I might be able to tap into those loops to extract the initial angle of that first tween, but hoping to avoid that) Thanks again for your thoughts and for the quick help and revision on the bezier plugin. - Doug

Jamie, Thanks for the quick reply. You did a nice job distilling this down to a demo of both the problem and a simple solution. Yes, I'm working in actionscript, but the matrix setting solution you posted on codepen does do the trick for me as well -- that's very good to know, as I was not aware that rotational properties needed to be set in this way for more fool proof initialization of the bezier tweens. It would be nice if this was not required, but this might turn out to be a "feature" because it will allow me to have a setting for whether non-AR tweens that follow AR tweens adopt the last angle of AR rotation or not... since I'm making a path editor, there are situations where either behavior could be desired, now that there is a way to control that choice. Note that, in my case, and maybe for actionscript in general, I was able to use the timeline.set method on the object to go straight to 0 rotation, without the need for a non-zero setting first as you found was necessary in JS... Thanks again!

Hi, In the development of my animation path authoring app, which uses the bezier plugin in "thru" mode, came across puzzling behavior that I can't pin down the cause of.. Here's the scenario: Paths can be authored as a series of tweenmax bezier tweens (where each bezier tween has a thru-points curve of its own, with n points). These tweens are appended back to back in a timelinemax instance. thereby making one long "path" made up of a series of these bezier tweens, where the ending point of one tween is the starting point of the next. The app allows each of these tweens in the timeline to have its auto-rotate parameter set independently, so some tweens in the path will orient the animated object to the path, while others do not. When I have non-autorotated tween(s) at the beginning of the path, followed by an auto-rotated tween later in the path, the initial run of the timeline works as I'd expect: the object follows the beginning tween(s) without auto-rotating (ie, the object's initial rotation is maintained), and when the autorotated tween is reached, the object starts orienting to path --- great. But, after reaching the end of the timeline (end of the full path), if the timeline is commanded to run again, using timelineInstance.restart(); the second time around those same beginning non-autorotated tweens move the object along the path with a fixed amount of rotation that is equal to the INITIAL amount of rotation that the FIRST autorotate tween would impose on the object at the start of its tween -- very weird, and very repeatable... it does not matter how many non-AR tweens exist before the first AR tween, and it does not matter if there is more than one AR tween down the line, the non-AR tweens at the beginning always apply the fixed amount of rotation that would get applied later when the first AR segment is entered, but only after the initial run... the first run through the timeline, also started by the same timelineInstance.restart() approach, works fine.. I even force the rotation property of the tweened object back to 0 just before calling restart, and this still happens, as if there is internal memory of the initial AR rotation value that is somehow contaminating the behavior of earlier non-AR tweens.. Example: The complete "path" consists of 4 tweens in a row, appended back to back in a timeline. First 2 are non-AR, second 2 are AR.. On initial run, the object maintains initial rotation of 0 along the curves of the first 2 tweens as expected, and on the curves of the 3rd and 4th tweens the object rotates to stay oriented to the path -- perfect. Let's say the curve starting the 3rd tween has an initial departure angle of 45 deg from its start point, and the 4th tween has a departure angle of 90 deg from its starting point, meaning when entering AR tween 3 the object initially shifts its rotation to 45 degrees to orient to path, and then continues to change rotation as expected to maintain that path orientation -- same for 4, starting at 90 deg. Now, on the second and all subsequent runs, via timeline.restart(), the first 2 non-AR tweens still maintain fixed rotation, but instead of that rotation being 0 (the initial object rotation), the object gets rotated to a fixed 45 degrees, which is the INITIAL angle that the object takes on when entering AR tween 3... AR tweens 3 and 4 continue to work as normal with variable rotations along their curves... In experimenting with this, the fixed angle of the first two tweens track exactly with that INITIAL departure angle from the point that starts tween 3 -- if I move the points around to make that tween 3 initial angle some other angle, the first 2 tweens adopt that exact same new fixed angle... It makes no difference what the initial angle of LATER AR tweens is, or what the final angle at the end of the path is... it all keys off the initial angle of the first AR tween encountered in the timeline sequence... I don't think it should matter, but note that I'm dynamically constructing the tween instances, and the appending of course is doen dynamically, prior to the first run, but not prior to the second run.. the second run is simply timeline.restart() being issued manually after the initial run completes successfully. Also note that I'm using the array approach for autorotate in the tween declarations, with variables used for the "rotation" property and for the degrees offset. To enable AR, I set the property string in the array to "rotation" and to disable I set it to "" (empty string). -- this appears to work fine as the tweens behave as either AR mode or not according to how this is set, but is empty string the best choice for fully "disabling"?. The degrees offset was set to 0 in my example, but I've set it other values, and the offset works fine in the AR tweens, but the other behaviors are the same. I'm not using any on-complete handlers. As said earlier, attempts to set the object to 0 rotation before the timeline.restart() do not have any effect -- the fixed "error" in the early non-AR tweens, as described above, is still there Not at all easy to provide sample code for this right now, since this is buried in a fairly complex app.. but hoping you can shed some light on whether this might be expected for some reason or if there is something different I might want to do in the way I launch subsequent timeline runs (I realize what I'm doing here might be fairly unique, but this use case has proven to be a very effective one so I need to find a solution... I may need to resort to re-declaring the tweens dynamically prior to each run if I can't find another solution. Thanks much for any thoughts or insights, Doug

Got it working as I outlined in my initial post, using a bezier length approximation algorithm on the beziers from each bezier-through tween (feeding the algorithm with the bezier array data from bezierThrough), then calculating the needed duration for each tween so that every tween would run at the same constant speed (per the "Edit" paragraph in my initial post). It actually works great, and wasn't that difficult once I had the pieces.. Combines the power/intuititve nature of the bezier-through approach (no control handles), with the ability to make sharp changes in direction and curvature (which would normally require control handles).... exactly what I was aiming for. Plus, have all the power and options of the timeline to manage the "macro" animation behavior across the overall path as well. - Doug

Hi, I'm developing a motion path editor that makes use of the bezier plugin and the "bezier through" option such that users can simply click to create points that they want the curve to pass through -- this makes things "simple" because it avoids the need for visible control point handles in the UI. Great. The one drawback of course is that you can't make sharp changes in direction/curvature at a point since the "curviness" setting applies across the whole tween --- ie, this is what you lose by avoiding the use of control point handles... Well, my thought is to get some of this kind of control back, while sticking with just the "bezier through" approach, by allowing the user to declare a point in the curve as a "break" point, meaning that, behind the scenes, a new "bezier through" tween would start at this point... This allows the curve that departs that point to be a sharp change in direction, or exhibit a different amount of curviness, based on the points and curviness setting of this new tween... So, in the end, the overall path can end up being one big bezier-through tween (if no "break" points were set) or a seamless series of separate bezier-through tweens, where the point that ends one tween is the starting point of the next tween.. In the eyes of the user, these separate tweens would simply be "segments" of the total path, where each segment could have its curve properties set independently. I know this can be done using timeline to run these as a series of appended tweens, but what I'm not sure about is how to best set this up if I want the overall path to perform like a single unified motion path, where I can set a time duration for the overall path (timeline) and achieve a constant object "speed" through the entire path (even though the object is actually being animated by a series of separate back-to-back bezier-through tweens, as described above). The time duration values for the individual tweens can't be used to achieve this, I don't think, because the total length of the curves for each individual tween is going to vary greatly. So, my question is: Is there a way to override the individual tween durations and have a master timeline duration be in effect that would force a constant speed from one end of the overall path to the other? I assume that clocking the overall timeline progress property to progress at even intervals via enter frame / onUpdate for the timeline (using time-based update value) won't help in this situation, because "progress" would always be in terms of the sum total of the durations of the child tweens (?) -- I guess I need to manipulate "distance-based" progress, not time-based progress, which would not seem possible without knowing the "length" of the path that the bezier curves represent. Too bad there's no "speed" setting for the bezier tweens that could be used instead of "duration". If "speed" could be set, they could just all be set to the same value and I'd be good. EDIT: In thinking about this further, I guess there are methods that could be done in as3 to compute the approx distance of the individual quadratic bezier curves, and then sum up those computed distances for each tween and dynamically calculate the duration property for each tween to achieve a certain speed across all the tweens, but I'm still hoping there's an easier way via some combination of timeline/tweenmax/bezier-plugin features that I haven't yet thought of. Also open to any ideas on a different approach that would achieve this constant speed goal and the editing goals mentioned above, ie, is there a better way to set this up other than using a timeline with a series of back-to-back bezier tweens? Thanks, Doug

Thanks Jack. Regarding item 2, I was doing as you suggest, BUT, somehow I completely missed the fact that BezierThrough ALSO has a curviness parameter which I just noticed in checking the documentation again... so, with that it seems I can get the plot to match the tween path exactly for all curviness settings.... very cool. Thanks again, Doug

Hi Jack, Update -- I did in fact have an error in where/when I initiatilized the offsets, and this resulted in the 0 value calc results... After correcting that, I'm seeing your trig code work perfectly -- now I have two viable solutions it seems! The only app-specific issue I have now is that some of the objects being animated in the hosting app have children with display elements that add width to the overall visual entity, such as stroke elements that can have varying widths extending beyond the parent's width (these aren't reflected in the width property of the top level object, so the centering is off a bit when these are present) ... so, I'm hoping I can find a generic way to get true "total width" that includes the effects of child elements (without having to dig throught the dimensions of all the actual children, which vary a lot depending on the type of object construction)... Still wondering a couple of things: - do you have a reference that explains the nature of the trig calcs that use both x and y sin/cos elements in EACH offset calc, as you did (I suppose this is just "common sense" for animation gurus, but I'm a bit rusty in the applied trig area) - what would you suggest for being able to display a plot that matches the bezier tween curves? Right now I'm using the flash curveTo quadratic method suggested in the API doc for the bezier plug-in, but that only matches if the tween "curviness" is set to 1 (normal). Hoping to be able to get a matching plot that works with any curviness setting... I suppose I could draw the path via the actual animated object's path by running the tween once just to create the path, but that could be a little clunky... My intended use case is providing a friendly UI so that a non-flash author can set/drag anchor points, and change curviness values, etc, and instantly see the plotted animation path that results.. Thanks, Doug

Jack, Good to know.. In just looking, I think I may have dropped the assignment statements for the 2 offset values in a spot that executes prior to the code that initializes the existing variables I was using... ie, you may be right that they were both zero inadvertently.. I'll try this out later and let you know. The only other difference is my tween declaration, but I don't think this would present a problem: TweenMax.to(tweenObject, 5, {bezier:{curviness:1, timeResolution:9, autoRotate:["x","y","rotation", 90,false], values:[{x:tweenPoint2X, y:tweenPoint2Y}, {x:tweenPoint3X, y:tweenPoint3Y}]}, ease:Linear.easeNone}); Note I had the the auto-rotate set at 90 to shift the facing forward point of the object to be the "top" of it -- but wouldn't think this should matter. The curve is roughly a parabola shape. The timeResolution value has been set high as an experimental setting to force a faitly constant speed regardless of point spacing... I haven't quite yet got my mind around using both the cos and sin calcs in that manner in each of the offset calculations... been away from the trig side of things too long.. is there a reference you could point me too that addresses this particular technique? In prior attempts, I had just been using cos for x and sin for y offset calcs. By the way, I'm using the approach laid out in the Bezier plug-in API doc to use the flash curve drawing API to draw a visible path that matches the tween path.. It's an exact match when tween "curviness" is set to 1, but I'm wondering if there's a way to plot the curve to match other curviness values? Thanks, Doug

Jack, Thanks for the suggestion and code snippet.. I incorporated your approach and the equations but it did not have any net effect as far as centering the object.. I traced the expressions for mc.x and mc.y and they actually each net out to zero at every point, so there is no offset applied for either x or y, as written. When I was working on my own trig-based solution earlier, I got close by just using cos for the x calc and sin for the y calc... but could never achieve consistent centering over the entire path -- I think part of the problem is that the object being animated has changing width/height values over time -- I think this may be due to how the bounding box widens and narrows as rotation occurs. Anyway, since my post above, I was able to work out what appears to be a reliable non-trig solution by using a variation on the popular container-with-shifted-child approach for centering. As mentioned in my earlier post, I can't simply re-parent the target to be inside a container due to constraints in the hosting app. As a workaround, I created a proxy child object inside a container as if it were the target, offset the child based on 1/2 the dimensions of the target object, and then in the enter frame handler I simply assigned the x and y coordinates of target to equal the global space x and y values of the shifted child (where the container (parent) object was the one actually being tweened), and also set the rotation of the target to match the rotation of the container.. Since the global (stage) space coordinates were needed, the child x and y coordinates could not just be read directly, because that just results in getting fixed numbers that relate to the child's coordinate space within the container parent --- so, needed to use the localToGlobal method to get a point that was in terms of the global coordinate space. Got good centering results with this approach across the full bezier paths, and it's fairly intuitive and easy to tweak. - Doug

Hi, I'm using the v12 bezier plugin to animate objects along curved paths using the "through points" option), and am looking for a way to shift the origin (registration) point for the object being tweened so that it can be centered on the path (the path is made visible in this app by drawing it via the flash drawing api method described in the bezier plug-in api documentation, which does match exactly with the actual tween path). The challenge here is that this is being done in an "add-on" app of sorts to a commercial flash-based elearning authoring tool.. In this environment, I am not able to use what seem to be the standard tricks for moving origin points (ie, the object being animated is created by the authoring app, and therefore I cannot re-parent it to carry out the shell container shift trick (the app won't allow that type of change to the top level display list), and because of the complex child hierarcy of these objects I cannot use the transform matrix approach on the object's contents either). The good news is that, within the add-on app I'm developing, I can tween the object nicely using the gs v12 bezier plugin (need the through points curved paths this provides), but the object is tweened at its default "top=left" origin point, which is not acceptable in this use case -- I need to center it, and also need to use auto-orient-along-path option as well (which the bezier plugin also supports nicely). I thought perhaps the tranformAroundCenter plugin would help, but from what I've read in the forum this plugin only works for basic tween types, and does not work with the bezier plugin. So, one approach I'm considering is to use an enter-frame handler to track the movement of a dummy object being bezier tweened, and assign the dummy object's rotation and offset x - y values for the actual object there (some trig needed here, I think, to get the right x- y offset values, given that auto-orient rotation is happening). I think this could be made to work, but don't like the overhead implications of frame-by-frame tracking of the tween. The idea I like best is to, once at initialization time, simply decalre the actual tween curve such that it is shifted away from the visible drawn curve, such that the end-result is that the object appears to animate centered on the drawn path. This is easy if not using auto-orient-along-path, as it's just a matter of shifting the bezier through points (relative to the visible drawn path) by the x and y amounts of 1/2 the width and heigh of the object.. It becomes trickier though, when auto-orient-along-path is enabled, because the rotation that occurs makes the simple x-y offsets for the tween declaration difficult/impossible to know -- so this is where I'm stuck.. IF there were a way to use the bezier plugin along with timelinemax to somehow, as part of "initialization", go to the defined through points one by one, then check the object rotation value at each of those points, and then use that info to calc the x-offsets at those points using trig, then I think the offset tween curve "through" points could be determined and plugged into the bezier tween declaration statement... but I don't see support for "going to" the bezier through points to do such a thing.... So, the question is, can this be done somehow, or are there ideas on an alternate approach that would be better, given the constraints of the hosting authoring tool mentioned above? Thanks for any insights/suggestions, Doug