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