Updates in the Parameter Editor mode

The function of the ‘+’ button to the right of a line style name in the Freestyle: Line Style tab has been changed so as to make a copy of the active line style instead of creating a new line style with default settings.  This is meant to be consistent with the creation of new data blocks in other parts of Blender (for instance, creating a new material will result in a copy of the active material).  Also a button to make a single-user copy of a line style (i.e., the button that indicates the number of users) has been implemented.

Copy and paste operations for line sets have been added to make it easy to duplicate the settings of a line set.

It is recalled that line sets have a reference to a line style.  When the settings of a line set A having a reference to a line style X is pasted into a line set B, the latter line set will have a reference to X.  That is, the paste operation changes the line style references, but does not modify the settings of line styles.  If you also want a copy of the referenced line style after the paste operation, you have to make it using the copy operation for line styles as described above.

An extended set of conditions for feature edge selection by edge types has been introduced.  Each edge type check button in the Selection by Edge Types has now an associated toggle button to exclude the edge type from the feature edge selection.  This allows you to select, for instance, those edges that are silhouette lines but not external contours by enabling the two edge types and also the toggle button for external contours, as shown in the screen shot below.

A new option for disabling the chaining of feature edges has been added to the ‘Stroke’ panel of the Freestyle: Line Style tab.  This option is useful for examining the initial set of feature edges in the view map.

New options for splitting chains of feature edges by a minimum and maximum 2D angle and by a 2D length limit have been added to the ‘Stroke’ panel of the Freestyle: Line Style tab.  These options are useful for splitting long strokes into small pieces.  See the example renders of the Guiding Lines geometry modifier below for an example use of splitting by 2D length.

Three new stroke geometry modifiers have been implemented.

• Polygonization
• Guiding Lines
• Blueprint

The Polygonization geometry modifier transforms smooth strokes into jagged polylines.  The “error” parameter specifies how much deviation is allowed from the original stroke geometry (the larger the error parameter is, the more jagged the resulting polylines are).  The following test renders illustrate the effect of the Polygonization modifier: (a) without applying the modifier, strokes along arcs are smooth; (b) with the polygonization modifier applied with the error parameter set to 5, the strokes are transformed into jagged polylines; and (c) the error parameter set to 20 gives more jagged polylines.

The Guiding Lines geometry modifier replaces a stroke with a straight line connecting both ends of the stroke.  This modifier will produce reasonable results when strokes are short enough, because shorter strokes are more likely to be well approximated by straight lines.  Therefore, it is recommended to use this modifier together with the splitting options (by 2D angle or by 2D length) mentioned above.  The following images show how splitting and geometry modifiers can be combined: (a) smooth strokes along arcs are split into small pieces by the 2D Length option; (b) the Guiding Lines gemoetry modifier is then applied to approximate the split stroke segments by straight lines; and (c) the Backbone Stretch geometry modifier is further applied to extend both ends of each straight stroke.

The render below is a combination of the Guiding Lines and Spatial Noise geometry modifiers.  Both modifiers were applied to two identical line sets to duplicate the guiding lines.  The line sets contain only external contours.  The Spatial Noise modifier was applied before the Guiding Lines modifier, so that two sets of guiding lines display some variability.

The Blueprint geometry modifier produces a blueprint using circular, elliptic, and square contour strokes.  A blueprint here refers to those lines drawn in the beginning of free-hand drawing to capture the silhouette of objects with a simple shape such as circles, ellipses and squares, as illustrated below.

The Perlin Noise 1D geometry modifier had an issue that noise frequency was relative to the stroke length (i.e., the number of noise displacement values was the same for strokes of different lengths).  This resulted in very noisy short strokes and much less noisy long strokes.  Now the noise frequency is relative to the distance from the starting point of a stroke.  That is, two strokes of the same length will be distorted by the same number of noise displacement values, whereas longer strokes will have more noise displacement values along stroke.

Stability improvements

