Re: Dissolve within schedule

[Christian W. <cwa...@gm...>]

Hi Norfren!

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.

	pipmak.dissolve (1, 0.5)
	ring:setimage("n94_ring" .. ring_wave .. ".jpg")
	return 0.5

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.

Hope that helps clearing things up.

 -Christian