Freestyle integration into Blender

April 19, 2009

Weekly update April 13-19

Filed under: Update — The dev team @ 2:15 PM

In the period of April 13-19, there were no commits to the code base of the Freestyle branch.  In the meantime, the developer team investigated a cause of crashes when the camera was orthgraphic instead of perspective.  The cause of the problem has been identified, although a complete solution of the issue still needs a further investigation.

Test renders of the week were offered by bmania from Japan.  The motive is steel pipe desks and chairs for class rooms.  The desks and chairs of these shapes are very common in Japanese schools.  The strokes are clean and strong.  Thank you bmania for the nice renders!

bmania1_tn bmania2_tn

bmania3_tn bmania4_tn

April 12, 2009

Weekly update April 6-April 12

Filed under: Update — The dev team @ 6:39 PM

This week, the branch was augmented with the ability to fine-tune style module configuration at the render layer level. The immediate crashes caused by the modification have been corrected. In the process,  the bug affecting the camera view transformation after a Freestyle render was removed.

After a study of Blender’s data structures, it seems that the view map cannot easily be made available as a render pass. This is a structural problem: the original GSoC 2008 proposal had supposed that Blender render passes were general enough to store any type of computed data. We now understand that render passes are containers of float arrays, which means we have to make a choice of either extending the definition of a render pass to support the view map,  finding a workaround to present the view map at the node level without adding it at the render pass level, or dropping the idea of incorporating the view map in the compositor altogether. The final decision will rest with Ton and the core Blender developers.

Before moving on to the next milestone, we will first work on correcting little annoying bugs and adding minor features:

  • view map calculations sometimes make the program crash, when an orthographic camera is used.
  • strokes are rendered in random order, affecting the end result when they overlap. The stroke depth information should be able to correct the issue.
  • style module configuration cannot currently be saved to file.

The Milestones page was updated. If you have suggestions or requests for the branch, please let us know in the comments.

Let us move on to a test render of the week.  Currently a splash screen contest for upcoming Blender 2.49 has been conducted.  The following image is the raw render prepared for an entry by T.K. The strokes were drawn by slightly modified versions of qi0.py and external_contour.py, while the halftones were generated by a PyNode script.  Encouraged Freestyle users are suggested to submit yours.  The deadline is April 19!

splash_tn

April 8, 2009

Full control at the layer level

Filed under: Update — The dev team @ 3:23 PM

As some have seen in the branch commit log, Freestyle now supports stylistic control at the layer level. The panel has been improved to support many style modules per layer. The feature most lacking right now is the ability to save the module configuration to file.

The immediate feedback on the BA thread mentions some crashes and weird issues with the view. In the next few days, I will concentrate on improving stability. After that, I will implement the saving functionality.

April 6, 2009

Weekly update March 30-April 5

Filed under: Update — The dev team @ 5:44 AM

This week the Freestyle branch received a few commits aimed at consolidation of the Python API. In addition, type checking of boolean arguments in class constructors and methods was relaxed so as to accept not only True and False but also various other boolean expressions such as 0, 1, and None.

Test renders of the week is concerned with quantitative visibility. In Freestyle, the visibility of a view edge (i.e. a line segment in a projected 2D scene) is described based on the notion of quantitative visibility. Simply put, the quantitative visibility of a view edge is the number of surfaces that hide the view edge. If the view edge is not hidden by any surface in the scene, the quantitative visibility of the view edge is 0. If the view edge is hidden by a surface, then the quantitative visibility is 1. If hidden by 2 surfaces, the value is 2, and so on. In style modules, this value can be tested with the QuantitativeVisibilityUP1D predicate. For example, the expression QuantitativeVisibilityUP1D(0) is true if the quantitative visibility of a view edge is 0 (i.e., the view edge is visible) and false otherwise. Consequently, Operators.select(QuantitativeVisibilityUP1D(0)) is an operation to select all visible view edges in the scene.

The notion of quantitative visibility was originally proposed by Arther Appel in a paper published in 1967. The image shown below is a test render intended to reproduce Figure 1B in the paper using Freestyle. You may notice that the quantitative visibility values shown in the test render are slightly different from the values presented in Figure 1B. In fact, the paper defines quantitative visibility as a value that increases or decreases when a line in question passes a contour line. For the purpose of a stylization API for human artists, Freestyle’s modified definition of quantitative visibility looks a bit more intuitive. By means of the QuantitativeVisibilityUP1D predicate, you have a fine control on view edge visibility.

fig1b_tn

The WordPress Classic Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 61 other followers