Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Asderex

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

Go to solution Solved by GreenSock,

Recommended Posts

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?

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

  • Solution

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. 

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

  • Like 2
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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!

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×