Animation Keypoints

[aplman]

Hello All!

Having read recent discussions and tutorials on the subject of animation keypoints, I did my own research. It is interesting to compare the two PTE files, before and after making small changes. I made some interesting discoveries. I would like to share my findings here, for the benefit of users at a similar stage to myself.

First I created a new project, and dropped in three images. My transitions are all of length 1 second, and I set each slide to have a duration of 5 seconds. Please see file TEST-1.PTE attached. This discussion will centre on the animation of slide 2.

At this stage, the only keypoint for slide 2 (in Objects and Animation) is at the beginning of the starting transition. Looking into the text of file TEST-1.PTE, we can see that [slide2] includes a single object, representing the main image.

Then I placed three more keypoints precisely at four key positions on the timeline - the end of the introductory transition, the beginning of the next transition, and the end of the slide. O&A shows that these are timed at 5, 6, 10 and 11 seconds. Now I save as TEST-2. We can see in the file TEST-2.PTE that the main image object in slide 2 now has four embedded object blocks. These represent the four keypoints. Notice that each object block has an Origin= parameter, and respectively they are SlideBegin, PrevEffectEnd, NextEffectBegin, and SlideEnd. Each object includes the line "Time=0". This, I presume, is why we see a + on the keypoint in O&A - they are special points.

Now I place two more keypoints at 7 seconds and 9 seconds, and save as TEST-3. In the file TEST-3.PTE, there are now two more objects - KeyPoint3 with parameters Origin=SlideBegin, Time=2000, and KeyPoint4 with parameters Origin=SlideBegin, Time=4000.

Let's think about KeyPoint3. I suspected that if, instead of simply adding it with the + button, I had cloned the second keypoint (6 seconds), and positioned the clone at 7 seconds, I might have seen these parameters in KeyPoint3: Origin= PrevEffectEnd, Time=1000. But PTE does not work that way ... new keypoints, however created, are given a time relative to SlideBegin, unless they coincide with one of the four special points.

Next I edited the file TEST-3.PTE, and saved TEST-4.PTE. In it you will see that in KeyPoint3 , the lines with parameters Origin=SlideBegin, Time=2000 have been replaced by the lines Origin=PrevEffectEnd, Time=1000, in line with my hypothesis in the last paragraph. Similarly, KeyPoint4 now has the lines Origin= NextEffectBegin, Time=-1000 (that’s minus 1000). The good news is that works nicely in PTE, and we see the keypoints at the same position as before. So it appears that the position of our keypoints can be defined relative to any of the four special points, with either a positive or a negative displacement.

Even better news is the we can change the duration of the slide, and keypoints 1, 2 and 3 will maintain their positions relative to the left end, and keypoints 4, 5 and 6 will maintain their positions relative to the right end. That’s providing we do NOT have “Scale keyframes in objects” ticked in Customize Slide”. File TEST-5.PTE illustrates slide 2 with a duration of 10 seconds. Keypoints 3 and 4 are still close to either end, as before.

The not so good news is that if want to keep the keypoints proportionally spaced over the new duration, by ticking “Scale keyframes in objects”, it will not work. Unfortunately, PTE reverts in that case to timing positions relative to SlideBegin, and messes up the timing. TEST-6.PTE shows what I got after adjusting slide 2 in TEST-4.PTE, by turning on Scale keyframes in objects and then setting the new duration.

Examine the keypoints in O&A, and you will see some shown in red, indicating multiple keypoints at the same timing position. By looking at the object code in the PTE file, we can see that keypoints 2 and 3 have the same Time=parameter, and keypoints 4, 5 and 6 share the same time. This is quite nasty. On some occasions, I was unable to separate, move or remove those keypoints ... but this may be part of the Windows 7 64-bit trouble I have been having.

[aplman]

Oops! Sorry. I forgot to attach the test files. Now attached here.

APLman (Ken)

KeyPoints.zip

[aplman]

and Image files attached here.

Ken.

KeyPointsImages.zip

[fh1805]

APLman,

It is my understanding that when using "scale keyframes..." the four special cases that you identified do not move. Only the keyframes between the end of the previous transition and start of the next transition move. The four special keyframes will change their time positions only if the transition durations are changed. Are you seeing something different to this?

Overlapping keyframes are, in my opinion, best dealt with by clicking on the time flag and adding a few micro seconds until each of them has a unique keyframe time. Then you can study each of them and decide which you want where.

From your post it sounds as though you are investigating the project file with a view to understanding it so that you can write some routines of your own to process it. Do remember that the structure of the project file might (will?) change with every PTE version as Igor adds in more function. You are setting yourself up to have to do constant maintenance to stay abreast of PTE's future development.

