Freestyle integration into Blender

March 23, 2009

Weekly update March 16-22

Filed under: Update — The dev team @ 2:03 AM

Last December, in order to integrate with Blender’s rendering pipeline, Freestyle had been modified to work as a tile-based process. Unfortunately, this prevented the use of the color buffer and depth buffer in style modules. This week, Freestyle became a post-processing effect again ! There are simple reasons for returning to the “old way”. Freestyle is inherently a global-level image process: contrary to Blender’s traditional edge renderer, Freestyle cannot determine strokes’ attributes in a single tile; the view-map, calculated on the whole image, is needed to calculate them. We will reintegrate the color buffer (“Combined” render pass) and the depth buffer (“Z” render pass) in the weeks to come. In the process, Freestyle’s stability was improved a bit. Freestyle now works in “Single” render layer mode too. Maybe this will fix some crashes when compositor nodes are used.

Moreover, further stabilization was carried out in the Python API implementation.  The underlying C++ API was modified as well in order to allow for proper error propagation between the Python and C++ layers.  Before these changes were made, the C++ layer had many API functions and class methods that were not able to inform error states to their callers.  This C++ API design made it difficult to propagate errors from the Python layer through the C++ layer up to the toplevel error handler in the Python interpreter.  Although some error messages could be printed to the console, the errors were generally not handled properly by the toplevel error handler, undermining the Python API stability.  Now that the C++ API has been revised, error handling at the Python-C++ boundaries is much better, and exceptions in user-defined predicates and functions in Python will be properly cought and reported to the user together with a traceback.

The changes made to the Python API are negligible in fact, while those in the C++ API require some attention from those users who are interested in extending Freestyle with C++.  Before the changes were made to the C++ API, the operator() methods of predicates and functions, for example, returned a value of various types such as bool, double and Vec2f.  These returned values were not capable to represent an error state in many cases.  Now the operator() methods always return 0 on normal exit and -1 on error.  The original returned values are stored in the “result” member variables of the predicate/function classes.  This means that if we have a code fragment like below:

UnaryPredicate1D& pred;
Interface1D& inter;
if (pred(inter)) {
  /* do something */
}

then we have to rewrite it as follows:

UnaryPredicate1D& pred;
Interface1D& inter;
if (pred(inter) < 0)
  return -1; /* an error in pred() is propagated */
if (pred.result) {
  /* do something */
}

Here pred() is either a built-in predicate in C++/Python or a user-defined predicate in Python; the latter is likely error-prone, especially when debugging it.  The first code fragment shown above prevents the proper error propagation because the boolean return value of UnaryPredicate1D::operator() cannot inform the occurrence of an error to the caller; the second code fragment can.  In addition to the operator() methods of predicates and functions, similar modifications have been made to all other C++ API functions and class methods that are involved in the execution of user-defined Python code snippets.  See the commit log of revision 19342 for a detailed list of modified functions and methods.

OK, let us move on to a test render of the week.  In the image presented below, the strokes were made by a slightly modified qi0.py to get material-based stroke colors using pyMaterialColorShader.  The motif and the entire color coordination were borrowed from “Lily” of the Flores series by Alfons Mucha, whose Art Nouveau style is characterized by strong strokes such as thick external contours.  His artwork poses a number of interesting NPR issues that would be worth addressing in Freestyle.

lily_tn

1 Comment »

  1. sounds like the move back to a post-processing effect is the way to go for now. determining stroke attributes from a single tile definitely seems like a limitation to freestyle. Good call IMO.

    The test render looks nice too. Those tasty freestyle lines, mmmm

    Comment by 3D — March 23, 2009 @ 3:25 AM


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: