On Wed, Jan 18, 2012 at 5:24 AM, Ton Roosendaal <t...@blender.org> wrote: > > 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?
I think he's asking for an easy way to output render layers/passes to individual files. It's generally not good practice to include all layers/passes/outputs etc in a single EXR file if you're going to comp with it. Due to how EXR stores data, the entire file must be read before any data is accessed, so reading RGBA channels will also need to wait for all other exr layers as well, which slows things down in a compositor by a factor of how many layers there are. In most comp pipelines (especially on network storage), i/o is a significant bottleneck, so single files are used to allow access on demand. I agree blender's render layer/pass system could use some significant improvements, this being just one of them. Hopefully with cycles, it can move to more of a 'named output' type system rather than hard coded as in blender internal. I made some notes on this topic in a forum discussion previously - it's pasted below if anyone's interested. cheers Matt --------- The terminology blender uses here is a bit non-standard. Where Blender has render layers and render passes, other renderers have render passes and outputs (AOVs - arbitrary output variables). The way most renderers with programmable shading that I'm familiar with work, is that within your shader (whether that be code or a node tree or whatever), you can define any number of outputs in addition to your main colour output. You can then send whatever data within your shader network that you're interested in, to that output. For example you could wire a raw texture colour straight to an output before it's used for shading. Once you've defined outputs within your shader, then in your scene you can add those named outputs to your render. So if your shader defines an output named 'tex_colour', if you add an output named 'tex_colour' to your scene to be rendered, it will generate that additional image buffer at the same time as your beauty render. This means that you have complete control over what the contents of your AOVs will be, and at render time can choose which ones you are interested in. As for render passes (render layers in blender-speak), in blender internal, these don't give you a lot of control - they're just mainly for layer visibility with some additional things like overriding materials. Other apps ('Takes' in Houdini, 'Render Passes' in XSI afaik) do it differently, where you are given a blank slate to override bits of data in your scene with whatever you want. This is a bit like if you have a linked scene in blender, but can specifically override certain properties. So in your render pass you could do the same thing as blender - unlock and disable/enable renderability, or for example if you want a shadow only pass you can unlock and turn off certain lights and replace your shaders with a special shadow catcher shader, or perhaps you could only show the contribution of certain objects to GI, or whatever. The possibilities are endless, it's just a simple way of rendering various versions of your scene via a kind of 'diff'. These are pretty standard ways of achieving this sort of functionality - it's a lot more flexible and practical than blender is currently, and potentially simpler internally as well. As for hooking such functionality up to external renderers, for AOVs, there just needs to be a way to add any extra named image buffers to the render result, rather than filling in the hard-coded diff/refl/ao/blah blah that exists currently. This shouldn't be terribly difficult to implement on the blender side. As for render layers, there's not really much interaction between that and external renderers at the moment - external renderers are free to re-use BI's render layers interface, but doing things like iterating through render layers, collating visible objects and sending them off to be rendered, is all up to the exporter script. Alternatively it *might* be possible for renderer addons to implement their own 'Poor Man's Render Passes/Takes System' themselves, but it would be a lot better if blender had a system for this internally that all renderers could use. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers