Weekly update March 15-28

An attempt to address the full sample anti-aliasing (FSA)  issue in Freestyle was made over the last two weeks.  The outcome is in revision 27805 of the Freestyle branch.  As far as we have tested, the FSA works fine with Freestyle stroke rendering.

In order to address the FSA issue, Blender’s render pipeline underwent careful modifications, which indeed required lots of code reading with regard to the overall data flow in the render pipeline.  On one hand, it was a tough task to understand the render pipeline’s implementation details as it is whenever one has to go through a large and unfamiliar code base.  During the code reading, we examined several different approaches to a solution of the FSA issue.  Some approaches turned to be inappropriate just because of a lack of proper understanding of the render pipeline internal, while other approaches were impractical due to possible performance degradation.  The present solution is intended to be as conservative as possible in terms of memory consumption as well as the amount of file I/O in the EXR image file format.  On the other hand, the code reading was a nice experience in the sense that it helped us to have a clear picture of the render pipeline internal.  Now we feel like the render pipeline is not a black box.

As usual, user-side tests and problem reports are very welcome with regard to the FSA issue as well as other issues.

Weekly update March 2-14

During the last two weeks, the dev team was working on support for full sample anti-aliasing.  At the moment, full sample anti-aliasing does not work well with Freestyle.  Strokes are drawn only in one of multiple samples, which results in very faint strokes in the final anti-aliased render.  The full sample anti-aliasing issue has been demanding a considerable amount of code reading with regard to the render pipeline of Blender’s internal renderer, and so far no major coding has been done.  A proper implementation of full sample anti-aliasing for Freestyle seems a non-trivial task due to the complexity of the render pipeline.  The internal renderer is multithreaded through a tile-based data decomposition in which an image to be rendered is split into a two-dimensional grid of tiles.  Each tile is a small portion of the entire image, and multiple threads work on different tiles in parallel.  When full sample anti-aliasing is enabled, the render pipeline also involves external file I/O in the EXR image format.  These implementation details make it difficult to enhance the internal renderer so that full sample anti-aliasing works properly with Freestyle.  We will further look into this issue in the next weeks.

Weekly update February 22-March 1

Since the last blog post, the dev team was digging into Blender’s render pipeline with the aim of addressing an instability issue regarding animation rendering.  The issue was that animation rendering was very instable when Freestyle was enabled.

After lots of code reading and a number of attempts for resolving the problem, the cause of instability was finally identified as follows.  In the  Blender code base, RE_BlenderFrame() and RE_BlenderAnim() are internal top-level rendering API functions for a single frame and a series of frames, respectively.  These functions employ some global variables to keep render pipeline states.  Freestyle’s stroke rendering was relying on RE_BlenderFrame() to render a temporary scene of stroke meshes.  This means that two calls of the top-level rendering API functions were nested, which caused broken render pipeline states and eventually led to a crash.

An attempt to fix the instability issue has been made in revision 27213 of the Freestyle branch, by introducing new rendering API function RE_RenderFreestyleStrokes() specifically geared to stroke rendering in Freestyle.  The new function does not do anything with regard to the global variables in the rendering API implementation, so that the render pipeline states are kept clean.  As far as we have tested, animation rendering with Freestyle appears much more stable than it was in the past.  User-side testing and problem reports are highly appreciated.

The renders of the week are offered by mato.  In the BlenderArtists Freestyle thread, he presented impressive line drawings of chrysanthemum shown below, together with a custom SVGWriter style module for drawing strokes with depth-dependent variable line thickness.  Thank you mato for sharing the cool results!