The Blender render pipeline went through a full recode, resulting in quite some changes in the implementation and workflow.

This diagram shows what happens when you start an animation render (ANIM button) or an image render (RENDER button). In Blender, an animation render will enter a loop, saving out images or a movie files. A single image render will only return and display the result.

The main block detects the main pipeline options, which involves checking for a Sequencer render, or a 3D render and/or Compositing. Both the Sequencer and Compositor can again invoke a full render of another Scene.

Per Scene, the result of rendering is stored, which is a linked list of 'render layers' which in turn has a list of 'passes' which store the actual buffers.

Read the API specification in Blender Wiki.

This page now will describe the end-user aspects only.

The preview render in the Shading buttons now makes use of the Blender Render itself. This used to be a separate routine, with own shading code, causing previews to be rendered inaccurate.

The new Preview Panel also offers a couple of additional previews options (plane, cube, small sphere, large sphere, monkey head). For the future a couple of additional options should be added, like for ray tracing and hair render.

What gets rendered here is just a Blender scene and file, which is now hardcoded compiled in Blender. You can find this file in Blender cvs, in blender/release/datafiles/preview.blend.

Previews can also be rendered in the 3D window, this is a scalable Panel accessible with the hotkey Shift+P.

This preview uses the new render pipeline feature to be able to render incrementally. This means that all render data (including octrees and shadowbuffers) only gets created once, allowing editing changes you make to be rendered again quickly. On each keyboard or mouse-move event a preview render will escape from the rendering loop, keeping the UI interactive.

Currently a fast re-render update happens only for:

- moving the Panel around or changing its size

- changing Material/Texture properties (But not for Halos yet, or a switch for ZTransp).

Force a full refresh of the preview by pressing SHIFT+P twice.

This preview render also uses the "Local View" option (in numerical pad, slash key), meaning you can display the selected Object(s) only, but still render with the lights from the original layers. Use this option for fast preview renders.

For a good understanding of the Blender render pipeline, here's a diagram of the internal structure of all the image buffers that can get created on a render.

Scene

As usual, a Blender file (i.e. the project you work on) can consist of many Blender Scenes, each with individual render settings and shared or unique Objects.

The Render pipeline is fully 'localized' per Scene, ensuring renders can happen per Scene independently or even in parallel.

RenderResult

One of the first steps of rendering a Scene is to create the RenderResult, this is a container for all RenderLayers and Passes, and it stores the result of Compositing or Sequence edit. Each Scene will get its own unique RenderResult, but multiple RenderResults per Scene can exist as well (as illustrated by the new 3D window preview).

RenderLayer and Passes

Once all 3D rendering geometry has been created and initialized, the pipeline goes over each RenderLayer in succession to fill its "passes" with data. Per RenderLayer you can define which geometry is being rendered (like Solid, ZTransp or Halos). The Pass is the actual image and can store anything, like the RGBA 'combined' result of a render, or the normal value of a render.

If you use compositing, you can find the RenderLayers in a "RenderResult Node" as a menu option, and its passes available as output sockets.

Apart from the obvious memory constraints, there's no limit in Blender for the amount of layers or passes in a single render command.

This is the most interesting aspect of the new pipeline, offering an artist advanced control over what gets rendered, especially in relationship to compositing features.

A "RenderLayer" allows to render a sub-set of the 3d geometry that has been generated for rendering the scene. A typical situation is for example to split a rendering in a foreground and background, which then can be blurred independently and combined again. The new render pipeline allows to define such layers in advance, which then all get rendered at once, and delivered as individual 'images' to the Compositor for further processing.

The two main options to define RenderLayers are:

- indicate to render Sky, Solid faces, ZTransp faces, Edges and/or Halos

- indicate which "View Layers" have to rendered.

The Blender render system already renders Solid faces seperately from ZTransp faces and Halos. By default these get combined in a predefined order (first Solid, then Halos added, then ZTransp added). By using the RenderLayer options you now can choose to store these layers separately and combine it with compositing in the order you prefer.

Also note that "Edges", since it is zbuffer based, only works for the Solid faces now.

In spite of its name, a RenderLayer is really different from View-layers. You can consider a RenderLayer as if it's a layer in Photoshop or Gimp, the View-layer is only a visibility flag for Objects or faces.

This means that you first have to set the visible View-layers for the Scene, as usual, to indicate which Objects have to be included. Then, as additional control, you can indicate which of these Objects are actually rendered by setting a visibility-layer per RenderLayer.

Shadow and ray-tracing

It is important to realize that shadowbuffers and the Octree (for ray-tracing visibility) get generated in a preprocess, so these are identical for all RenderLayers as indicated.

That means you can separate a foreground from a background with RenderLayers, but still get a combined image as if it was rendered in a single pass.

