WD40andTape

No problem at all @GreenSock. I will continue to post here in case anyone can give me any pointers or in case someone needs to do the same in the future as to me it seems relatively fundamental to keyframing. I have improved my previous solution. I am using two (slightly simplified) functions taken from BezierPlugin to estimate the length of each bezier segment. From this I know the progress at which each anchor will be hit. Hence, I can create a CustomEase to adjust these times to my target times. As it stands, the main thing that needs improving is smoothing on the speed. You can see commented out in the CodePen that I have tried to convert and feed a BezierPlugin.bezierThrough into CustomEase instead of individual points. Unfortunately this was causing problems of rapid accel/decelerations and overshooting at times - I think this is maybe just the nature of BezierPlugin's 'thru' type. https://codepen.io/WD40andTape/pen/dBOzPJ

Thank you very much to both @mikel and @GreenSock for your help - I really appreciate this community. I figured out a solution! Hopefully it's useful to somebody in the future and you get a better idea of what I was after from this CodePen. I am still using correlate as I need the tweened progress value to be synchronized with the position. However, I am now using a dummy object so that I don't try to set impossible properties of the DOM element/timeline. In order to convert from the bezier progress value to a CustomEase I sample a number of points from the bezier tween. Perhaps there's a cleaner way to do this? Or to create a smoother CustomEase, as right now it's linear? Another problem is that sometimes progress doesn't increase monotonically, i.e. sometimes if it needs to move too slowly between two points it will start moving backwards for a short distance. https://codepen.io/WD40andTape/pen/dBprjz

To give a quick summary, I want to be able to set the progress/time at which a bezier path will hit each anchor point while keeping both the path and speed/progress smooth, i.e.: var bezier_path = [ {x:0, y:0, progress:0}, {x:0, y:80, progress:0.1}, {x:80, y:80, progress:0.5}, {x:80, y:0, progress:0.6}, {x:0, y:0, progress:1} ]; Essentially what I'm trying to do is the same as @danehansenfrom 2013 if it gives you any inspiration: As you can see in the CodePen, the main method I've tried is correlating the x, y, and progress properties of a bezier tween. The x and y properties tween the moving element and the progress property tweens the parent timeline. Unfortunately it appears that including x and y values in the timeline tween breaks the tween. Hence, I've played with BezierPlugin.bezierThrough to calculate the correlated bezier and then seperate the object properties out for the element and timeline tweens. Unfortunately, TimelineMax.to() with bezier:{} doesn't accept this form of input. I've thought about using CustomEases but unless I know at at what time/progress a bezier anchor point will be reached this is not possible.

Hi @OSUblake, hope you're well, I'm back once again. I looked over your code again and for sure the ObservablePoint.rotate() function just calculates the end point of the rotation and the callback tweens to that point without any curvature (linearly). It becomes really clear what I'm talking about if you try to do an 180 or 360 degree rotation. However, some space from the problem helped me think! I updated my function to precompute the rotation as a Bezier path, rather than setting the element's properties instantaneously at each proxy update. It seems less laggy, can be stopped or interrupted (overwritten) as expected, and generally integrates with the timeline more naturally. Hopefully something like this can be integrated into GSAP officially as it seems pretty basic but took a whole lot of work - I'm sure it can be improved more too!

Hey @OSUblake, thanks, that's nice of you! ooh boy those are useful helper functions - the transforms and bounding boxes were doing my head in - and particularly I think that I can learn from the code organisation in the last demo, shows your experience with the library! My code is pretty simple bar the 'gotchas', it essentially: waits until the given time; calculates the element's transformed properties; calculates distance and angle to the rotation point; tweens these, using trig to calculate the updated position at each step; adds an instantaneous 'set' at each frame with the updated position. That last step is required to actually follow the correct arc as it rotates, in your example the dots transition along a line from the start to end point of the rotation. That last step is also what is causing lag in more complex scenarios and inconsistencies if the rotation is interrupted (tweens normally just pverwrite current tweens, moving from the current to the next point). Any thoughts?

Hi OSUblake, first of all true to your title you're an absolute superhero - thank you! Based upon your answer I've spent a while creating an orbit method to manually calculate and set the correct x, y, and rotation at each frame. Hopefully others will find it useful in the future.

Thank you, that certainly does help my understanding. I had also assumed that GSAP was doing the maths in the background to convert from transforms to global coordinates, e.g. so that rotations would cause a coordinate change. Having said that, I'm still not sure how to tackle this. To restate I need 3 operations, all of which could be interrupted midway: 1. Rotate elements around an absolute position (relative to the top left of the entire SVG). 2. Move elements to an absolute position, e.g. [0,0] so that the circle sits at the top left of the SVG. 3. Rotate elements around their centers. It's the combination of the first two which introduces the complexity, while the third is simple. I guess I could either retrieve and transform between each of the coordinate systems, or write a function to perform point 1 using points 2 and 3. Any guidance? I'd be surprised if no one has come across this before.

Hi GreenSock, thanks for having a look and sorry that you found it ambiguous. Rotating with svgOrigin and smoothOrigin appears to permanently change the global coordinate system for that element, i.e. {x:0,y:0} no longer refers to the top-left corner of the viewbox, and I can't figure out how to reverse that change. I've done as you said and included some more comments, hopefully it helps to clarify things. The red circle shows the expected behavior, the blue circle shows the true behavior.

Hi all, first of all loving the forums, lots of helpful people creating a wonderful referencing resource. What I'm trying to do should theoretically be very simple, but I've been struggling with it for a week, I've read all of the available documentation and forum posts with no luck. I need to arbitrarily move SVG elements to an absolute position (relative to the viewbox), rotate them around their centers, or rotate them around an absolute position (possibly interrupted during), any number of times in any order. The problem is that with smoothOrigin DISABLED the elements jump and do not rotate around the intended point, with smoothOrigin ENABLED the elements drift and do not stop at the expected point. Can I reset the svgOrigin so that the new position is in the same coordinate frame? Anyone have any experience dealing with this? A quick pointer in the right direction would be much appreciated!