[Bf-committers] S-DNA and Changes

[Leo Sutic]

On 2010-11-26 00:28, Peter Schlaile wrote:
> Hi Leo,
> 
>> Ah, ok.
>>
>> I'd still try to stick with integer frames and a parameterless next().
>> Allowing the client to specify the advance in the next() method makes it
>> too much of a random-access method (there is no guarantee that the
>> advance is to the "next frame", which is the whole purpose of the
>> iterator interface).
>>
>> I'd do it this way:
>>
>> Suppose we have a scene where we want normal speed for frames 1-10, an
>> extreme slowdown for 11-12 and normal speed from 13-20.
>>
>> Strip 1: Scene, frames 1-10. This strip covers frames 1-10 in the VSE.
>> Strip 2: Scene, frames 11-12, with a framerate of 1/100th of the output
>> framerate. This strip covers frames 11-211 in the VSE.
>> Strip 3: Scene, frames 13-20. This strip covers frames 212-219 in the VSE.
> 
> sorry, that won't work. One can retime using fcurves.

Then you can have one strip with an fcurve to map from VSE output frames
to scene frames:

Strip 1: Scene, frames 1-20, with an fcurve that maps from VSE frames
(iterated over using next()) to scene frames. It covers frames 1-219 in
the VSE.

If I may modify your code a little:

class scene_iterator : public iterator {
public:
 	Frame next () {
                // fcurves go in map_vse_frame_to_cfra
                float cfra = map_vse_frame_to_cfra (nextFrame);
 		setup_render(cfra);
                ++nextFrame;
 		return render();
 	}
    int nextFrame;
}

VSE only sees a sequence of discrete frames - which is precisely what
its domain model should look like, because video editing is about
time-discrete sequences, not continuous. The Blender scene is a
continuous simulation - having a float cfra makes sense, because time is
continuous there. In the VSE the domain objects are discrete in time.
Having a float cfra makes no sense.

> Which brings me to the point: what was the sense in dropping the random 
> access interface again?
> 
> The imbuf reader has also a random access interface, but internally keeps 
> track of the last fetched frame and only reseeks on demand.

It is always possible to wrap a sequential interface in a random-access
interface, or vice versa. The purpose of dropping the random access
interface was to be able to write code that didn't have to deal with two
cases - you'd know that you'll always be expected to produce the next
frame, and can code for that. Less to write, less to go wrong.

Clients of the code know that they can iterate over *every* frame in the
sequence just by calling next(). With a random access interface -
especially one that uses floats for indexing - you'll always worry if
you missed a frame, or got a duplicate, thanks to rounding errors.

/LS