Hi Jason, from this discussion I guess we are pretty much on the same track ;-) Very promissing ;-)
On Monday 04 November 2002 08:27 pm, Jason Wood wrote: > Neither am I, scenes are what I used within the cutting list specification. > I used a screengrab of the timeline as a simply means of showing (I hope) > how I would break down the graphical representation to create scenes. Ok, good. And why again do we need scenes? > Ok, here is the way that I see it as working at present : > > 1. The Timeline is represented as shown, with tracks capable of sliding > over each other, they can be resized, chopped up, have effects, applied, > you name it. Ok. > 2. When we want to render something (preview, production, etc.) We take > this internal GUI representation and translate it into a number of scenes, > which we then pass onto a scheduler. Why break it up in scenes? > 3. The scheduler looks at the scenes that it has been asked to process, > compares them to scenes that have already been processed, and substitutes > in any pre-rendered caches that it has for scenes, or partial scene trees. > The now-modified scenes get passed onto the the renderer(s) to be > renderered. Except for the scene-part. Great. > (On a sidenote, it's hard to describe how the scheduler will work, but it > effectively acts as a proxy between the GUI and the cutter(s), and is their > to make the most effective usage of resources that it can. Essentially, it > should be transparent to both GUI and the cutter.) Well, If you eant to render a 60 sec part on ten mashines, why not split it up in ten 6 sec parts? A further improvement can be an analysis on predicted render speed based on the complexity of the tree and then pass chunks of equal predicted rendertime to the ten renderes. I mean, if the whole production is represented as a single tree, you just pass this tree to all renderes and tell them which frames (time intervall) to render. Why break it up in scenes? > Just in case I am not clear about what a scene is, a scene itself is > represented as a tree in the same way that you represent media elements, > (operators, nodes, leaves, the lot) but they are strung together in serial > fashion to make the entire movie. Ok, good, that's what I understood, but good to be sure. > If you like, a scene is a "building block" element for a movie. It > describes a transition between two videos, or an effect of a part of a > video, or just the playback of a single video, or it could describe how 30 > seperate videos should be combined correctly to perform a complex effect. > But it only describes one such thing, and then another scene takes care of > the next bit of the movie. > > As far as I can tell, this "should we break the tree up into chunks or not" > is the only difference between your view of how the cutting list should > work, and my view. Yes I agree, and that is really not a big difference. I guess this difference will be washed out as the project matures, we'll just see what we really need. Maybe I just can't see far enough at the momen. > Effectively, it is your idea of a PropertyNode. You specify "key frames", > which are those frames where you specifically say "This property should be > this value at this time", and you specify what interpolation needs to occur > to get from one key frame to the next. Yes, that is what I mean. > I really don't think this is worth arguing over at this moment in time. > Let's discuss again when we are implementing the interface for transitions. Agreed ;-) As I said, we'll see more clearly what we need as we code on. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ ***************************************************************
