Keyframes and Rotation - a possible bug/design flaw

[fh1805]

I'm now in the midst of "polishing" the sequence called "Kaleidoscope" (see my post under the "Sequences" forum) and have hit a problem.

At one point I have the large brown wheel rotating through 1440 degrees anti-clockwise over a period of about 33-34 seconds. At four points in this rotation, timed precisely to fit with the music, I need to set a triplet of keyframe time points, the members of each triplet being about 25ms apart. I have not yet found a reliable way of doing this. I have tried producing a simplified sequence of just: black slide, background, black slide with the brown wheel added to the middle slide. If I set a keyframe for the wheel at the end of the middle image and assign -1440 rotate to this the wheel rotates smoothly throughout the 34 seconds I've assigned to the middle slide.

If I then insert a keyframe point and give it the specific offset I need (which for the first of the triplets is 4500 ms into the image), I cannot guarantee that it will have the correct value assigned to rotation. Sometimes it does seem to assign the correct value and sometimes it doesn't.

Does anybody have a technique for inserting keyframe points into a long running rotation that guaratees to pick up the exact state of rotation at that particular time offset and with a precision of at least 25ms?

regards,

Peter

[xahu34]

Peter,

In order to prevent misunderstandings: can you publish a small project including slides which show the situations you want to consider.

Best regards,

Xaver

Munich

[fh1805]

Xaver,

I'll put something together this evening and post it. Who knows, in trying to set up the example I might even find the answer!

regards,

Peter

[fh1805]

Xaver,

I've now extracted the "brown wheel" from the "Kaleidoscope" sequence and built a simple three-slide sequence. Please read the ReadMe document included in the zip file and then follow the instructions. The problem is not one that I can readily explain by producing an example of it but I hope that the simple sequence and the instructions will enable you to understand what my problem is.

RotateBug_Aug25_2008_16_49_04.zip

regards,

Peter

[Lin Evans]

Hi Peter,

Back with version 5.0 I was trying to simulate video with PTE by decompiling a video sequence then playing back one frame at a time at high speeds. To better the typical video rate of 29.97 fps, I set the sequence to run at 20ms and the result was that it dropped frames. After consulting with Igor I learned that even though 4.x would easily do even 15ms, 5.0 would not go faster reliably than about 75ms to 100ms and really was designed more for 150ms between frames. The bottom line is that 25ms timings "may" be too optimistic for the video engine. I don't remember the technical reasons for this but I do remember that there is a way to create a "log" file using command line sequence which can reveal if a frame is dropped. I don't recall the syntax for this but I'm sure Igor can give you that if you email him.

I'm not certain that this is your problem but I suspect it may well be.

Best regards,

Lin

I'm now in the midst of "polishing" the sequence called "Kaleidoscope" (see my post under the "Sequences" forum) and have hit a problem.

At one point I have the large brown wheel rotating through 1440 degrees anti-clockwise over a period of about 33-34 seconds. At four points in this rotation, timed precisely to fit with the music, I need to set a triplet of keyframe time points, the members of each triplet being about 25ms apart. I have not yet found a reliable way of doing this. I have tried producing a simplified sequence of just: black slide, background, black slide with the brown wheel added to the middle slide. If I set a keyframe for the wheel at the end of the middle image and assign -1440 rotate to this the wheel rotates smoothly throughout the 34 seconds I've assigned to the middle slide.

If I then insert a keyframe point and give it the specific offset I need (which for the first of the triplets is 4500 ms into the image), I cannot guarantee that it will have the correct value assigned to rotation. Sometimes it does seem to assign the correct value and sometimes it doesn't.

Does anybody have a technique for inserting keyframe points into a long running rotation that guaratees to pick up the exact state of rotation at that particular time offset and with a precision of at least 25ms?

regards,

Peter

[Lin Evans]

Hi Peter,

I just looked at your sample and I think the issue is not the timing itself but rather the 3000ms transition which is causing the problem. It doesn't seem to want to be deleted and I've not yet determined why.

It's quite easy to get the precise 15000 second timing. Don't try to slide the keyframe around but enter the value in the keyframe field instead. As it is right now, entering 14000 will result in 15000 at the keyframe because of the transition which amounts to about 1 second. The essence is that rotation stops at the beginning of the transition which is about one second before the 30 seconds elapsed time so the rotation at this time will not be as you expect. If the transition were deleted (quick, no transition) then the calculations "SHOULD" be correct. I'm perplexed as to why I can't delete the transition. I can set the customize slide function to "quick, no transition" then copy and paste the slide below and it has no transition. If I then remove the original with the transition and move up the copied slide which has no transition, the transition time again appears. Very perplexing......

If there is a bug, I think it's in the transition issue rather than the keyframe issue. I'll check further.

Lin

[fh1805]

Lin,

I agree it's very easy to get a keyframe at a precise point by keying in the value into the box on the O&A Animation tab. But it is impossible to get this keyframe to have the correct rotate setting unless you either get very lucky and hit the spot "dead-on" with the mouse-click or do some horrendously complicated mathematics to arrive at the answer.

The problem isn't with the half-way keyframe of the example (15000ms equates to -720 degrees of rotation; I don't even need a pocket calculator for that one!) But what rotation will have been achieved at 4500ms into a 30second slide? and at 4550 and 4575 and all the other keyframes I need to place with precise accuracy as to both time and amount of rotation

There may well be a secondary problem with the keyframes being placed too close together for the calculation engine to keep up. But right now, I've got a primary problem in that I cannot even set the keyframes with the total accuracy that I need.

regards,

Peter

[Lin Evans]

I still think the problem is with the transition. You "can't" get rid of the 3000 transition. No matter how you set it, it remains. Look at the timing on the first keyframe (the keyframe itself) - it's not zero even though it shows zero in the keyframe block. Set the slide to "quick, no transition". The transition remains at an indicated 3000ms (three seconds) even though the customize slide shows a setting of 1000ms (one second).

Setting things to zero for transition then copy/paste slide results in no transition indicated. Remove the slide then move up the one with zero and the 3000 ms re-appears. Delete the one keframe at that point and it still remains. The timings will never be accurate as long as there is a bug with the transition time. Your "assumption" is that you have a 30 second slide when in fact you do not have a 30 second slide because of the incorrect transition time....

Look at your first slide. You have zero transition set yet there is a 1000ms transition indicated on the timeline????

On further reflection, I think this whole issue is related to the problem which will be addressed shortly where the PTE file is not being updated properly. You probably made multiple changes over time in your experiments and these changes were not properly updated in the PTE file resulting in any number of problems which show up as strange timings, transition times which will not delete, etc.

Best regards,

Lin

[fh1805]

Lin,

Here's an even simpler project that illustrates the point I'm trying to make.

The project file was created as follows:

- File...New...and give it the name RotateBug2

- Project Options...Effects... and turn off all effects so that all transitions are "Quick"

- add Black Slide, Background slide and Black Slide in that order

- check that everything looks OK in the Slide List, the Timeline and on each image in the O&A window - It does!

- from the Slide List, select slide number 2

- into O&A

- click on the O&A timeline near the right hand side but inside the slide duration area and add a keyframe setting its offset to 7000 millisecs (i.e. at the end of the slide)

- check the start and end keyframes for this slide show correctly both visually and via the timestamps in their "flags" - They do!

- Add the Yellow Grad image as a child of the main image

- Resize the Yellow image to 25% zoom

- Select the background object

- Select the endpoint keyframe

- Select the Yellow object and create keyframe here

- Set Rotate for this keyframe to be 360 degrees

- Ensure that the Yellow image is the selected object and click on the O&A timeline at about one-third way along

- Create a keypoint here

- Set the keypoint time to 3500 (i.e. the mid-point for which the rotate value should be 180)

The Rotate value does not change to reflect the new keyframe value. It does not show 180 degrees but the number of degrees associated with where I clicked (and as far as I'm concerned this is a totally random value).

The question remains: how do I position a keyframe at a precise point along this timeline, measured to within less than 30 milliseconds of error, and have that keyframe pick up the correct rotate value for that precise offset?

I can add a keyframe at a precise offset (by keying in the time offset that I want)

I can pick up a correct rotate value (by clicking on the O&A timeline)

But I cannot do both at once!!!!!!

regards,

Peter

RotateBug2_Aug25_2008_20_09_13.zip

[Lin Evans]

I see what your issue is now. There are two problems - first a logical issue. You have the ability to change the rotation between any two keyframes to anything you wish. For example you may want to make 180 degrees of rotation between keyframe one and keyframe two, then make 1440 degrees of rotation between keyframes two and three.

But if you simply set keyframe one to zero degrees of rotation and the last keyframe to 1440 you will have exactly 720 degrees of rotation at the halfway point between these keyframes regardless of the real time between the beginning keyframe and ending keyframe. If you simply move the blue slider along the timeline while observing the rotation you will have precisely 720 degrees at the halfway point. But when you "insert" a keyframe, the value for the rotation is picked up at the point where the keyframe is created and it maintains this value no matter where you eventually position the keyframe. So if you insert the keframe at 360 degrees it will keep this value even if you position the keyframe at the halfway point where you "expect" to find 720 degrees of rotation. The keyframe value is not "updated' as the slider is moved.

If you set the mid keyframe time to the halfway point then type in the proper rotation for that point it will work correctly, but what you want is for the program to automatically calculate the degree of rotation to coinside with the keyframe time inserted rather than assume the rotation degree from the point of keyframe insertion.

This probably can be done by changes in programming, but for now you would have to calculate the proper degree of rotation for the particular time on the timeline and insert it manually. This could get complicated and it would be "better" to have the program calculate it for you precisely with the provision that you can change it manually if you so wish.

I'm not certain how this will work in practice because of the non-linear functions such as smooth, accelerate, slow, etc. That is I don't know the inter-relationships at the code level but you could ask Igor if this change is possible.

The second part of the problem is the nagging refusal of PTE to properly update which complicates trying to resolve the other issue. Right now it's necessary to go into the PTE file and manually remove the 3000 to make it correspond with your one second (1000) transition.

Best regards,

Lin

[fh1805]

Lin,

Thanks - and sorry if I got a bit "het up" in that last post of mine. I'll PM Igor and ask him to have a look at this thread from the point of view of giving us an option to have PTE calculate the rotation value in the way in which I need it - with manual over-ride, of course!.

regards,

Peter

[xahu34]

Peter,

Some time ago (as far as I remember) I asked for the feature to enter manually the time for a keypoint which is to be ceated. I use the following workaround:

1. Add an additional object (a frame) in the background without any animation.

2. Highlight this dummy object.

3. Move the blue cursor to a point near the place you like to have it for your rotation object.

4. Create the keypoint (for the dummy) and adjust it via the keyframe time field.

5. Highlight the rotation object, the cursor remains at the position where it should be.

6. Create the keypoint for your rotation object.

Does this help?

Best regards,

Xaver

Munich

[Lin Evans]

Hi Xaver,

Nice viable work-around for finding the precise location for the keyframe....

Best regards,

Lin

[fh1805]

Xaver,

I really do appreciate all the helpful suggestions that are coming from folks on this one - but I don't think yours is the answer to this particular problem.

Consider this: I have an object that is set to rotate through 1440 degress in 30 seconds. At 4500, 4550 and 4575 milliseconds into the rotate I want to program a Zoom (increasing the size between the first two of these keyframes; and returning it back to its original size between the second two).

It's simple to set the keyframes at those time offsets.

It's simple to set the bigger zoom value on the middle one of the three keyframes

But what rotate value should each of those three keyframes have in order that the rotation continues without any pause, speed increase, or speed slow down?

The problem is all about having the rotate value calculated for these three keyframes by PTE so that there is no apparent change to the rotating object other than the brief flash up to a bigger size and back again (a "pulse" as I think of it).

Wait a minute! You're a genius, Xaver! Whilst sorting out my thoughts to argue this point with you, I've just realised what the answer is. The rotating object needs to be set on two nested frames. I use one frame to control the rotate and the other to control the zoom - I think!.

Now I know what I'll be doing in the morning! Indeed, I'm so certain that this will solve the problem that I'm going to go and pour a glass of red wine to celebrate!

I'm off the air for the rest of the night, everybody!

Thanks, pal!

Peter

[Lin Evans]

Hi Peter

216 degrees

218.4 degrees

219.6 degrees

Lin

It's simple to set the keyframes at those time offsets.

It's simple to set the bigger zoom value on the middle one of the three keyframes

But what rotate value should each of those three keyframes have in order that the rotation continues without any pause, speed increase, or speed slow down?

[xahu34]

Hi,

I forgot to say one thing: You have to program the start keypoint and the final one first (with their rotation parameters). If you then insert the additional ones in the way I described, they will inherit the appropriate angles.

Best regards,

Xaver

Munich

[fh1805]

Xaver, Lin and all,

You're not going to believe this. In the first half of the Kaleidoscope sequence I used nested frames to keep the rotate programming separate from the zoom programming without realising the significance of what I was doing.

The solution was already there in my sequence. I just didn't realize it!

Thanks for helping me arrive at this new state of enlightenment.

Tomorrow I set about introducing consistency into my programming of "Kaleidoscope" - something I should have done right from the start!

Sorry to have been such a pain.

regards,

Peter

[xahu34]

Peter,

I'm glad to see that you have found your solution. Using nested frames or using a dummy frame outside (which can be deleted after final use) to make the intermediate adjustments, will in the end lead to an equivalent result. So let me come back to my suggestion from April 9, see here. If we had this feature, nested frames or dummy frames could both be avoided in this situation.

Best regards,

Xaver

Munich

Additional remark (to whom it my concern): For most of the non-native speakers in this English forum, it would be easier if some of of you, when posting, could come to the point more directly. Sometimes I regard it as tedious to read all the odd and ends. There must be something between writing books or stories and the telegraphic style of Ken.

[Igor]

Peter,

There is a trick which will help to reach the desired result.

Choose custom speed for Rotation and set range 1-100 (instead 0-100 by default). It will look practically as a linear speed and PicturesToExe will take rotate values from first and last keyframes ignoring Rotate values from intermediate keyframes (between first and last ones) - exactly what you need.

[xahu34]

Igor,

What you say seems to be true in this particular example. In general, it would be very helpful, if it were possible to position the cursor in the O&A-window to a precise position (via keyboard) in order to create a new keypoint without any need to reposition it after creation (as repositioning will "move" the inherited parameters for PRZ, with the consequence that the original flow of the animation will get lost).

Best regards,

Xaver

Munich

[fh1805]

Igor,

Thanks for that advice. How many more little tricks have you programmed into PTE that I don't know about, I wonder?

I've solved my problem by using nested frames but I'll give your suggestion a whirl (pardon the pun!).

regards,

Peter

[fh1805]

Igor,

With regards to your post above (post #19 on page 1)...

I've tried your little trick and it does the job very nicely! However, I feel that using two Frames (one to control Zoom and one to control Rotate) is, to me, a more easily understood solution. However, it leaves me with a question which only you can answer:

Is there a greater processing overhead involved with the "two frames" solution compared to the custom rotate solution?

Or to put it another way: which solution places least demand on the PC's resources?

regards,

Peter

[xahu34]

...There is a trick which will help to reach the desired result. Choose custom speed for Rotation and set range 1-100 (instead 0-100 by default)...

Igor,

Doesn't it seem logical to have the feature of ignoring intermediate keyframes to be dependent on just gluing the frames instead of having a non-linear speed profile ?

Best regards,

Xaver

Munich