[Bf-committers] Proposal: Remove fixed upper bound on number of render layers and pave the way for stacked image layers

Brecht Van Lommel brechtvanlommel at pandora.be
Thu Dec 15 14:36:32 CET 2011


Sorry for the late reply ...

On Thu, Dec 8, 2011 at 2:44 PM, Konrad Kleine <kokleine at googlemail.com> wrote:
> I've been wondering if there's a particular reason why the Image
> struct defined in DNA_image_types.h has an upper bound on the number
> of render layers (#define IMA_MAX_RENDER_SLOT 8). If it's possible to
> have "n" render layers (e.g. use ListBase), then we might actually be
> able to use the render layers as "image" layers and not only as
> "render" layers.

This is not a limit on the render layers though, it is for render
slots, to compare different renders. Each of those slots can contain
multiple render layers.

> A while ago when I proposed to introduce a new layered ImBuf stack to
> the basic Image struct, people objected because it would have been a
> pain to integrate. Whereas the render layers are already accessible
> through the compositor and so forth. I must admit that I totally agree
> with this objection.
> One might not need more than 8 image layers when rendering but nearly
> everybody needs more than 8 layers when it gets down to painting
> images in Gimp or Photoshop, right?
> Here's my proposal and some implications that came to my mind:
> 1. Code-wise replace the render layers array with a List of render
> layers (whole lotta work, I know)

Given the above, this is actually already the case. RenderResult
contains a list of render layers. The main issue here is that it's a
data structure that is tied into the render engine, but is also used
for multilayer EXR images that are not necessarily renders.
Refactoring multilayer images so this so it is less tied to the render
engine and the EXR image format would be a good idea I think.

> 2. Enrich the render layer struct with information more related to 2D
> graphics software (e.g. opacity, mask, etc.)
> 3. Associate the order of elements in the render layers list with the
> order the images are stacked upon each other (e.g. first element in
> list is the front image)
> 4. Build UI that can handle layering of images on top of each other
> (e.g. http://wiki.blender.org/index.php/File:Soc-2010-kwk_image_layers.png)
> 5. Somehow allow compositing the image as a whole (e.g. through
> blender's compositor or OpenGL texture blending)
> 6. Change the preview mode for images (blender-wide?)

This I'm not so sure about. While layered images are nice, it's also
adding more complexity. Personally I don't think we should try to
support this type of image layers that is composited together, I'd
rather leave that to painting apps. What might fit better is the
ability to attach a compositing node tree to any image?

Also, for texture painting, images can be layered in the material
(using the texture stack or nodes), and we should make that workflow
easy to use.


More information about the Bf-committers mailing list