Freestyle integration into Blender

March 30, 2009

Weekly update March 23-29

Filed under: Update — The dev team @ 3:55 AM

This week we made further improvements on error handling in the Python API implementation. Writing and testing style modules should be much easier. Untrapped errors in the Python layer (i.e. those errors that are not properly handled by the toplevel error handler of the Python interpreter) are very likely to cause a crash when you quit Blender. Please let us know if you observe crashes of this kind.

Freestyle renders of the week presented below are contributions from Ronin (Rylan Wright).  He is one of the most active early adapters of Freestyle for Blender.  His feedback in the form of artwork is very valuable and encourageous.  Thanks Ronin for sharing the nice results!



March 25, 2009


Filed under: Other — The dev team @ 6:46 PM

I added the Milestones page to the blog, originally posted on the BA thread. This will give you an idea of what we are currently working on and by when certain features should be implemented. We tried to give you conservative estimates on the dates.  We will update the page with our progress.

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 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.


March 15, 2009

Weekly update March 9-15

Filed under: Update — The dev team @ 7:29 PM

In the period of March 9 through 15, several updates were made to the code base.  Efforts were mainly directed to consolidation of the Python API and several bugs that led to immediate crashes were fixed.  The execution of style modules is now more stable than the previous revisions.  Also the StrokeVertex::setPoint() method has been fixed, which enables some shaders (including pySinusDisplacementShader in the shaders module) that rely on the method.  The image below is a test render using pySinusDisplacementShader.


This week we have another render to present here, contributed by Naoki-san, a member of  The original model of a water wheel is shown in the upper right of the image, and the results of two style modules, and, are shown in a composited form and also in strokes only.  The colored results look like illustrations in a fairytale book.  Thanks Naoki-san for sharing the nice results.


March 8, 2009

Weekly update March 2-8

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

As announced in the BA thread, more regular weekly updates are anticipated in this blog.  We hope to keep you posted even when there is little or no progress in the development of the branch.   OK, let us get started — here’s the first weekly update in the period of March 2 through 8.  There were two improvements in the code base during this period.

  • An issue regarding render layers was fixed.  Now the Freestyle renderer builds a view map based on selected object layers in a render layer, instead of the global selection of object layers.  This allows, for example, to have two render layers, one for rendering solid faces of objects in all object layers, and the other for rendering outlines of objects in selected object layers by Freestyle.  At the moment, the number of Freestyle-enabled render layers is restricted to one — a better fix is in the future work.
  • An immediate crash due to execution failure of a style module was fixed.  Blender will keep running regardless of a syntax or runtime error during the execution of a style module.  This will ease the burden of debugging the style module when some errors are expected.  You have to be aware of error messages to be printed in the console.

As part of the weekly updates some test renders by branch users will also be presented.  The following image is a test render using that comes with Freestyle.  The style module was slightly modified so as to get thin strokes and material-based stroke color.

flores (thumbnail)
(Click the image to enlarge.)

Create a free website or blog at