[Bf-committers] S-DNA and Changes
Leo Sutic
leo.sutic at gmail.com
Thu Nov 25 21:24:05 CET 2010
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
More information about the Bf-committers
mailing list