I consolidated the code base today:

• removed unused functions in the Controller and AppCanvas classes
• corrected a crash when the scene is empty
• removed AppGLWidget and all related classes (AFAIR, this was the last remaining Qt dependency)
• added an AppView class to transfer camera information from Blender to Freestyle
• corrected the Python interpreter so that the executed scripts are not left opened in the text editor

Let me know if the 17784 revision is unstable.

Thanks to bupla and his test on the BA thread, I was able to correct an ‘obvious’ bug that would happen when the Vector render pass was enabled. This should correct the “Memoryblock free: attempt to free illegal pointer” message. I committed the correction to the 17764 revision; let me know if this resolves your crashes.

Oversampling and tiling have been corrected and now work as expected (committed as the 17714 revision).

Update:
I corrected a little bug related to rendering. The 17721 revision correctly supports all the chosen filter settings.

To clear up some questions I found on the BA thread:

• Freestyle is activated by toggling on the ‘Freestyle’ button in the ‘Output’ panel and the ‘FrSt’ button in the ‘Render Layers’ panel (sorry, there is no space for ‘Freestyle’ or ‘Strokes’ in the UI….). These are the only required steps to produce a render.
• you can use Freestyle in as many render layers as you want, as well as with compositor nodes.
• the branch is still experimental and not optimized at all for Blender: this explains the big memory footprint for even “regular” scenes and the crashes. There are many different reasons behind all of them (the original API functions not being fully implemented, remaining bugs in the internal engine,…). If you encounter a specific reproducible problem, please let me know by email.
• in the short term, there is no plan to provide an interface to control line attributes. Freestyle is meant to be used for a whole array of styles, not just a few in particular. It wouldn’t make sense to limit the panel to particular styles. Nothing stops one from developing Python UI scripts that simplify style module usage. The final decision to include these scripts or not in the final release will be up to the Blender development team.
• in the original Freestyle program, strokes could be be controlled on a per object basis (using the Id class, each Id determined using the user interface). Unfortunately, AFAIR, Ids are currently given incrementally when models are imported into Freestyle. That means it is very difficult to know which strokes belong to what object. Eventually, I will change it so that a stroke can also have access to the underlying object’s name, not just its Id.

As of today, I consider the second milestone “Render layer for NPR line drawing” of the original project proposal as finished. I am aware that the branch is unstable and has a whole new set of problems, particularly the inability to use textures or to retrieve the depth/color information from the original scene (which in turn means the the DensityF0D and LocalAverageDepthF0D functions cannot be used currently). Nevertheless, I consider that it is important to move on to the next phase “Decomposition of Freestyle’s algorithm into reusable functional modules”, which will integrate the view map in the render database as a render pass: this means you will be able to combine different style modules, directly in the compositor or in code with PyNodes. I also intend on optimizing the current pipeline in many ways. You should consult the project proposal for more details.

But before I move on to the next stage, I want to take a step back and consolidate the branch. The first thing I will do is write a status report. This will allow me to determine which areas of the branch need to be improved for all you brave beta users. For example, I want to finish to port the last remaining style modules. I also think it is time to work on the documentation. I am aware that writing style modules or Freestyle shaders might scare many artists eager to use Freestyle. An effort needs to be made on my part to make their job easier. I am grateful that Tamito will be there to help us in that direction. I have other ideas that I would want to work on in the short term:

• setting up a gallery of Freestyle/Blender results: I would be grateful to all of you who could share their best works on the blog.
• setting up a repository for style modules: this would be great for quickly visualizing style modules, while at the same time learning from others. Another solution would be contacting Blender Materials or other repositories for such a service. If anyone is interested in making it happen, let me know.

I think that’s all for today. I will inform you all when the status report is uploaded on Blender’s wiki. For now, enjoy !

As of today, Blender’s internal renderer can composite Freestyle strokes on top of any other render result. That means Freestyle does not need an OpenGL context for rendering anymore: Freestyle strokes can now be visualized fullscreen or in the image editor without a crash. What a delight !

The complete list of changes for this 17671 revision is described in the commit log. The important information to remember is that:

