[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:

and you thought:
"that sounds indeed usefull"

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.


More information about the Bf-committers mailing list