• A fix was made to address duplicated feature edges due to a numerical instability of line clipping by near/far Z planes.
• View map construction was not properly taking face marks into account.  This caused incorrect (and unpredictable) feature edge selection results when face marks were used.
• A crash caused by temporary scenes for stroke rendering was fixed.  Freestyle generates a temporary scene containing a number of stroke meshes to achieve stroke rendering using the Blender internal renderer.  This temporary scene may appear in the outliner and undergo user interaction when the stroke rendering takes a long time.  The crash was due to the deletion of the scene without taking care of references to the scene from screens, one of which was the outliner.
• The interaction between Blender and Freestyle was revised to address a crash when two scenes in the compositor have different render resolution (i.e., image width and height, scaled by a percent parameter).
• Stroke rendering instability with stroke geometry shaders was addressed.  Stroke::Resample(int nPoints) was not properly working when a wrong value was returned from Stroke::getLength2D(), resulting in repeated warning messages “Warning: incorrect points number” during stroke rendering.  The main cause was that stroke geometry shaders did not update the two-dimensional (2D) length (also referred to as curvilinear abscissa) after they modified the 2D points of stroke vertices.  Now all stroke geometry shaders make explicit calls for Stroke::UpdateLength() that has been introduced for recomputing the 2D length.
• A bug in Operators.recursiveSplit() that splitting could not take place within the last segment of a chain was fixed.

Remarks on the merge into the trunk

The dev team has been receiving an increasing number of questions from branch users concerning the merge into the trunk (i.e., official release of Blender).  It is remarked that the merge has already been agreed with the core Blender developers of the trunk, and the only major question is when the merge is done.

In June 2010, the dev team defined a list of unfinished components that need to be done before the merge is finally asked.  The list includes three major components: (a) GUI for the Parameter Editor mode; (b) feature edge detection at the intersection of two faces; and (c) Freestyle Python API improvements.  Subjective achievement rates of the three components are 90%, 0%, and 80%, respectively.  In other words, the Freestyle branch needs more development before it gets ready for code review that is required for the merge to happen.

At the moment the official release of Blender 2.62 is planned in February 2012, but it is unlikely that Freestyle is included into this release because of the short deadline for code review in January.

Considering an admittedly limited amount of time resources, it is still difficult to predict when all the unfinished components are done and the code review for the merge can be asked.  We appreciate the understanding and patience of branch users.

Stability improvements with the face smoothness option

Several branch users kindly reported that Freestyle failed when the Face Smoothness option was enabled and object materials were used to determine line colors.  When the Face Smoothness option is enabled, the view map computed from a given 3D scene is populated by not only sharp FEdges (i.e., edges in the original meshes) but also smooth FEdges (i.e., newly constructed edges across faces).  This situation often resulted in a failure of the getFEdge() method (defined in the Interface0D class and its subclasses) used to obtain the FEdge between two given 0D elements (such as SVertices and CurvePoints).  The instability of getFEdge() caused many related issues because the method is widely used in other predicates and functions that rely on it.  The most prominent example of related user-visible problems is a failure of the built-in MaterialF0D class that retrieves object materials of given 0D elements, as seen in the problem reports from branch users.

The persistent failure of getFEdge() was resulting from several bugs in the view map construction algorithm.  These bugs were fixed through careful code revisions and intensive testing.  Also, the built-in MaterialF0D turned out to be incapable of handling Curve objects (such as chains and strokes), so that a new CurveMaterialF0D class has been introduced to address the material retrieval in the case of Curve objects.

These changes have improved the stability of the renderer with the Face Smoothness enabled.  The dev team is very grateful to those branch users who provided the bug reports together with .blend files to reproduce the issues.  The .blend files were indeed indispensable test cases during the bug hunting.

Fine control of feature edge selection with mesh face and edge marks

With the aim of allowing for fine control of feature edge selection, new “face marks” and “edge marks” have been introduced in mesh data blocks.  In the edit mode of a mesh object, face marks can be put to selected faces by choosing Mesh > Faces > Mark Freestyle Face from the menu of a 3D View window or Ctrl-F > Mark Freestyle Face from the context menu.  Similarly, edge marks can be put to selected edges by Mesh > Edges > Mark Freestyle Edge or Ctrl-E > Mark Freestyle Edge.  These marks should work fine with the Subdivision Surface and Mirror modifiers.

Moreover, two new conditions for feature edge selection have been added to the Parameter Editor mode, as described below:

1. The Selection by Edge Types option now includes the new Edge Mark type, which can be used to (de)select feature edges having edge marks.  This option can be used to add to (or remove from) the view map arbitrary edges of mesh objects.
2. Selection by Face Marks option has been newly introduced, in which face marks are used for feature edge selection in two ways.  One option is called “One Face” which is to (de)select feature edges if one of faces on the left and right of each feature edge has a face mark.  The other option is “Both Faces” to (de)select feature edges if both faces on the left and right have a face mark.  Those feature edges that meet the conditions are selected if the Inclusive option is enabled; they are deselected if the Exclusive option is turned on.

The following screenshot shows the new GUI controls (highlighted in red) based on face and edge marks.

Edge marks are useful when you want to draw lines along particular mesh edges.  The following example images demonstrate the use of edge marks.

The image on the left shows a sphere mesh with edge marks (in the edit mode).  In a 3D View window, edge marks are displayed in light green.  The image on the right is a render without the Edge Mark type enabled in the Selection by Edge Types option (the black line shows the silhouette of the sphere).  The image below is a rendering result with the Edge Mark type enabled.  The blue lines indicate those resulting from mesh edges with edge marks.

Face marks are useful for removing lines from certain portions of mesh surfaces.  Suppose that two faces of the default cube have face marks as shown in the image on the left below.  Marked faces are displayed in light green.  The image on the right is a rendering result without using the Selection by Face Marks option.

The following images show how rendering results vary with four combinations of the Inclusive/Exclusive and One Face/Both Faces toggle options.  Notice that only the edge between the two marked faces is (de)selected when the Both Faces option is used, while all the edges touching the marked faces are (de)selected when the One Face option is enabled.

Renders from branch users

In the meantime, branch users have been sharing their renders made with Blender and Freestyle.  Here are some selected rendering results.

Toon rendering of Sintel by jikz (the model is base on Sintel Lite 2.57b by BenDansie):

Architectural line drawing by flokkievids:

Many thanks to jikz and flokkievids for the excellent contributions!

Enhancement of the Parameter Editor mode

New line style controls have been added to the Parameter Editor mode that is intended to be an artist-friendly GUI for manipulating line styles without any user efforts on Python scripting.  Recent major additions and changes are described as follows.

• A new line style option for sketchy chaining of feature edges has been added.  The conventional default chaining method is now called Plain, while the new chaining option is called Sketchy.  The latter option allows for generating chains of feature edges with sketchy multiple strokes.  Both Plain and Sketchy chaining options have the Same Object toggle button in common, whereas the Sketchy option has an additional option called Rounds.  With the Same Object option enabled, only feature edges of the same object are chained.  The Rounds option specifies the number of rounds in sketchy strokes.  The following render shows a visual effect of sketchy chaining (3 rounds, with the Spatial Noise geometry modifier specified to enhance the sketchy appearance of strokes).

• A calligraphic thickness modifier has been implemented.  This modifier gives strokes variable thickness that looks as if they are drawn with a broad and flat pen for calligraphy.  The following test render illustrates a typical effect of calligraphic thickness.

• A new parameter called Angle has been added to the Perlin Noise 1D and 2D geometry modifiers to specify a displacement direction in degrees (zero degree indicates the positive X direction).  The following images demonstrate how the Angle parameter makes a difference in rendering results (left: the Angle parameter set to 45 degrees; right: 135 degrees).