• the rendering is only correct (in the sense that strokes are correctly overlayed on top of models) if oversampling (OSA) is disabled and if the image is rendered in one tile (Xparts = Yparts = 1)
• style modules using the underlying scene’s depth or color information  will NOT work.

You’ve been warned… Of course, I will work hard on correcting these vital two features in the days to come. Strokes now being integrated in the rendering pipeline, you do have enough room to experiment with your own style modules.

Here are simple results for this revision (the right column presents the strokes produced by the renderer);

As a preliminary first step towards full support for Python’s native iterator protocol in Freestyle, Stroke and StrokeVertexIterator (used in the shade() method of a StrokeShader implementation) have been improved to adhere to the iterator protocol as follows:

• Stroke object has __len__() and __getitem__() methods so that subscript can be used, like stroke[0] and stroke[-1].
• stroke.StrokeVerticesBegin() and stroke.StrokeVerticesEnd() return iterable objects (having next() method).
• “for v in stroke.StrokeVerticesBegin()” is equivalent to “for v in stroke”.

The conventional C++/SWIG-based syntax is still usable, so programmers can choose a preferable syntax.

Simple iteration

C++/SWIG-based syntax:

    it = stroke.StrokeVerticesBegin()
    while it.isEnd() == 0:
        v = it.getObject()
        v.attribute().setThickness(...)
        it.increment()

New syntax #1:

    for v in stroke:
        v.attribute().setThickness(...)

New syntax #2:

    for v in stroke.strokeVerticesBegin():
        v.attribute().setThickness(...)

The strokeVerticesBegin() method takes an optional argument for resampling (the default value is 0, which means no resampling).  The second syntax is useful when the optional argument is specified.

Reverse iteration

C++/SWIG-based syntax:

    it = stroke.StrokeVerticesEnd()
    while it.isBegin() == 0:
        it.decrement()
        v = it.getObject()
        v.attribute().setThickness(...)

New syntax:

    for v in stroke.StrokeVerticesEnd():
        v.attribute().setThickness(...)

Getting the first StrokeVertex

C++/SWIG-based syntax:

    it = stroke.StrokeVerticesBegin()
        v = it.getObject()

New syntax:

    v = stroke[0]

Getting the last StrokeVertex

C++/SWIG-based syntax:

    it = stroke.StrokeVerticesEnd()
        it.decrement()
        v = it.getObject()

New syntax:

    v = stroke[-1]

Getting the number of vertices

C++/SWIG-based syntax:

    n = stroke.StrokeVerticeSize()

New syntax:

    n = len(stroke)

Removing vertices during iteration

There are needs to remove some vertices during iteration.  However, the following code will not work, since the removal of vertices may confuse the iteration.

Incorrect code:

    for vertex in stroke:
        if some condition holds:
            stroke.RemoveVertex(vertex)

If an API were designed so as to make this work, stroke.__iter__() would always have to return a copy of the sequence of vertices, which would be expensive in many cases where the removal of vertices is not necessary.

So, a compromised API design has been taken as follows:

• stroke.__iter__() returns a reference to the sequence of vertices.
• when removal of vertices is necessary, programmers must create a copy of the stroke explicitly before starting iteration over the vertices.

Correct code #1:

    for vertex in Stroke(stroke):
        if some condition holds:
            stroke.RemoveVertex(vertex)

Correct code #2:

    for vertex in list(stroke):
        if some condition holds:
            stroke.RemoveVertex(vertex)

Finally some good news about the integration with the internal renderer ! Having a bit more time this week, I was able to implement an old idea I had during the summer: exporting the stroke information as a Blender Python scene and render it to an image file. The image can then be imported back into Blender and composited on top of the render result produced by the renderer (or saved in its own render layer).

This phase took me longer than expected. Even though the information needed for rendering is very simple (a bunch of triangles with color and texture), rendering the actual triangles is not straightforward in code, especially if I want to respect the selected renderer settings. After some discussion with Tamito, I had even considered using a third-party library as rendering back-end (such as Cairo or Anti-Grain Geometry), but the idea of adding an extra library to the branch and having to support its compilation motivated me to try again to leverage the internal renderer’s capabilities.

