利用者:Mx/Freestyle status report Summer 2009

Freestyle Summer 2009 Report

Freestyle will soon be included in Blender 2.5. The merge is an opportunity to document the state of the branch, listing a summary of the main commits since the GSoC 2008, its current limitations and the modifications needed before it can be released in the wild.

Before diving into all of these details, it is important to clear some of the confusion around it. Freestyle is a "non-photorealistic line rendering framework". It is important to understand that is is a framework, NOT a closed set of line rendering styles. It defines a pipeline with operations that work on an array of geometric information, allowing the definition of an infinite amount of styles. This implies that end-users should not just focus on the sample styles provided by the branch, but learn to understand how they are implemented.

The framework could be used in different ways by different users:

• developers could extend it, incorporating new line geometric features or improving the speed of computation.
• technical artists could define new style modules, using the same skills as shader writers.
• artists could define the module parameters that are useful for style experimentation

Freestyle aims to satisfy these three groups of users.

State of the Branch

Past improvements

Since last year, many improvements have been made:

• style module configurations can be saved to file
• the pipeline is fully controllable at the render layer level
• stroke rendering is native (using the internal renderer)
• the API has been significantly improved for ease of use
• the program is much more stable, robust and with a lower memory footprint
• it supports more of the original style modules

Upcoming features

A significant amount of work is needed to consider the engine production ready:

• the API has not stabilized yet. We are continuing to find ways to make it simpler for artists, by transforming the syntax into something in line with traditional Python idioms. Style modules have to be ported to the new API continuously.
• many of the originally supported geometric features (depth, stroke density, steerable view map, textured and transparent strokes...) are not available. We do not want to release Freestyle until these features are ported.

Blender 2.5 will only support Python 3.1. We do not think it will impact Freestyle that much though, as there is practically no Python code in the engine:

• Freestyle is made available through the Python/C API
• style modules depend mainly on the Freestyle API. Python 3.1 will not change any of it so we don't expect any interference.

Bugs

Many of the program's current bugs are listed on the FAQ page.

For the 2.5 release, we will only focus on stability bugs. We cannot afford any form of crash to be created by the pipeline.

Possible improvements

• Style modules should be defined via the script editor. This would allow modules to be packaged with files, to be configurable at run-time and would open the door for customization at the compositor level.

• The current implementation matches the toon-edge functionality, depending on the 'Freestyle' button to be toggled on. There is however no real need for it and the button could be easily removed.

• Users would want style modules to live in their own directory, for quicker access.

• Freestyle is the original name of the NPR software. The merge into the 2.5 branch is an opportunity to rename it 'correctly' in the UI, possibly 'line edge rendering' or 'line strokes'. If you think of a better name, please let us know.

• The current pipeline still matches the one from the original authors. One severe drawback is that geometry has to be imported into a specific format for the line features to be calculated. In particular for animations, the geometry is imported at every frame. One solution would be to determine when the reload is necessary, but it would still waste computing resources. A better approach would be to transform all of the line feature computation to Blender's native geometric format: that way, no more conversion and native computation. The same remark applies to having Freestyle's engine utilize already computed render passes (for example, depth and normal information).

• The current view map computation is still prone to errors and is tied to a few constants that affect line features in certain situations. We want to gradually improve the robustness of these calculations. The goal of the branch is to provide top-quality stylizable line features. For large scenes, the view map calculation puts a severe strain on performance. We need to devise ways to speed things up (parallel computation seems like a viable solution).

• As outlined above, a greater challenge is integrating the view map and style modules in the compositor, empowering artists with editable style module parameters. Representing these style modules via a PyNode seems like the best solution. That said, we have not thought much of the difficulty to implement the feature and whether it would go well with end-users.

Internals

We have started documenting how Freestyle is organized as a rendering engine and how it is integrated into Blender. The Internals Overview page lists some information useful to developers. It is only a start; we expect to add more detail in the weeks to come.

Questions

 

Will the parameter editor be made an integral part of the release ?

The parameter editor is useful for artists who want to experiment with specific styles, modifying the parameters for a particular job at hand. Even though it is great for experimentation, it is a temporary solution. Its main drawback is that it sets style parameters globally, meaning that if two layers use a same style module, both layers will end up using the parameters values.

It would be better to tweak these values directly in the compositor: the view-map wouldn't have to be regenerated as style parameters change and many instances of a same style module could be used with different choices of parameters.

A possible solution would be to represent a style module with a PyNode. The current pipeline does not allow it yet, but it seems like the best solution for artists.

Why can't style modules be directly chosen from a list ?

As was explained before, presenting a list of predefined style modules does not make much sense as it would restrict users with a closed set of modules.

We understand that manipulating Python scripts might not be the best solution for non-tech-savvy artists. Perhaps a generalist style module customizable via the Freestyle panel could be integrated. We are currently thinking about the most balanced solution.

Do you plan to add a style module preview render window ?

A style module preview similar to the one used for materials would be a great addition. That said, we have not yet defined a style module interface and do not know how style module parameters should present themselves to users in the UI. This problem is closely related to the challenge of exposing parameters in the compositor. Both problems will be dealt simultaneously.

Will Freestyle be fully usable for animation ?

Most of Freestyle feature lines (silhouette, QI...) are temporally-coherent so they can be used in animation as-is. The jittering might come from the definition of a particular style. For example, style modules that depend on randomized shaders should not be used in animation.

The immediate goal is to finish integrating Freestyle into Blender, for the first 2.5 release. When this is done, we can try to work on animation-related features. There many NPR algorithms from research that specifically deal with these issues.

Can mesh intersection lines (between two meshes or within a mesh) be stylized (as is currently possible with Blender's current toon-edge) ?

This is not a currently planned feature. We would have to research it before integrating it (it might severely impact the view map computation time).

Will users be allowed to manually define features lines on meshes ?

This is an original feature planned in the GSoC proposal, that will be dealt with in future revisions. This is however not a priority for the first revision, that focuses on API stability, robustness and efficiency.

Will Freestyle replace the current edge features ?

We hope to eventually replace the current edge functionality. The current toon-edges are computed in tiles independently, using the depth buffer. If Freestyle is able to completely recreate the same line features, we will recommend removing the previous implementation. The final decision rests with Blender core developers.