[Bf-committers] Render Layer Proposal

François T. francoistarlier at gmail.com
Wed Jan 18 10:03:42 CET 2012


Yes it is true that RenderLayers are a bit of a mix up in Blender where it
is actually Layers/Scenes manipulation and passes at the same time, which
makes complicated the way to add another pass (except by going through a
mat overall).
But I was trying to keep things simple and stick to the actual design to
hopefully have it being faisable by just redirecting each buffer we already
have into different image sequence.

MultiLayer can be nice in some cases but it is usually slow. The other
downside is that if you want to, for instance recompute your AO pass, you
are good to re-render everything. :/ So several image sequence is very
common.

cheers,

F.

2012/1/18 Matt Ebb <matt at mke3.net>

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



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier


More information about the Bf-committers mailing list