• The behavior of the Perlin Noise 1D geometry modifier has been changed so that it works differently from the Perlin Noise 2D geometry modifier.  Now the Perlin Noise 1D modifier distorts strokes using the curvilinear abscissa of stroke vertices as the input of the Perlin noise generator.  It is remarked that curvilinear abscissa is a scalar value between 0 and 1.  The first and last vertices of a stroke have the values 0 and 1, respectively, and the values for other stroke vertices are linearly interpolated over the stroke.  Therefore, the Perlin Noise 1D modifier gives identical noise displacements to strokes if the strokes have the same length and sampling interval (the latter is specified by the Sampling geometry modifier).  In contrast, the Perlin Noise 2D modifier generates noisy displacements using 2D coordinates of stroke vertices as the input of the noise generator.  Therefore, strokes in different positions in a render will be distorted with different displacements by the Perlin 2D noise generator even if the strokes have the same length and sampling interval.  The differences between the Perlin Noise 1D and 2D modifiers are illustrated in the following test renders.  The image on the left shows a set of vertical lines and another set of star-shaped strokes, both distorted by the Perlin Noise 1D modifier.  Strokes in each set of lines have identical noisy displacements, because of the same stroke length and sampling interval.  The image on the right shows a render of the same scene with the Perlin Noise 2D modifier, which gives different displacements to each of the strokes because of their 2D positions in the image that are different from each other.

• New line style options for selecting chains by min/max 2D lengths have been added.  Using these options you can select strokes that are longer and/or shorter than specified stroke lengths.

Link and Append

A proper support for the Link and Append commands has been implemented.  Now you can link/append line styles as well as scenes with line styles from within other .blend files.

Stability improvements and bug fixes

An attempt to fix the long-standing issue of occasional infinite straight lines has been made.  The fix is still not the best solution, but seems to yield much better results as illustrated in the following test renders (left: examples of unwanted infinite lines due to the bug; right: infinite lines no longer appear after the bug fix).

Since the solution looks quite effective, a temporary workaround (implemented by means of a custom chaining rule) for infinite straight lines was removed.  This change has resulted in much cleaner strokes.  If you have suffered from a lot of segmented strokes that are supposed to be a single straightforward stroke, then using the latest Freestyle branch would be a solution for the issue.

In addition, several other bug fixes have been made to improve the general stability of the Freestyle renderer.  Most of the bugs were reported by branch users, some with example .blend files for reproducing the problems.  These reports were really invaluable, and we appreciate the feedback from the branch users.

Concluding remarks

That is all for now.  More additions to the Parameter Editor mode as well as further development work on other priority tasks (i.e., unfinished components that must be completed before the merge into the trunk is asked) are anticipated in the next weeks.

Stroke geometry modifiers

A new set of line style options for modifying stroke geometry was introduced in the Parameter Editor mode.  Stroke geometry refers to the backbone polyline of a stroke.  Now stroke geometry can be modified by a list of stroke geometry modifiers specified in the Geometry tab (previously referred to as Distort).  At the moment the following geometry modifiers are available, each with a set of animateable parameters:

• Sampling: Changes the resolution of stroke backbone polylines.
• Bezier Curve: Replace stroke backbone with a Bezier approximation of the stroke backbone.
• Sinus Displacement: Add sinus displacement to stroke backbone.
• Spatial Noise: Add spatial noise to stroke backbone.
• Perlin Noise 1D: Add one-dimensional Perlin noise to stroke backbone.
• Perlin Noise 2D: Add two-dimensional Perlin noise to stroke backbone.
• Backbone Stretcher: Stretch the beginning and the end of stroke backbone.
• Tip Remover: Remove a piece of stroke at the beginning and the end of stroke backbone.

Note to branch users: When you have a .blend file with Freestyle options specified, you need to add a Sampling modifier with the Sampling parameter value set to 5, which is the default polyline resolution previously used for line drawing in Freestyle.  Before geometry modifiers were introduced, this initial sampling was automatically done.  Now the initial sampling is a tunable parameter that can be omitted, allowing better control on polyline resolution.  If no sampling modifier is specified, your line drawing will result in coarse polylines.

