[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