Also, and as an aside, the best way to package your project is to do File...Create Backup as Zip. This will place the .pte file and all its associated image and sound files into one zip file. In your specific case you would then have needed to add the other .pte files into that zip manually to give us the complete package.

regards,

Peter

[trailertrash]

Whatever all that is " I'm agin it "

[fh1805]

Andrew,

You're still working your way along the learning curve. Take your time and build up your knowledge and understanding slowly. You will get to this point eventually - and when you do, you will then understand!

regards,

Peter

[Guest Yachtsman1]

I'm not holding my breath

Regards Eric

Yachtsman1.

[xahu34]

APLman,

I must admit that I have avoided to read your long post in detail. There has already been a bug report on the behavior of keypoints with respect to scaling that has never been addressed by WnSoft, see here!

Regards,

Xaver

[aplman]

Peter, I thank you for each of your comments.

It is my understanding that when using "scale keyframes..." the four special cases that you identified do not move. Only the keyframes between the end of the previous transition and start of the next transition move. The four special keyframes will change their time positions only if the transition durations are changed. Are you seeing something different to this?

Yes, I do get a different result. If "scale keyframes" is used, only the SlideBegin and SlideEnd keyframes keep their special positions. All keyframes between SlideBegin and SlideEnd (not inclusive) are scaled. If there are keyframes at the special points PrevEffectEnd and NextEffectBegin, they are converted to SlideBegin (with a new Time= value, of course), and then scaled. So they no longer have their special location.

I am currently preparing a full report on my findings and my wishes. I think PTE's animation is amazingly good, lots of fun, and extremely flexible. I hope I can contribute to a better scaling function so that it will be more widely appreciated.

I believe keypoints that lie within a transition should be not be scaled unless the transition time changes.

I believe very firmly that keypoints that DO NOT lie within a transition should be scaled according to the changing length of the non-transition duration only. At the moment, the scaling is proportional to the total time of the slide including its before and after transitions. That makes very little sense to me. Surely animation during a transition must be fairly rare? I only find animation desirable during the main (non-transition) view of an image.

Overlapping keyframes are, in my opinion, best dealt with by clicking on the time flag and adding a few micro seconds until each of them has a unique keyframe time. Then you can study each of them and decide which you want where.

Agreed.

From your post it sounds as though you are investigating the project file with a view to understanding it so that you can write some routines of your own to process it. Do remember that the structure of the project file might (will?) change with every PTE version as Igor adds in more function. You are setting yourself up to have to do constant maintenance to stay abreast of PTE's future development.

Also agreed! I was hoping to find the challenge [a] fun and not too frequent.

Also, and as an aside, the best way to package your project is to do File...Create Backup as Zip. This will place the .pte file and all its associated image and sound files into one zip file. In your specific case you would then have needed to add the other .pte files into that zip manually to give us the complete package.

I take your point ... Thank you for that. My previous submission was not well presented.

Best Wishes ...

Ken.

[aplman]

APLman,

I must admit that I have avoided to read your long post in detail. There has already been a bug report on the behavior of keypoints with respect to scaling that has never been addressed by WnSoft, see here!

Regards,

Xaver

Thanks for your comment Xaver. I had not found that previous post.

I noticed there that some folks think the scaling option is not very useful in its present form. I hope to see it fixed properly, because PTE's animation is a great fun, flexible feature. As I see it, there are several problems to be addressed ... if we users can agree on what we want! I'm working on a suggestion document for the "Ideas and Suggestions for Next Versions" sub-forum.

Regards

(APLman) Ken

[pedro.silva]

hi APLman!

just make sure you don't write your document so it must be interpreted right to left -- please! ;-)

cheers,

pedro

Thanks for your comment Xaver. I had not found that previous post.

I noticed there that some folks think the scaling option is not very useful in its present form. I hope to see it fixed properly, because PTE's animation is a great fun, flexible feature. As I see it, there are several problems to be addressed ... if we users can agree on what we want! I'm working on a suggestion document for the "Ideas and Suggestions for Next Versions" sub-forum.

Regards

(APLman) Ken

[aplman]

hi APLman!

just make sure you don't write your document so it must be interpreted right to left -- please! ;-)

cheers,

pedro

Thank you, Pedro, for bringing a smile to my face! It's always good to find someone who has heard of APL!

Ken

[pedro.silva]

no worries, glad it served the intended purpose! your alias and interests also brought a smile to my face, thinking of when notation [w]as a tool of thought...

cheers,

pedro

Thank you, Pedro, for bringing a smile to my face! It's always good to find someone who has heard of APL!

Ken