From BlenderWiki
Blender Extended Expressive Rendering (BEER) Development Proposal
The Blender Extended Expressive Rendering is a good opportunity to revitalize Blender Internal engine and build ad hoc tools and workflows for Non Photorealistic Rendering (NPR). This document aims at building a proposal suitable both for evaluating development feasibility and as development guideline, by expanding the current draft into a coherent framework.
[WORK IN PROGRESS]
Implementation Challenges
- Fragmentation: each paper and feature request deals with a specific aspect of a NPR style. There is no comprehensive approach to bring all of this work together.
- Flexibility: some of these NPR features/shaders are desirable for styles other than the one they were thought for. Artists should be able to build the desired look by freely mixing these features/shaders.
- Intuitive controls and setup: Non Photorealistic renders and materials can be quite complex. They can involve the compositing of multiple render layers, and materials composed of many shaders processed by color ramps, textures and color mixed in various modes. An alternative User Interface is required for a better workflow.
- Lacking node editor: Some of the features requested are already, or partially, possible with material nodes. The issue with Blender Internal shader node editor is it's little more than a materials mixer, not a shaders builder like Cycles. That’s why using the current nodes is cumbersome to manage and edit.
Development Plan
To address the issues raised above the development is broken down in three stages:
First stage: Node implementation
Implementation of the various NPR features as nodes for Blender Internal material node editor. This has several advantages.
- Completed nodes can be individually committed to trunk as soon as possible.
- Even if development where to halt at some point not everything will be lost.
- By breaking everything in nodes we can tackle one problem at a time, it's easier to test that everything works as expected and different areas can be worked at the same time.
- We can build early prototypes of the new Blender Internal NPR materials by connecting the nodes, start testing use cases and the workflow, and collecting useful information for the next development stage.
- Once this stage is complete we end up with a powerful NPR shader builder.
Second stage: BI materials integration
Once the nodes prototypes are confirmed to work, and cover all production needs, the nodes functionality are integrated into Blender Internal materials, as it was already proposed.
Bonus stage: BEER add-on
A layer or stack user interface can cover the node editor functionality, providing a better UI and workflow. The BEER add-on whould be basically an UI that builds a node tree in the background, by connecting predefined node groups, and shows you only the relevant controls. If you where to look at the node editor you would see a common node tree built by the add-on.
While BEER aim is to allow wide range of NPR stylization (cartoon, watercolor, hatching, etc.), the focus is on three stylization:
X-Toon
Common toon shading uses a 1D texture (i.e. a color ramp) that describes how the tone of the surface varies relative to incoming light. X-Toon replaces this 1D texture with a 2D texture, where the second dimension adds an additional tone behavior, other than the incoming light one. This supports effects such as levels-of-detail, aerial perspective, depth-of-field, backlighting, and specular highlights, depending on what input you use in the in the additional axis.
The horizontal axis (labelled S for shading) corresponds to tone as in a classic 1D toon texture, the texture coordinate along that axis is derived from a standard diffuse shading computation. The vertical axis (labelled D for detail) corresponds to tone detail: each value along this axis corresponds to its own 1D toon texture. The whole 2D texture can thus be regarded as a stack of 1D toon textures with increasing “detail.”
Once a 2D texture is created, the designer must choose an attribute (e.g., orientation or depth) that will control the tone detail, and provide functions called attribute maps that map the attribute to a detail value D at each location on a surface. This formulation is general in that any attribute can be chosen, depending on the application goals.
In other words X-Toon is a two dimensional color ramp, controlled by two factor values: one is the shading relative to the incoming light, the other is a user chosen attribute (usually a view dependent one).
Soft-Toon
Cel-Toon
Node Implementation
X-Toon
X-Toon versatility comes from the several attribute map functions. Dividing the 2D texture sampling from the attribute functions, we leave room to further expansions of this tecnique, with new attribute functions, and freedom to the user of building its own attribute functions.
2D Color Ramp
Inputs
- Texture: Texture menu.
- Fac1: Float with expected value in the [0, 1] range. Any value outside the endpoints is clamped to 0 or 1. Default value is 0.5.
- Fac2: Float with expected value in the [0, 1] range. Any value outside the endpoints is clamped to 0 or 1. Default value is 0.5.
Outputs
- Color: Sampled color at (Fac1, Fac2) texture coordinates.
- Alpha: Sampled alpha at (Fac1, Fac2) texture coordinates, if there is an alpha channel, otherwise its value is 1.
The texture can be of any type. If it's an image texture, whatever its form factor is, the horizontal length is mapped from 0 (left margin) to 1 (right margin), the vertical length is mapped from 0 (bottom margin) to 1 (top margin). For other types of texture we map the texture preview. This allow us to build X-Toon textures using the texture nodes editor (see picture below).