In the example image, the floor is in view-layer 1, the monkey in view-layer 2, the lights are in both view-layers. Then two RenderLayers were created, rendering these two view-layers separately. Note that the floor then still receives the monkey shadow, because the shadowbuffers were created for all geometry, independently of indicated RenderLayers.

Also when the floor would have been a mirror, the first RenderLayer would have shown the monkey reflected.

Download a test .blend file, 150k

RenderLayer and Passes UI

1) Scene visibility (view) layers

As a reminder mostly, here you can see and set which view-layers of a Scene will get converted to render geometry.

2) RenderLayers

- The browse menu button allows to set active RenderLayers or add new ones. The active RenderLayer is also the layer as displayed after a rendering.

- The name button can be used to give meaningful names to RenderLayers. Changing the name will correctly adjust names in the RenderResult nodes in a composite.

- Use the "Single" option to enfore the pipeline to only render the active RenderLayer.

- the "X" button deletes a RenderLayer.

3) RenderLayer visibility layers

Here you can set the view-layers that have to be rendered. It can only be a sub-set of the Scene view-layers.

4) RenderLayer options

In a RenderLayer you can define which of the 'geometry' options are visible and have to be rendered.

The buttons offer now the options Sky, Solid, Ztransp, Halo or Edge.

5) Passes

Here you can indicate additional storage of specific shading information per pixel. A "pass" is available as an output socket in a RenderResult node.

(Note; only Combined, Z, Vec and Nor works now. Additional pass control for shading like AO, Specular, Shadow, etc is being worked on.)

One of the annoying discoveries during the making of the Elephants Dream movie, was that 32 bits systems address much less than the theoretical maximum of 4 GB you would have expected.

Even worse, on OSX the entire Blender process was limited to use 2 GB only, only allowing about 1.7 GB to be used for rendering (and not a byte more, then it crashed instead of swapping!).

The solution we found was to split up allocation of memory in two segments. The Blender UI itself and all rendering geometry is allocated as usual, but all image buffers - for rendering, composite and images used for textures - are allocated using a disk-based "memory map" system. Typically, this memory uses a different address space, allowing to allocate much more. For OSX systems, it meant we could succesfully use up to 2.8 GB that way.

You can monitor memory usage in the Blender window header, which prints the total allocated, and in brackets the part as used for 'memory map'.

Although 64 bits software has the future, it is not expected to be widespread available on everyones desktop soon, so this feature will remain useful for the next few years.

Read the Orange blog posting about this

Floating point color buffers

All buffers in Blender used for storing color or pass values now are floating point, which increases the required memory for buffers fourfold. That's one of the main reasons to use several tiles for rendering, since then only per tile temporal render buffers are allocated.

However, the final Render Result will be allocated in advance completely, unless the option below is used.

Save Buffers

Use this option to disable allocation of the final RenderResult buffers before a render starts. Instead it will save RenderResult tiles to disk using OpenEXR and read back after rendering, after the render geometry was freed, and before a Composite starts. Saving and reading tile-based openEXR takes some extra render time though, for a 2k HD frame about 15 seconds.

Free Tex Images

The second big memory saver was to add a new option to free all Image Textures at the end of each rendering. This option especially became interesting because the creation of Mip Mapping has been speedup enormously (20-30 times faster).

The old implementation for Panorma render was added quite hackish. It used the "X Parts" value to extend an Image size horizontally, and rotating the camera for each X Part.

Now the internal render system has become fully tile-based; enabling the Panorama option will automatically apply the panorama effect on all vertically aligned tiles (slices).

So you can just enable or disable the "Pano" button, to get a subtle lens effect, the output image size will still be same as without Panorama.

For Panorama render, the minimum slice size has been hardcoded to be 8 pixels. The "X Parts" button goes up to 512 to allow that. In practice, rendering 64 slices will already give very good images for a wide angle lens of 90 degrees, the curvature of straight lines then is equal to a circle of 256 points.

Rendering a full 360 degree panorama you do by creating an extreme wide angle camera. The theory says camera-lens 5 should do 360 degrees, but for some reason my tests reveil it's 5.1... there's a rounding error somewhere, or something related to the clipping plane start? We will look at that later. :)

Also note that for each Xpart slice, the entire database needs to be rotated around camera to correct for the panorama effect, on huge scenes that might give some overhead.

Threaded render goes fine for Panorama too, but it can only render the parts within a slice in parallel (the Y-Parts). For the next panorama slice it has to wait for all threads of the current slice to be ready.

On reading old files, the settings from old files are converted to match as closely as possible the new situation.

Currently the code detects for old panorama by checking for the image size. If image width is smaller than height, it assumes it's an old file (only if Panoroma option was set).