Hi Leo, > 1. Write a "VSE 2" and create all-new structures?
this will break compatibility with older versions of blender. Should only be done as a last resort and if you *really* know, what you are doing. > 2. Create some kind of "compatibility loader" or data import filter > that converts the old data to the new, as far as possible? That is, we > read old and new formats, but only write new format. that is *always* necessary, otherwise, you can't open old files or make sure, that on load of an old file, your new structure elements are initialized properly. This is done in doversions() in readfile.c . > 3. Convert the old structs to the new in-memory? That is, we read and > write the old format, maybe with some back-compatible changes, but use a > new format internally? nope. After each editing operation, DNA data has to be in sync, since DNA load/save is also used on undo operations(!). I'd also suggest, that you first try to make sure, that you *have* to change something, and why. Since, you guessed it, you will most likely make some people unhappy, that want to open their new .blend file with an old version and see things broken all over the place. So I'm a bit wondering, what you want to change? I tried to understand the blog post you linked some days ago. To quote your blog: (disadvantages of the current system) > 1.1. Disadvantages > The disadvantages come when we wish to perform any kind of processing > that requires access to more than just the current frame. The frames in the > sequencer aren't just random jumbles of image data, but sequences of > images that have a lot of inter-frame information: Object motion, for > example, is something that is impossible to compute given a single frame, > but possible with two or more frames. > Another use case that is very difficult with frame-wise rendering is > adjusting the frame rate of a clip. When mixing video from different > sources one can't always assume that they were filmed at the same frame > rate. If we wish to re-sample a video clip along the time axis, we need > access to more than one frame in order to handle the output frames that > fall in-between input frames - which usually is most of them. To be honest: you can't calculate the necessary optical flow data on the fly, and: most likely, people want to have some control over the generation process. (Maybe they just want to use externally generated OFLOW files from icarus?) To make a long story short: we should really just add a seperate background rendering job, to add optical-flow tracks to video tracks, just like we did with proxies, only in the background with the new job system and everything should be fine. (For scene tracks or OpenEXR-sequences with a vector pass, there even is already optical flow information available for free(!) ) In between frames should be handled with float cfras (the code is already adapted at most places for that) and the new additional mblur parameters. That has the additional advantage, that you can actually *calculate* real inbetween frames in scene tracks. For other jobs, like image stabilisation, you should just add similar builder jobs. (Which most likely don't have to write out full frames, but just generate the necessary animation fcurves.) The implications of your track rendering idea is - scary. Either you end up with a non-realtime system (since you have to calculate optical flow information on the fly in some way, which is, to my knowledge, not possible with current hardware) or you have to render everything to disk - always. I, as a user, want to have control over my diskspace (which is very valuable, since my timelines are 3 hours long, and rendering every intermediate result to disk is *impossible*!). Or, to put it another way: please show a case to me, that *doesn't* work, with a simple "background builder job" system, where you can add arbitrary intermediate data to video, meta or effect tracks. Having to access multiple frames at once during playback *and* doing heavy calculation on them doesn't sound realtime to me by definition, and that is, what Ton told me, the sequencer should be: realtime. For everything else, the Compositor should be used. You could still use RenderMode: (CHUNKED, SEQUENTIAL and FULL) to make that background render job run in the most efficient way. But it is still a background render job, which is seperated from the rest of the pipeline. As always, feel free to proof me wrong. If I got it correctly, your interface idea looks like a good starting point for a background builder system interface. So probably, if you convince everyone, that this is the best thing to do for playback, too, we might end up promoting your builder interface to the preview renderer, who knows? BTW: I'm currently rewriting the sequencer render pipeline using a generic Imbuf-Render-Pipeline system, which will move some things around, especially all those little prefiltering structures will find their way into a generic filter stack. But when I do that, I will make sure, that their is really a good reason for that, since, as stated above, it will certainly break things for some people and that should come with a real benefit, not only aesthetics... Cheers, Peter _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers