Download the norf94.pipmak file http://www.gunda.hu/downloads/norf94.pipmak from here which contains a single node with a green rippling circle. The
moving ripples are made up of 8 pictures with the different phases. The
movement should be slower, but when the timing constant is greater than 0.1
the rippling starts to lag. So I decided to embed a dissolve method into the
schedule function hoping that the lagging caused by a longer timing could be
counterbalanced by the smoothed transition.
Open the node.lua file, enable the dissolve method and experience with the
timing constant and the return time. I have the feeling that schedule
overrides dissolve - in other words schedule function does not wait until
dissolve finishes but continues and stucks again before the previous
dissolve had been finished and so on. Therefore it is difficult to stretch
the transitions and to preserve smoothness on the same way. Am I right?
View this message in context: http://old.nabble.com/Dissolve-within-schedule-tp32227740p32227740.html Sent from the pipmak-users mailing list archive at Nabble.com.
Sorry for the slow response, I've been really busy with Zik Clock and ULP this week.
> schedule function does not wait until dissolve finishes but continues and stucks again before the previous dissolve had been finished and so on.
This is correct, and is the intended behavior.
- Not waiting: Keep in mind that transition functions like pipmak.dissolve() only set up the transition, they don't wait until it is finished (pipmak functions can never wait for anything, they must return immediately, because Lua execution happens in lock-step with rendering - while your Lua code is running, the screen is not updated). What you return from a scheduled function is the interval to the next execution starting from the last execution (these are points in time, how much time the function actually takes to execute is irrelevant), not starting from when anything set in motion by the last execution finishes. Would you expect that when a scheduled function sets up a transition, the duration of the transition is added to the new interval it returns, so that the interval only appears to start after the transition is done? I think that would be an unnecessary restriction. If you want that, just add the transition duration yourself.
- Starting again: It is true that when you start a new transition while a transition is already running, the initial image of the second transition is taken from the current state of the world as it exists behind the running first transition, not from the currently visible state of the first transition. Whether that is a good thing is debatable - on the one hand it causes a visual discontinuity, on the other hand deforming an already deformed source image again may be undesired too.
So, I think the correct solution to your problem is to make the duration of the transition equal to the timer interval, e.g.
This makes the transitions exactly adjacent - no overlap, avoiding the discontinuity that would cause, and no period of static image in between.
Now that the animation still looks uneven with this is caused by a different effect: it is that the transitions are not linear, but start slowly, accelerate, decelerate, and end slowly again (a cubic curve with slope 0 at the beginning and end). When I experimentally make the transitions linear, the animation becomes much smoother. (It still doesn't feel completely even, I haven't examined whether that's an optical illusion because it alternates between blurry and sharp or whether there's still something wrong with the timing.) I guess something like "pipmak.lineardissolve()" could be introduced for that, or the transition curve could be made customizable in general.
However, another problem with continuous transitions like this is that you can't look around while a transition is running. This is because a transition happens between two static screenshots, not between two live 3D scenes. Changing that would be possible but not very simple. Because transitions can be (and are most commonly) used between two nodes, it would mean that two nodes (or stacks of nodes) would need to be kept running simultaneously, which the current code does not support.
Addendum: It occurs to me that you could achieve your desired effect by doing it yourself instead of using a transition: have two patches on top of each other with adjacent frames of the animation, and fade the top one in or out using patch:setalpha().