[Bf-committers] Render Layer Proposal
Ton Roosendaal
ton at blender.org
Tue Jan 17 19:24:22 CET 2012
Hi Francois,
I can't follow your text really.
Instead of explaining why you need it, or calling it "better" or "more useful", just write down a neutral and very precise specification of how it looks what you want? It seems to me you like some Openexr file version that's between the MultiLayer and the regular (RGBA+Z) exr file we have?
-Ton-
------------------------------------------------------------------------
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 17 Jan, 2012, at 18:01, François T. wrote:
>>
>>
>> I have however a few questions:
>>
> Note that all my points are in case you are NOT using Multi-Layer and NOT
> using compositor
>
>
>> What do you mean saying that "Only the first RenderLayer gets rendered"?
>
> When you render to MultiLayer exr - all passes of all render layers
>> get stored.
>>
>
> Let say you only using RenderLayer for the "layer selection" feature (aka
> different object on different layers). and you do render into a PNG
> sequence. Only the first RenderLayer of your list get rendered.
> Other example, you are using RenderLayer for Material Overall feature
> (regardless passes)... same issue here
>
>
>
>> I don't quite follow. If you really want to store all of the passes -
>> you simply select MultiLayer as a format and you're done.
>> You can add in in compositor in some other file if you wish and have
>> full access to all of the passes of all of the render layers.
>> I don't fully understand what you mean here.
>>
>
> Again, same here, of course you can do that ! but this proposal as I
> mention is in case you don't want or can't use multiLayer format.
> And going through the compositor via a Multilayer EXR to seperate passes,
> or directly use the RenderLayer Node in compositor to split via FileOutput
> node is a terrible pain less workflow AND slow down your render time
> because of all this useless steps
>
> Maybe I wasn't clear enough in the proposal, but all you are mentioning is
> obvious, since it's the only way we can do it now :p. My concern is to
> bypass this and make the workflow better and faster (faster in user time in
> manipulation, faster in render time by not playing around with buffers
> traveling everywhere and getting some useless process, and not having extra
> files (render) on your harddrive).
>
>
>
> cheers,
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
More information about the Bf-committers
mailing list