'getRelativePosition' or 'convertCoordinates' for a (yet to be transformed) element

[Asderex]

Hi,  I was wondering if it's possible to factor in an intended transformation of the elements into the getRelativePosition or convertCoordinates methods.

convertCoordinates doc's

 

For example, in the demo video for convertCoordinates the video shows a fromElement and a toElement which transform by a random scale, rotation etc. and then tween the child element into position using the newly transformed parents.  My question is "is it be possible to tween the transformation of both the parents and the child elements at the same time so everything moves synchronously?". (Sorry - I wanted to link to the codepen here but could find the one I was looking for from the video)

 

I can't see how I could do that right now as (as far as I can tell) any elements passed into getRelativePosition or convertCoordinates need to be in a 'final' position i.e. these functions return a transform for where the elements are and not where they are going to be.

 

note: I've seen the 'arm and joint' getRelativePosition demo which uses 'onUpdate' to remap the the arms start position.  This could probably be used but it just seems a bit inefficient to continuously recalculate the necessary transform on ticks of the parents tween when we should be able to calculate the final position at the outset using the current positions and intended transformations.

 

Any thoughts on how this might be achieved? Maybe some clever matrix composition?

[ZachSaucier]

Hey Asderex. I'm not sure I'm following you completely. Are you saying you want to animate a child element to the location of a different element while its parent's position is also animated? If so the easiest solution is to make the element not be a child of the parent  

 

A minimal demo would be useful. This is one of the demos in that video which might help you get started:

See the Pen 200b2067226622a5ad2f37962d7fdfe9 by GreenSock (@GreenSock) on CodePen

[GreenSock]

I'm not sure I follow, but if your goal is to figure out the final values, couldn't you just move the parent and child to the destination temporarily, do your calculations and record the values, and then move them back to start animating? It'd be invisible to users - it's just for the purpose of calculating. 

 

Again, I may be misunderstanding your question. Like Zach said, a minimal demo would be super helpful. 

[Asderex]

Thanks for the reponse Zach and Jack - hmm, it maybe non trivial then as my project requires the current hierarchy of elements.  What I was hoping to do in the example codepen Zach has included was have the boxes rotate and move and the four point shift to their new positions at the same time and not in stages.    

 

It's a very niche requirement and I was thinking about using Jack's suggestion of shifting the parent between screen refreshes and grabbing the transformations before shifting it back for the next screen refresh but it felt a bit janky.

 

The transform I will be applying to the parent elements is scaling so I think it might just be a matter of multiplying the returned transform by the scale factor but I thought I'd check if there was some clever GSAP solution was missing out on.

[GreenSock]

8 hours ago, Asderex said:

It's a very niche requirement and I was thinking about using Jack's suggestion of shifting the parent between screen refreshes and grabbing the transformations before shifting it back for the next screen refresh but it felt a bit janky.

By "janky" do you mean that it animated in a jerky (non-smooth) way or "janky" as in "hacky, non-optimal"? 

 

I'd say it's a lot less janky than recalculating things on every update, although in certain cases that's really the only option when things are super dynamic. 

 

8 hours ago, Asderex said:

I think it might just be a matter of multiplying the returned transform by the scale factor

It really depends on the scenario - what can really complicate things is transform-origin because everything scales outward from there, you know? And then if you've got rotation, skew, etc., it can get mind-bending

[Asderex]

20 hours ago, GreenSock said:

And then if you've got rotation, skew, etc., it can get mind-bending

.... you're not wrong, scale is more than enough for me .  I've actually found a simpler way off dealing with my specific problem.  I had several nested elements with arbitrary x,y transforms set by the user dragging things around.  I found by rebasing the transforms (so nothing effectively moves on screen but the various transforms are applied to different elements) it makes life alot easier... I even still get to use convertCoordinates.

 

20 hours ago, GreenSock said:

By "janky" do you mean that it animated in a jerky (non-smooth) way or "janky" as in "hacky, non-optimal"? 

I meant "hacky", but the fact that you suggested it as a possible solution made me think it would have been a reasonable approach (I'm a hobbyist at this stuff rather than a professional).  I never actually tried it and it probably would have worked just fine but it felt strange using DOM state as a calculator.

 

Thanks for the responses and for giving us access to these methods - super useful!

[GreenSock]

2 hours ago, Asderex said:

I meant "hacky", but the fact that you suggested it as a possible solution made me think it would have been a reasonable approach (I'm a hobbyist at this stuff rather than a professional).  I never actually tried it and it probably would have worked just fine but it felt strange using DOM state as a calculator.

 

I have similar instincts, but after spending a LOT of time digging into this stuff, I realized that sometimes my "purist" approach actually made things way more complicated or even slower. Sometimes it's smart to leverage stuff that the browser offers. At least that's where I've landed. convertCoordinates() is doing some of that under the hood in fact. 

 

Happy tweening!