Images below are a few example renders made with the following stroke geometry modifiers used: (a) no geometry modifiers, showing baseline stroke backbones; (b) Bezier Curve modifier; (c) Sinus Displacement modifier; (d) Backbone Stretcher and Spatial Noise modifiers.

Fill Range by Selection

A new push button Fill Range by Selection was added to the Distance from Camera and Distance from Object modifiers (see figures below).  This button allows you to automatically fill the Range Min and Max entries based on selected mesh objects.  For the Distance from Camera modifier, the Range Min (Max) entry is filled with the minimum (maximum) distance between the active camera and the vertices of selected mesh objects.  For the Distance from Object modifier, the distance between the target object and the mesh vertices is measured.

Stroke splitting at material boundary

A new toggle button for splitting strokes at material boundary was added to the Strokes tab.  This option divides strokes into pieces at material boundary.  The following renders illustrate the effect of the splitting option: (a) disabling the option results in a smooth (blurred) transition of stroke colors across material boundary; (b) enabling the option permits a flat color transition at material boundary.

In addition, the Parameter Editor mode of the Freestyle graphical user interface was enhanced with new Material modifiers that allow you to change the line color, alpha transparency, and line thickness of strokes by object materials.  The screenshot below shows the GUI controls of the Material color modifier.

The following set of rendering results demonstrates a typical use the Material color modifier: (a) the stroke color is constant (i.e., the base color is black); (b) the Material color modifier is applied and the base color is replaced by the the diffuse color of object materials (i.e., blend = Mix, influence = 1.0); (c) same as (b) but the diffuse color of object materials is blended into the base color (blend = Add and influence = 0.4).

Artwork with Freestyle for Blender

In the meantime, several branch users released excellent animation shorts and movie clips made partly with Freestyle.  First, Chris Burton and his colleagues released a finished animation short “The Light at the End“.  This is one of the most impressive pieces of artwork that give you a real sense of how line drawing with Freestyle looks like.

Dolf Veenvliet (macouno) has been using Freestyle for his Entoforms project.  Entoforms are little creatures generated by a program that “grows” them through a kind of DNA strings.  The use of Freestyle is meant to give a “drawn” look to 3D renders according to one of project blog posts.

And last but not least, Ike AhLoe released a finished animation short “Clocked In“.  During the production of this artwork, he contributed to the Freestyle integration project through a number of bug reports and development updates.

We are very grateful for the authors of these art products, since the early adoption of the Freestyle renderer should have been tough and time-consuming due to bugs and limitations.  We hope these frontier examples encourage further use of Freestyle in future 3D art projects.

Technical overview of the optimization

Now let us describe Alex’s optimization work from a technical perspective.  The performance improvements have been mainly done in two major components of the view map construction: silhouette edge detection, and edge visibility calculation.

Silhouette edge detection is to find feature edges of interest that constitute a basis of line drawing in Freestyle.  To optimize this data processing for speed, Alex made careful changes to the code base so as to exploit compilers’ optimization capability.  This modification leads to a shorter rendering time independently of the spatial structure of a given scene.

The detected feature edges then undergo the edge visibility calculation where an integer value expressing quantitative visibility is assigned to each feature edge.  The edge visibility is determined by a raycasting algorithm with the help of a spatial grid structure that allows efficient traversal of faces in the 3D space (i.e., tris and quads) from the view point of a camera.  As a matter of fact, the non-optimized old view map code relied on a grid data structure that was implemented with the assumption that the faces were evenly distributed within the 3D bounding box.  In addition, the old code was internally creating a list of occluders by copying polygons again and again, which slowed down the view map construction.  Alex devised new grid data structures (SphericalGrid for perspective cameras and BoxGrid for orthographic cameras; automatically switched based on the camera types) that do not assume the ideal even distribution of polygons, as well as a heuristic grid density calculation algorithm that enables an adaptive population of the grid structures with polygons.  Moreover, an iterator is employed for obtaining the occluders on demand instead of making a local copy of them.

