[Bf-committers] Compositing from Different Renderers

Aaron Moore two.a.ron at gmail.com
Sat Jul 14 02:55:04 CEST 2007


Hi Ton,

On 7/13/07, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
> Per Scene. Per Layer cannot work, and conflicts with design. The
> concept of a render-layer is to have many renders possible with *one*
> database of render geometry. Layers share shadow buffers, octrees, can
> share Zbuffers, etc.
>
> Check the render pipeline design to see why.

I was proposing a possible interface change, but if you wish to see a
possible implementation change to go along with it...

 [ scene ] --
                  |----- [ render result ]------
                  |       blender internal       |----- [ render layer ]
                  |                                       |----- [
render layer ]
                  |
                  |----- [ render result ]------
                           yafray                     |----- [ render layer ]
                                                          |------[
render layer ]

Nicer version of diagram:
http://dreamforgers.dreamhosters.com/aaron/soc/engine_per_layer.jpg

Instead of specifying the engine in the scene, specify it in the
render result, of course, the addition of the engine that was
rendering the render layers to the result would perhaps make the name
"render result" a little odd, that might be changed to "render job"
perhaps. Or perhaps not, it just seems odd to me.

Then you could specify the engine per render layer. How? By writing
functions to place the render layer in the correct render result for
the engine that it is using. When a render layer switched renderers,
it would call a function which would scan the render results, remove
it from the current renderer and add it to the new one.

Of course, this is only one first impression design. The basic idea
being, sort render layers by engine, which is the same thing that is
happening when you specify the engine per scene, except it gives you
more flexibility.

> Where is a diagram explaining the flow for the new API?

This diagram would require that I design the reworking of the pipeline
to conform to the API. Since I'm smack in the middle of designing and
implementing the API, I don't have the prerequisite for producing such
a diagram yet. Once the API is finished enough that I can design the
reworking of the pipeline, I will produce such a diagram.

Aaron


More information about the Bf-committers mailing list