I will now create the same pipeline using Blender’s native C functions and extend it as much as I can (for example, adding  texture mapping support for the strokes). I will try my best to get that code released in the next few days for testing. Hopefully, I won’t run into unexpected issues with the migration to native functions. If that is the case, I will release the Python-based code. Either case, I will post updates and results on the blog soon.

Thanks Maxime for the kind introduction.  I am very happy to be a member of the Freestyle integration team.  I was one of many Blender users who were eagerly waiting for the completion of the Freestyle integration, so that I understand the high and ever growing demand for Freestyle as a quality NPR renderer for Blender.  I would like to do my best to facilitate the integration.  In the next weeks, I will be working on better usability of the renderer’s (currently C++-like) Python API.  I hope I will be able to make full use of my experience as a longtime Python programmer.

I merged the so-called antialiasing patch to the Freestyle branch.  Now you can obtain antialiased renders.  I believe the present implementation of antialiasing in Freestyle is useful and stable enough, but please note that this addition is HIGHLY EXPERIMENTAL.  Technically speaking, the current implementation of antialiasing is based on OpenGL accumulation buffer and has required some global changes outside the Freestyle renderer.  This means that

• Antialiasing may not work depending on your hardware.
• It might cause unexpected (I mean, bad) side effects in other functionalities of Blender.
• And thus it might cause data loss and other damages to your products.

So please use the Freestyle branch at your own risk.  A good news is that the hardware-dependent implementation of antialiasing is temporary and will be removed when we move to a new renderer core that does not rely on OpenGL.  One more news is that now the OSA settings for Blender’s internal renderer are respected by the Freestyle renderer as well.  You can change the sampling level and disable antialiasing (although the use of accumulation buffer cannot be disabled).

Great news for all of you who would like the project to advance at a faster pace.  Tamito Kajiyama (a.k.a. T.K. in BA and other places) will also be involved in the integration work from now on. I am thankful of all the time he has already spent improving last summer’s work and I know how much of a boost he will be to keep the project on track. Expect new improvements in the upcoming weeks !

This week, Tamito contributed a patch to enable line parameters present in the original Freestyle program (ridges/valleys and suggestive contours). You can control these features in Blender in the Freestyle tab.

Here is a quick post to answer questions about the progress of the project. First, I would like to thank all of you for your patience and your ongoing enthusiasm on the BA thread. Unfortunately, I do not have anything to present yet. The main reason is that I have been too busy with my work. I also don’t expect to find any significant amount of free time to work on the integration before the second half of November.

Besides time, the major challenge I am facing is the actual work, removing OpenGL from Freestyle. After some conversation with Ton and Jean-Luc a few weeks ago, I have understood that I need a better understanding of both Freestyle and Blender internals to make it happen. That is why I have been going over both source code bases, cataloging the different steps to replace. I spent the whole GSoC stressed out about the next deadline; it had an impact on the quality of the code and the design that I produced. I am trying to pay more attention to it now and that necessarily means a slow-down in the release of features. Another reason for the slow progress is that working with Blender’s internal renderer is no piece of cake. It is not documented well at all and there are many design decisions that I am unfamiliar with. Sadly, I have to find most of the information in the source code itself, and it is a slow process.

As a quick note, I merged Blender’s latest revision with my branch today. Note that if you use scons to build the software, you will need to upgrade it to the 1.0 version (at least).

As of today, Freestyle runs without having to set the FREESTYLE_BLENDER_DIR environment variable: style modules and data files are now stored in the standard .blender/scripts/freestyle directory. This should allow all of you to compile and use the branch for your own tests.

I also generalized the glBlendEquation function verification to all platforms, not just for the Win32 build. Depending on your card and driver, glBlendEquation might not be supported or might only be accessible through glBlendEquationEXT.

I hope that these changes will make the program more robust and will allow a greater amount of people to use Freestyle. Let me know if you are experiencing problems with the latest revision. I am (finally…) moving on to an essential addition: strokes are going to be rendered by Blender’s internal engine (rather than by OpenGL).