[Bf-committers] Render Layer Proposal

[Matt Ebb]

On Wed, Jan 18, 2012 at 5:24 AM, Ton Roosendaal <ton at 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.