Jump to content
Search Community

2.x updateTo in 3.x ?

CryOfGaming test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

Hello,

 

i wanted to upgrade from the old 2.x to the latest 3.x GSAP. Mostly everything is working, except the code below.

I need to update variables during the animation without changing or resetting the duration—it should just continue to the new path like nothing happened. 

 

In 2.x it was working perfectly, now im messing around with "quickTo()", "invalidate()", trying to get the old "duration()" and inserting it in the updated tween, but nothing works like in 2.x.

 

Could someone suggest me how to achieve the same 2.x updateTo() effect without resetting the duration?
It's also important to be as efficient as possible. Lots of objects get created, each having this update function which get called many times per second in each individual object.

 

Thank you!

 

this.Tween.updateTo({
  x: newPositionX, 
  y: newPositionY
}, false); //false = Dont reset duration!
Link to comment
Share on other sites

There isn't a direct equivalent in 3.x because that method was something that almost nobody used and it just didn't seem worthwhile kb-wise to have in 3.x. But you should totally be able to recreate that functionality. Just so I'm clear, are you saying that many times per second you're updating a destination value and you want to keep the overall duration the same but basically redirect where the values are going? So, for example, if x is animating from 0 -> 100 linearly over the course of 1 second and then at 0.9 seconds you want to change the destination to 500, it would then travel from 90 to 500 over the course of 0.1 seconds (super fast)? 

 

// chop the duration to whatever time is left, and then invalidate so it flushes out the recorded start/end values
tween.duration(tween.duration() - tween.time()).invalidate();
// then update the destination values on the vars object.
tween.vars.x = newPositionX; 
tween.vars.y = newPositionY;
tween.restart();

Does that work for you? 

 

The main thing that doesn't do (which updateTo() did) is adjust for the easing. If you need that, there's probably a more complicated way to work around that. Just let us know if that's a requirement.

Link to comment
Share on other sites

If you need easing factored in, here's an "unofficial" helper function: 

function redirect(tween, vars) {
	let inv = 1 / (1 - tween.ratio);
	for (let p in vars) {
		tween.vars[p] = vars[p];
	}
	tween.invalidate().render(tween.time());
	let adjust = obj => {
		let pt = obj._pt, end;
		while (pt) {
			if (pt.d && pt.d._pt) { // plugin
				adjust(pt.d);
			} else {
				end = pt.s + pt.c;
				pt.c *= inv;
				pt.s = end - pt.c;
			}
			pt = pt._next;
		}
	};
	adjust(tween);
	return tween;
}

Usage: 

redirect(tween, {x: 1000, y: 500});

See the Pen oNMryZZ?editors=0010 by GreenSock (@GreenSock) on CodePen

 

That should pretty well replicate the old updateTo() method behavior that you were after.

Link to comment
Share on other sites

1 hour ago, GreenSock said:

There isn't a direct equivalent in 3.x because that method was something that almost nobody used and it just didn't seem worthwhile kb-wise to have in 3.x. But you should totally be able to recreate that functionality. Just so I'm clear, are you saying that many times per second you're updating a destination value and you want to keep the overall duration the same but basically redirect where the values are going? So, for example, if x is animating from 0 -> 100 linearly over the course of 1 second and then at 0.9 seconds you want to change the destination to 500, it would then travel from 90 to 500 over the course of 0.1 seconds (super fast)? 

 

// chop the duration to whatever time is left, and then invalidate so it flushes out the recorded start/end values
tween.duration(tween.duration() - tween.time()).invalidate();
// then update the destination values on the vars object.
tween.vars.x = newPositionX; 
tween.vars.y = newPositionY;

Does that work for you? 

 

The main thing that doesn't do (which updateTo() did) is adjust for the easing. If you need that, there's probably a more complicated way to work around that. Just let us know if that's a requirement.

 

Thank you for your help! Unfortunatly it seems to not be the solution.

 

This is how it looks in 2.x with "updateTo" which is exactly what i want: 

See the Pen PoBrabR by cryofgaming (@cryofgaming) on CodePen

A nice, smooth update. And as you exactly said, it speeds up to reach the targetposition because it has less and less time available.

 

And this is the solution, you provided. It's not smooth and jumps around. 

See the Pen MWBMXeM by cryofgaming (@cryofgaming) on CodePen

 

I hope it's understandable what i try to achieve. 

Link to comment
Share on other sites

6 minutes ago, GreenSock said:

I think you replied before I edited my answer (I was in a rush, sorry) :)

 

You just need to add tween.restart()

Yes the restart fixed the problem. THAnk YOu :)

 

I need to have all performance possible, what do you suggest to use for the best performance?

Should i use the method you provided (which also works awesome) or the fixed answer with "tween.restart()"?

 

If we already talk here, does the "DynamicProps" Plugin exist for 3.x? If yes, where can i get it? And also, is the plugin performant?

Everything needs to run as performant as possible, even just a millsec. Slower can be a big problem 

Link to comment
Share on other sites

11 minutes ago, CryOfGaming said:

I need to have all performance possible, what do you suggest to use for the best performance?

Should i use the method you provided (which also works awesome) or the fixed answer with "tween.restart()"?

 

You probably won't notice any real-world difference, but the first one is technically cheaper performance-wise because you don't have to loop through all the properties to adjust for the easing. Plus the 2nd version (helper function) is technically tapping into private properties that might change in a future update. So unless you really NEED the easing adjustment of that 2nd solution, I'd definitely stick with the first. 

 

If you're concerned about performance, you definitely shouldn't be changing top/left values frequently like in your demo. Just use transforms (x/y). In almost every case that I've seen, performance problems have nothing to do with the GSAP code and everything to do with graphics rendering performance in the browser. So make sure you're obsessing about the right things :) 

 

14 minutes ago, CryOfGaming said:

If we already talk here, does the "DynamicProps" Plugin exist for 3.x? If yes, where can i get it? And also, is the plugin performant?

No, but pretty much anything is possible to do with the current platform. I think it'd be much better for you to explain what you're trying to do from more of a macro level because sometimes I see people getting super caught up in the minutia of a very particular technical issue but their overall approach from an engineering standpoint needs an overhaul and if they did that, it'd greatly simplify or eliminate a lot of their challenges. 

 

Why do you feel the need to use DynamicPropsPlugin? Are your values constantly changing? Why? There may be an entirely different approach that'd end up being more performant and there'd be no need whatsoever for a DynamicPropsPlugin. 

 

If you can provide a super clear minimal demo illustrating the challenge you're facing, that'd be helpful. Just the most basic thing you can think of (a few colored <div> elements) is fine. Your earlier demos were great. 

  • Thanks 1
Link to comment
Share on other sites

10 minutes ago, GreenSock said:

You probably won't notice any real-world difference, but the first one is technically cheaper performance-wise because you don't have to loop through all the properties to adjust for the easing. Plus the 2nd version (helper function) is technically tapping into private properties that might change in a future update. So unless you really NEED the easing adjustment of that 2nd solution, I'd definitely stick with the first. 

 

If you're concerned about performance, you definitely shouldn't be changing top/left values frequently like in your demo. Just use transforms (x/y). In almost every case that I've seen, performance problems have nothing to do with the GSAP code and everything to do with graphics rendering performance in the browser. So make sure you're obsessing about the right things :) 

 

No, but pretty much anything is possible to do with the current platform. I think it'd be much better for you to explain what you're trying to do from more of a macro level because sometimes I see people getting super caught up in the minutia of a very particular technical issue but their overall approach from an engineering standpoint needs an overhaul and if they did that, it'd greatly simplify or eliminate a lot of their challenges. 

 

Why do you feel the need to use DynamicPropsPlugin? Are your values constantly changing? Why? There may be an entirely different approach that'd end up being more performant and there'd be no need whatsoever for a DynamicPropsPlugin. 

 

If you can provide a super clear minimal demo illustrating the challenge you're facing, that'd be helpful. Just the most basic thing you can think of (a few colored <div> elements) is fine. Your earlier demos were great. 

I just made a quick function which allows me to update variables and pass a boolean to either run the “slow” easing-adjusting code or the faster code.

 

Yea, I just changed top/left values in the CodePen for visualization. I mainly work with HTML5 canvases and need to change lots of object positions with GSAP.

 

About the DynamicPropsPlugin, It's not really required right now. Might be a QoL thing, especially if it would have very good performance. But if its not available, that's perfectly fine and not a big deal.

 

Thank you so much again for your help! :)

  • Like 1
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.
×
×
  • Create New...