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 slow. 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. Cheers, Peter ---- Peter Schlaile _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers