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