[Bf-committers] S-DNA and Changes

Peter Schlaile peter at schlaile.de
Thu Nov 25 21:54:42 CET 2010

Hi Leo,

> 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,
> That's why I need to involve the main rendering pipeline. I wish I
> didn't have to.

hmm, that's maybe a misunderstanding. I was talking about using the job 
system of blender 2.5 (which just forks another job within blender - not 
an external system/program!). So: still complete access to UI.

> 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

again, maybe a misunderstanding here. In that old post, I was more 
thinking of rendering seperate tracks in advance for prefetch rendering.
Not: making CPU heavy stuff run in the previews.
(But I didn't make that point really clear, that's true.)

> 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.

ok, point taken. I'm still a bit unsure about the CPU-heavy stuff, but I 
have to admit, that you could always add a proxy, if things start to get 

Regarding your interface prototype: your interators should take a float 
increment parameter. (There isn't really a well defined "next" frame in 
float precision scene-rendering...)

Otherwise: this could really work.


Peter Schlaile

More information about the Bf-committers mailing list