Problem with zooming / transform one view rect to another

[yv3]

Hello fractal lovers,

currently i am working on a video preview function in my tool yFract (old=yFractalExplorer). Everything is working fine, you can define waypoints, change fractal parameters and the software computes the transition between the waypoints so you can prepare and preview a nice movie. But i have a problem with transforming the view rect of a waypoint to the next waypoint. it works but it has a problem.
My first idea was to transform the view rect like other fractal variables (like magnitude, rotation, iterations etc.) with a static increment. Here is a picture that describes how its implemented, the pictures only focuses on how to determine the increment of "x1_inc" for simplicity, this is the value that i have to add every frame to the starting x1-value of the source view rect:



But this computation method has one problem: because the increment is static, the zoom gets more and more faster until the last frame ist reached. Thats because the view rectangle gets smaller and smaller but the increment stays the same. Here is a demonstration of the "bug":

<a href="http://www.youtube.com/v/C1ZyFkygEac&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/C1ZyFkygEac&rel=1&fs=1&hd=1</a>

Ive read about "exponential approximation" and tried to prepare a working formula with excel to solve the problem. But exponential approximation seem to never reach the destination value (in the case obove 2.9), also i don't know how to adjust the formula so the last value is quite near the destination value regarding the amount of frames/steps in the transition.

PLEASE HELP!

[HPDZ]

The way I (and I believe most other programmers) do this is:

Let S size of image on complex number plane (of course, you need Sx and Sy for a non-square image, but that's just a detail that complicates the main point here)
Let n = frame number

S(n) = S₀ 10^kn

where k = rate constant for magnification; i.e. for a 30 fps video, 10X per second means k=1/30

That will give a constant zoom rate. To get a variable zoom rate, i.e. smooth starting and stopping, you have to do something a bit more complicated. Basically, the essence of it is to use u(n) rather than kn in the exponent, where u(n) is some function you can make that defines the time-dependent behavior of the zoom velocity. Maybe I'll write a bit about this on a technical page on hpdz.net...it's a bit much to get into here.

And if you want to zoom while also moving the centerpoint of the image, THAT is a much more complicated problem.

I hope this helps.

[yv3]

Thank you very much Mike, the zooming is now at constant speed!, finally  . I also managed to write a function that estimates the value of "k" acording to a given start and destination value, it returns a value that almost reaches the destination value on the last frame. This function allows me to set a given start and end keyframe of the zoom and let the user decide the framerate and an exact transition time.

This is code of the function if anyone is intrested:

Code:

	double GetExponentForRange(double start_value, double end_value, int frames_in_transition)
	{
		int			frame, i;
		double		exponent, prev_exponent=0.0, current_value, step;
		const double	step_multiplier=1.0100000000000000; //1.0001000000000000 = more accurate but slow

		if(start_value>end_value)
		{
			exponent=-0.0000000000000001;

			for(i=0; i<2; i++)
			{
				for(step=0.0000000000000001; ; prev_exponent=exponent, exponent-=step, step*=step_multiplier)
				{
					for(frame=1; frame<frames_in_transition; frame++)
					{
						current_value=start_value * pow(10.0, exponent*double(frame));
					}

					if(current_value<end_value) break;
					prev_exponent=exponent;
				}
				
				exponent=prev_exponent; //and again for better precision, beginning with the last zoom factor that has been estimated
			}
		}
		else if(start_value<end_value)
		{
			exponent=0.0000000000000001;

			for(i=0; i<2; i++)
			{
				for(step=0.0000000000000001; ; prev_exponent=exponent, exponent+=step, step*=step_multiplier)
				{
					for(frame=1; frame<frames_in_transition; frame++)
					{
						current_value=start_value * pow(10.0, exponent*double(frame));
					}

					if(current_value>end_value) break;
					prev_exponent=exponent;
				}
				
				exponent=prev_exponent; //and again for better precision, beginning with the last zoom factor that has been estimated
			}
		}

		return prev_exponent;
	}

This is my first mathematical "brute force" function Maybe you know an easier approach.

If im honest im not really happy with this situation because i have to limit the waypoint functionality so the user can either zoom OR move the view rect. To make a zoom into a specified position you have to go to the destination place, then zoom out, set the first keyframe and then zoom again to set the second keyframe. Now i understand why it is complicated to combine both transition types, they are dependent on each other.

Smooth starting and stopping is a "nice to have fancy", but combining both zooming and moving is much more intresting for me. Maybe you can post a solution for this some day, that would be really cool, but you already deserved a thanks and a place in the credits section of my software

[HPDZ]

The mathematical formalism required to describe moving while zooming is too much to express in text.

The basic idea is to scale the velocity of the translational motion with the size of the image. You have P0=(x0,y0) and P1=(x1,y1) as your start and end points. You want to make a function u(n) that gets you from P0 to P1, like this: P(n) = P0 + (P1-P0) u(n), where n is the frame number. The form of u(n) is v(n) * S(n), where v(n) is the velocity of the translational motion (you need, of course, one equation for x and another for y, but, like I said, the formalism gets to be too much). and S(n) is the size of the image at frame n.

Now, how you make v(n) is a whole other matter. There are lots of ways to do it, but the easiest way is to make a linear ramp velocity impulse: that is, a holdoff time where v is zero (optional, really, but sometimes very useful), then a lead-in linear ramp up, then a constant value, then a lead-out linear ramp down back to zero. You have to normalize it so that the integral of u(n) -- not v(n), but u(n) -- gets you from 0 to 1 in n steps. I do that by numerically integrating the function and using the result as a normalization value. It is possible to do this in closed-form analytically, but it is really tedious, and knocking out a quick trapezoid rule integration function is really easy (I know, I know all the problems with that method, but its good enough for this application!).

That is basically it.

[yv3]

ok, ok, i admit that i don't understand almost everything in your last post
I implemented a workaround in my app now, if you zoom and move in the transition, the old calculation with the static zoom is used, otherwise if you only zoom without moving the exponential zoom is used (the app checks if the center of the view has changed).

Here is a proof of concept, a zoom into a boring place, with rotation and antialiasing:

<a href="http://www.youtube.com/v/3uceJzus-Rc&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/3uceJzus-Rc&rel=1&fs=1&hd=1</a>

Stretching while zooming also works! Thank you very much.


UPDATE:

My first self made fractal zoom gif