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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers