Freestyle integration into Blender

June 27, 2010

Weekly update June 7-27

Filed under: Update — The dev team @ 11:42 PM

The last blog post received a number of comments through the blog system and the BA Freestyle thread, which reminded us once more of the increasing interest in a user-friendly graphical user interface (GUI) for Freestyle in Blender.  To start with the design of the new GUI framework, we conducted an in-depth study of existing non-photorealistic (NPR) rendering software packages.  Some of the investigated NPR software packages have well-defined feature sets, providing us with a good deal of insight into GUI design possibilities.  After comparing the features offered, the organization of UI controls, and the ways of user interaction, we drew the initial plan toward the design and implementation of the new Freestyle GUI in Blender.  Basic concepts are as follows:

  • Render layers remain the primary place where Freestyle-related options are stored.
  • Two separate control modes are introduced: One is the Python Scripting mode, a conventional control mode that allows you to directly use style modules written in Python.  The other is a new control mode named the Parameter Editor mode that is intended to be usable by everyone without relying on Python programming.  The new control mode is equipped with a rich set of UI controls built into Blender.
  • Each render layer can choose to use either the Python Scripting or Paramete Editor mode.
  • In the Parameter Editor mode, a render layer has one or more linesets.  A lineset consists of feature edge selection criteria and a line style datablock.
  • Feature edge selection criteria are used to select from a set of all feature edges in the view map only those on which you want to draw strokes.  For instance, you specify a couple of criteria for selecting only visible crease edges.
  • A line style is a set of line stylization parameters that describe the appearance of strokes as well as how feature edges are joined to build the strokes.  Line style is a new datablock type, meaning that a line style can be shared by multiple linesets (possibly of different render layers in different scenes).  Line styles will be manipulated through a number of UI controls such as color ramps for specifying color gradients, curve editors for non-linear line thickness and opacity, and a preview window for seeing the effects of parameter changes in real time.

Branch users may have noticed that some of these elements have already been implemented in the latest revision of the Freestyle branch.  Now the Render buttons have two new tabs: the “Freestyle” tab and “Freestyle: Line Style” tab.  The former has render layer-specific options, while the latter contains UI controls for editing line styles.  The two images below show the new tabs in the Python Scripting mode (left) and Parameter Editor mode (right).

 

The code base is currently in a work-in-progress state.  Most of the new UI elements in the Parameter Editor mode shown above are basically a mock-up, and there is no usefulness for end users.  Much more additions are anticipated in the next weeks.

In the meantime, Maxime has kindly provided a set of slides that explain the internal of the Freestyle renderer in Blender.  The slides would be of great help for those people who are interested in getting involved in the Freestyle integration project.

Advertisements

June 7, 2010

Weekly update May 24-June 6

Filed under: Update — The dev team @ 4:23 PM

In the last two weeks, the dev team made a few fixes and improvements for a better stability of the Freestyle branch.  A possible source of memory leak in WingedEdgeBuilder (part of the initial mesh importer) has been eliminated, while a fatal crash due to materials of the wire type has been fixed.

Now that most entries in the December 2009 edition of the to-do list have been addressed, it is a good time for defining the final targets toward the merge into the trunk.  Here is a list of tasks that we would like to finish before we ask for the merge:

  • An artist-friendly graphical user interface (GUI) with a stylization preview window
  • Feature edge detection at the intersection of two faces
  • Completion of Freestyle Python API improvements

The following items in the previous to-do list will be postponed after the merge into the trunk:

  • Textured strokes
  • Steerable view map

Acknowledging an increasing number of requests for a better GUI, we should definitely consider providing a more intuitive and easy-to-use GUI specifically designed for artist-side users.  A major requirement for the GUI design is to maintain the high programmability of the Freestyle framework.  It is recalled that Freestyle is not only a bunch of predefined parameterized styles, but also a generic tool that allows you to define your own styles based on novel stylization ideas and new parameters.  SVGWriter is an example of many possibilities the extensible nature of Freestyle enables.  Keeping this requirement in mind, we have been considering several options.

  1. As discussed many times since the beginning of the Freestyle integration project, a node-based system would be an ideal GUI that most people could imagine.  However, this approach is too ambitious when the present limited resources (i.e., time and developers) are taken into account.
  2. A more feasible option is to provide a versatile style module equipped with a fixed set of stylization parameters that can emulate common style modules.  Implementing a universal style module of this kind would be a bit tricky, however, because of the present rigid interaction between the Freestyle renderer and a style module.  Basically a style module is just a call back function invoked from within the rendering pipeline, and there is no user interaction mechanism that allows style modules to build their own GUIs, as well as no persistent memory system for saving and loading style-specific parameter settings.  The design and implementation of these subsystems might require nearly the same amount of development costs with the node-based approach.
  3. Another option with a good cost-effectiveness ratio is to provide a fixed set of common stylization parameters through a built-in GUI (as part of the Layers tab in the Render buttons).  This approach can rely on the existing GUI and file I/O components of Blender.  Interactive parameter controls for non-programming users are offered through a “basic” mode, while user-defined style modules written in Python will be accessible through an “expert” mode.

As of this writing, the last option seems the most promising.  We are going to look into all these options in the next weeks.  As an attempt to implement a stylization preview window, we have successfully added strokes into the material preview window as shown below (please note that this is just a test from a technical perspective).

The idea here is to introduce a stylization preview window that shows a simple predefined scene (e.g., just a cube or Suzanne) in line with the material preview window.  More work on this specific GUI element is also anticipated in the following weeks.

Blog at WordPress.com.