Based on these internal improvements, two optimized edge visibility calculation algorithms have been added: a “traditional” algorithm for emulating old visibility algorithms, and a “cumulative” algorithm for improved, more consistent line visibility.  Both algorithms exploit the new spatial grid data structures for fast raycasting.  Each optimized algorithm comes with two variations: culled and unculled.  The culled visibility algorithms exclude most of the feature edges outside the image boundary.  This will result in much faster visibility calculation at the cost of possible alterations to the results of edge chaining.  The unculled algorithms take all feature edges into account.  The latter is useful when off-image edges matter for chaining.

New rendering options

A new option “Raycasting Algorithm” has been added to the Freestyle tab to allow users to choose a raycasting algorithm.  Available choices are:

• Normal Ray Casting
• Fast Ray Casting
• Very Fast Ray Casting
• Culled Traditional Visibility Detection
• Unculled Traditional Visibility Detection
• Culled Cumulative Visibility Detection
• Unculled Cumulative Visibility Detection

The first three algorithms are those available in the original Freestyle (the “normal” raycasting was used unconditionally, though).  The “fast” and “very fast” raycasting algorithms achieve a faster calculation at the cost of less visibility accuracy.  The other four are newly introduced optimized options.  The visibility accuracy of the “traditional” algorithms are the same with the “normal” algorithm, while that of the “cumulative” algorithms is supposed to be the same with or better than the “normal” case.  Performance improvements over the old algorithms depend on the scenes to be rendered.  The recommended options for branch users are the culled/unculled cumulative visibility algorithms.  These two options are intended to replace the other algorithms in the future.

Performance results

To conclude this brief introduction of Alex’s wonderful optimization work, some performance results are shown below using four test scenes.  In all cases, the non-optimized ”normal” visibility algorithm in revision 35506 was compared with the culled cumulative visibility algorithm.

Ichiotsu (orthographic)

73448 vertices, 72260 faces, orthographic camera.

Ichiotsu (perspective)

73448 vertices, 72260 faces, perspective camera.

Lily

64011 vertices, 60346 faces, perspective camera.

A scene by Greg Sandor (from Lighting Challenge #15: Film Noir)

109180 vertices, 189191 faces, perspective camera.

The first two examples indicate that the new grid data structures for perspective and orthographic cameras have comparable performance.  The third test showed a huge performance gain in silhouette edge detection.  The last big scene resulted in an incredible speedup rate in the view map building phase.  Remarkably, these amazing performance results are solely by means of Alex’s optimization work.  Again, thank you Alex!  This is really great!

Branch users are encouraged to test the new raycasting algorithms from both performance and artistic perspectives.  Performance reports and rendering results are highly welcome, possibly through the Freestyle thread in BlenderArtists.org.

1. Fixes for unexpected long straight lines

First, the issue of occasional unexpected long straight lines has been partially addressed.  Branch users may encounter this issue when a number of frames for animation is rendered.  A typical situation is that a few frames (e.g., one or two out of a hundred frames) suffer from weird long straight lines that are not in the scene data.  An example of such a long straight line is shown in the image below.  This problem is mostly due to a known bug in stroke mesh generation.  The bug is that quick U-turns in stroke topology are not handled properly.  A fix for this bug is planned as part of a comprehensive improvement of stroke mesh generation described in a blog post in last September.  As a quick remedy for now, the Parameter Editor mode has been extended so as to prevent strokes from doing quick U-turns.

Branch users writing custom style modules may be interested in the way how the fix is implemented.  Take a look at AngleLargerThanBP1D() in scripts/freestyle/style_modules/parameter_editor.py.  This predicate is used with ChainPredicateIterator() to allow two consecutive edges to be chained only when the angle of the two edges is larger than a given threshold.

In the meantime, another issue was identified as a source of unexpected long straight lines.  This issue arose when stroke thickness was specified by a curve mapping of a thickness modifier in the Parameter Editor mode.  In some occasions the curve mapping resulted in extrapolation, which gave an extremely large thickness value.  Now the extrapolation option is unconditionally disabled to prevent this issue, even when users turn on the option through the GUI.

2. Consolidation of stroke drawing

Second, consolidation of stroke drawing has been made through several related bug fixes.  After the introduction of face smoothness in last November, branch users may have seen a warning message shown below in the middle of stroke drawing:

Warning: you should not be there…

This warning turned out to be due to those edges in the view map that have a two-dimensional length almost or exactly equal to zero.  When such a zero-length edge was in a chain of edges on which a stroke was drawn, a number of style module API functions such as MaterialF0D() failed.  In addition, MaterialF0D() had another bug that an error condition was ignored due to a wrong return value.  In the end, these bugs jointly caused stroke color to be left undefined.

This stroke drawing instability has been addressed by automatically removing the zero-length edges (and chains of them) before stroke drawing begins and after stroke splitting is performed (e.g., using Operators.sequentialSplit()).  The bug in MaterialF0D was also fixed.

Moreover, possible memory leaks due to errors in user-defined style modules have been fixed.  Since scripting errors during style module coding are inevitable, these fixes improve the stability of the program regardless of having temporary programming errors in user-defined predicates, chaining iterators, and shaders.

• A bug in stroke rendering with round/square caps was fixed.  A freeze of the program was caused by a stroke having two vertices that reside (exactly or almost) at  the same position in the 3D space.
• The Parameter Editor mode was improved so that it accepts quote symbols within the names of scene render layers and linesets.
• Incorrect vertex normals in the case of smooth surfaces were fixed.  Many thanks to Stéphane for his careful code review and bug report!
• Compilation errors with CMake on Linux were fixed by a patch from Écrivain through the BA Freestyle thread.  Thanks!

In addition, the Freestyle Python API has been slightly extended by wrappers of the following Operators class methods in the C++ layer:

• getViewEdgeFromIndex(index): Returns a ViewEdge object in the current set of ViewEdges (0 <= index < Operators.getViewEdgesSize()).
• getChainFromIndex(index): Returns a Chain object in the current set of Chains (0 <= index < Operators.getChainsSize()).
• getStrokeFromIndex(index): Returns a Stroke object in the current set of Strokes (0 <= index < Operators.getStrokesSize()).

When you want to iterate over all objects in the current set of ViewEdges, Chains, or Strokes (for instance, in order to find the minimum and maximum Z depths, or sum up the lengths of all strokes), these API functions give a procedural programming way of accessing the objects, instead of relying on implicit side-effects of declarative rules (such as predicates and shaders).

A compilation issue with MinGW32 was fixed thanks to a report from Dazzle, and a bug in Distance from Object modifiers due to a recent change in the trunk about matrix-vector multiplication was fixed based on a .blend file provided by Jonathan Hudson.  We really appreciate the user feedback, which helps the dev team to improve the software.

In the meantime, the Parameter Editor mode was extended with two new feature edge selection options.  One is the “Selection by Group” option and the other is the “Selection by Image Border” option, both in part of linesets in the Parameter Editor mode, as shown in the screenshot below.

The Selection by Group option allows you to select feature edges based on a group of objects (defined through the Groups tab in the Object buttons).  For each lineset, you can specify one group of objects.  The group-based feature edge selection is either inclusive or exclusive.  If inclusive, feature edges are selected when they belong to some object in the group; otherwise, those feature edges not belonging to any object in the group are selected.  When no group is specified, feature edges are selected from all objects in object layers enabled in a render layer.  In the past, render layers were the only way to apply different line styles to different objects in the same scene.  This required the use of the compositor and thus a more and less complicated workflow.  The group-based feature edge selection is intended to address this difficulty, making object-specific line stylization much easier.  The image below is a result using this new feature.  A group of objects comprising a lily in the middle was defined, based on which white lines were drawn.  A different line style was applied to lines of two lilies in the left and right using a separate object group.

The Selection by Image Border option is used to select feature edges within the border of the image being rendered.  The border is defined either by the frame size or a border region (specified by the Shift-B key in a 3D View window).  When you work on a big scene with a lot of objects outside the viewing frustum, enabling this option leads to less memory consumption and possibly shorter rendering time.

Finally, the data flow within the Freestyle renderer was revised with the aim of reducing the amount of memory consumption.  Rendering of a 3D scene in Freestyle involves several data structures holding different representations of the scene and strokes generated from the scene.  The data processing in Freestyle is summarized as follows:

1. First of all, mesh data are imported from the 3D scene and stored in a tree-based data structure.
2. The mesh data are transformed into a data structure called winged edges and stored in a 3D grid structure for efficient spatial search.
3. The winged edges are used for view map calculation, and a separate view map data structure is constructed.
4. The view map is fed to stroke generation by means of style modules (it is noted that the Parameter Editor mode is implemented as a built-in style module).
5. Generated strokes are converted into Blender mesh data for stroke rendering.

Previously, all the data structures were kept until the end of the entire rendering process.  This makes sense in the original, stand-alone Freestyle program, in which the view map, for instance, can be reused for applying different style modules one after another.  This is not the case in Freestyle for Blender, where the view map is recalculated for each render.  Therefore, the memory resources allocated for the data structures should be released soon after they become unnecessary even in the middle of the rendering process.  For this reason, memory usage improvements were made with regard to the aforementioned data structures.  The improvements were verified by a test scene (generated using a modified version of “Arc Sphere.es” in Structure Synth) consisting of 34968 vertices and 52452 faces.  The left image below is a rendering result.  Using a 64-bit Windows machine, memory consumption in the latest revision 33485 was compared with that in revision 33434 without the memory-related updates.  The right image below shows the amount of allocated memory (in the vertical axis) throughout the rendering time (in the horizontal axis).  The maximum amount of allocated memory in the older revision was about 2.138 GB, which reduced to 1.439 GB through the memory usage optimization as well as the Selection by Image Border option.

Experiments with several other test scenes showed that the extent of memory usage reduction depends on scenes.  We hope the reported updates will allow branch users to render big scenes without an out-of-memory crash.

So far, mesh geometry data was treated as if all faces were flat (i.e., face smoothness was just ignored), which implied that the view map was composed of jagged feature edges as illustrated in the example below.  The left image is a rendering result of a torus mesh, where strokes are drawn along visible and hidden silhouette lines of the torus.  The right image shows the feature edges (highlighted) from a three-dimensional non-camera viewpoint.  These jagged polylines are what constitute the strokes that appear in the render.  As you see, the feature edges exactly lie on edges in the mesh geometry data.  This causes somehow jaggy strokes in the rendering result (especially in the part of the render where strokes make a quick turn).

When the face smoothness is taken into account in the view map calculation, the resulting feature edges totally differ from the outcome shown above.  As seen in the example below,  the three-dimensional feature edges representing the silhouette lines are much smoother.  The left image is a render of the same torus mesh, whereas the right image shows the smooth feature edges resulting from the view map calculated by accounting for the smoothness property of mesh faces.  Note that the smooth feature edges are no longer constrained by the original mesh topology.

As far as the dev team has experimented with several test scenes, taking account of mesh face smoothness results in a cleaner stroke topology.  The downside is that the visibility of smooth silhouette lines is mathematically not well-defined.  This means that rendering results may suffer from some artifact due to incorrect line visibility.  To our knowledge, the visibility of smooth silhouettes is still an open problem in computer graphics research.  Therefore, we decided to introduce an option for enabling/disabling mesh face smoothness in the view map calculation.  In the Freestyle branch revision 33350 and later, you have the new option “Face Smoothness” in both the Parameter Editor mode and Python Scripting mode.  When the option is enabled, the view map calculation accounts for face smoothness.  This option is intended to allow users to try the two ways of view map calculation with and without face smoothness and find which one would fit individual application needs.  For now the option is disabled by default in order to avoid the aforementioned visibility issue.