Hi Peter, thank you for your feedback on the SDNA.
You bring up some very good points, let me try to address them quickly: On 2010-11-25 19:45, Peter Schlaile wrote: > Or, to put it another way: please show a case to me, that *doesn't* > work, with a simple "background builder job" system, I thought about that yesterday, actually, because it seemed such a simple solution. But let's consider the background builder job itself. In principle, there is nothing that can't be factored out as a background builder job. I mean, I can do anything I want in an external program and then just place the end result in Blender. But then I have to build a UI for my stabilization program, and the whole purpose of doing any work on Blender was to put my stabilization algorithms there in order to have a nice UI. By "nice" I mean to be able to combine video effects in the VSE much like I can combine nodes in the compositor. I want to be able to apply stabilization, interpolation, etc. by stacking effect strips. Combinatorial power, I think it is called. This means that the "background builder job" ends up being more or less a render in anything but name. It needs access to the same data as a render - output from previous effect strips. That's why I need to involve the main rendering pipeline. I wish I didn't have to. > 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*!). Correct, it is impossible. You've asked this once before (way back), I replied in: http://lists.blender.org/pipermail/bf-committers/2010-September/028825.html and you thought: "that sounds indeed usefull" http://lists.blender.org/pipermail/bf-committers/2010-September/028826.html Short-short summary: The system need not do it the naive way and write out every frame. We can also optimize away a lot frames being held concurrently in memory by using smart algorithms. The current state of the prototype code is that *nothing* is being written to disk, and it never renders more frames than absolutely needed. Eventually I might need to include the option of writing out some things to disk but I consider that a last resort, and only for operations that the user *knows* will cost a lot of disk. This, however, is not a consequence of the strip-wise rendering algorithm itself, but of the processing we want to do. /LS _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers