Freestyle integration into Blender

November 28, 2010

Weekly update November 15-28

Filed under: Update — The dev team @ 1:15 AM

The dev team was working on a bug fix during the last two weeks in close collaboration with Stéphane, the main developer of the original Freestyle program.  The problem was that the view map calculation did not take mesh face smoothness into account.

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.

Advertisements

November 15, 2010

Weekly update October 25-November 14

Filed under: Update — The dev team @ 12:54 AM

The dev team was working on bug fixes and stability improvements during the last three weeks.

First, a fatal bug in the internal representation of curves (e.g., chained feature edges, and strokes) was fixed.  The bug was in the constructor of the CurvePoint class in the C++ layer, and in fact it was the source of several similar bugs.  For ease of future bug hunting, a fatal error in the CurvePoint constructor will result in a verbose error report in the console.  If you encounter a crash of this kind, please let us know.

Second, a bug in the SpatialNoiseShader was fixed.  The SpatialNoiseShader is used by standard style modules to add noise distortion to strokes.  The symptom of this bug was that some strokes resulting from the SpatialNoiseShader occasionally disappear from a render.  The problem was caused by a signed integer overflow in the PseudoNoise generator used by the shader.  When image resolution was very large (2000-by-2000 for instance), the buggy PseudoNoise generator could yield a series of huge noise values, which tossed the distorted strokes out from the image boundary.

Finally, a proper support for relative paths of style module files was implemented.  It is recalled that in Blender, file paths are either absolute or relative from the directory in which a .blend file resides.  When relative paths are used, it is a user’s responsibility to keep the relative paths valid.  To help you maintain valid relative paths, Blender offers you the “Remap Relative” option when you save a .blend file.  Suppose that you have created a new scene from scratch (based on the default scene after startup).  When you save the new scene for the first time, the default .blend file path will be $HOME/untitled.blend, where $HOME refers to a platform-specific home directory.  If you have relative paths in the new scene data, they are relative from $HOME.  Therefore, if you want to save the .blend file into a different directory, it is your care to update the relative paths accordingly (otherwise, the relative paths will no longer be valid).  The ”Remap Relative” option does these updates of relative paths automatically.  And from revision 33068 of the Freestyle branch, the “Remap Relative” option takes care of relative paths of style module files.  In addition, the following operations work properly with respect to style module files:

  • File >> External Data >> Make All Paths Relative
  • File >> External Data >> Make All Paths Absolute
  • File >> External Data >> Report Missing Files

Create a free website or blog at WordPress.com.