Freestyle integration into Blender

October 5, 2009

Weekly update September 28 – October 4

Filed under: Other — The dev team @ 1:45 AM

Integrating Freestyle in the RNA is going to be more difficult than we expected. For that reason, we have asked Brecht to help us in the upcoming week to make it happen. Once this is done, we will be able to reintegrate Freestyle in the UI. Unfortunately, we cannot work on other features until we can configure and run Freestyle in Blender 2.5. Thank you for your understanding.


May 4, 2009

Weekly update April 20 – May 3

Filed under: Other — The dev team @ 4:30 AM

It has been two busy work weeks for the both of us. For that reason, the branch has not had any update in that time. We hope to bring new changes in the next two weeks. Thank you for your patience and understanding.

March 25, 2009


Filed under: Other — The dev team @ 6:46 PM

I added the Milestones page to the blog, originally posted on the BA thread. This will give you an idea of what we are currently working on and by when certain features should be implemented. We tried to give you conservative estimates on the dates.  We will update the page with our progress.

January 26, 2009

Out of town until February 15th

Filed under: Other — The dev team @ 6:46 PM

During that period, I will not have Internet access so I won’t be able to answer any of your questions on the blog or by email.

Thanks for your understanding.

November 16, 2008

Welcome on board, Tamito !

Filed under: Other — The dev team @ 11:43 AM

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.

September 9, 2008

Some feedback

Filed under: Other — The dev team @ 2:56 AM

[I originally posted this message on BlenderArtists in the Freestyle thread ( to answer some questions that I found there. It is still waiting for moderator approval so I am putting it here too to make sure you all have this information.]

Hello everybody,
I have followed the thread throughout the summer and have wanted to answer some of your questions for a long time, but couldn’t due to lack of time. Now that I am back at school and  “settled” again, I have more time to communicate on the project. First and foremost, I want to reassure you all that despite the lack of recent progress, I still want to actively develop the remaining features of the original project proposal.

Let me now go over your different questions/remarks:

Win32/Linux 64 build
I have made a call on my blog for Win32 builders but have had no response. If you are interested in having a specialized build, are running the platform yourself and are not too scared to download the branch and compile it, please do let me know by sending me an email at I would work with you to make this build happen.

Crashes with animation
I haven’t myself tested Freestyle in such conditions. I am sure there is still quite a lot of redundacy in the current code and there is much room for improvement and optimization. If you encounter a crash and are able to recover a core dump or crash-related information, please do let me know. I’d be interested to resolve that issue.

strcmp issue
I added “#include <cstring>” to StringUtils.h. Hopefully, it will resolve the problem.

Trunk integration
I can understand that many of you would like to have Freestyle directly integrated in trunk now. Unfortunately, it is not production-ready and would not even pass Blender’s guidelines for release (I haven’t even started talking about trunk integration with the development team). I am sorry that the work cannot be distributed yet but it is better for long-term stability. I coded many parts of the project in a hurry and I would to go over many areas of my code, to clean it up.

User accounts on the blog
Apparently, my WordPress was wrongly configured so email registration was not working all along… I will go over each of the user accounts, manually recreating them and noticing each person by email. After that, I’ll try to configure the blog properly so that registration works. Thank you for your understanding.

I hope I have answered most of your questions. Do not hesitate to share your comments/questions, either on this thread (that I’ll continue to follow) or on my blog.


August 2, 2008

Towards stabilization

Filed under: Other, Update — The dev team @ 8:49 AM

The past two days have been important in stabilizing the SWIG replacement. I have had to face many issues while testing. Style modules with Python shaders would not “hold” the stroke attributes and some valid modules would not show up at all. By carefully studying which data structures needed to be given by reference rather than value and by making sure that the most important methods were available from the Python interpreter, I was able to correct most problems. Here is an example of a tractor model rendered using the latest revision (the style modules are respectively, and

I tested all of the original style modules tonight, comparing the results produced by Blender with the one created by the native Freestyle application:

Style module Status WORKS NOTHING: steerable ViewMap level doesn’t exist NOTHING: steerable ViewMap level doesn’t exist WORKS INCOMPLETE: wrong shape (incorrect getPoint support ?) INCOMPLETE: wrong shape (incorrect getPoint support ?) INCOMPLETE: wrong shape (incorrect getPoint support ?) WORKS WORKS WORKS WORKS NOTHING: GetTimeStampCF is not implemented WORKS NOTHING: TypeError: an integer is required WORKS WORKS WORKS NOTHING: TypeError: an integer is required NOTHING: getFEdge(i1, i2) is not implemented WORKS WORKS NOTHING: can’t select object with id WORKS WORKS WORKS WORKS WORKS INCOMPLETE ? stroke issue NOTHING: GetTimeStampCF is not implemented NOTHING: GetTimeStampCF is not implemented NOTHING: GetTimeStampCF is not implemented INCOMPLETE ? color/stroke issue INCOMPLETE ? color/stroke issue WORKS NOTHING: no warning either WORKS WORKS WORKS WORKS

I consider the system stable enough to work on replacing lib3ds now. Hopefully, the job won’t be as tricky as getting SWIG out was. I’ll keep you all updated on that progress soon.

July 29, 2008

Freestyle runs natively in Blender's Python environment

Filed under: Other — The dev team @ 10:55 AM

Great news ! The SWIG replacement is effective as of today and seems to run fine. I am relieved that all of the hard work I have put in the last two weeks has paid off. I do not know how stable the new system is yet, but I can say that at least it works. I will continue to test it this week and improve it. At least, a good foundation is already in place.

I will start working on getting lib3ds removed today. It’s unclear how difficult the job will be. I can only hope that it is faster than removing SWIG (and it should, I don’t have the same scale of code to produce). The quicker I get that done, the sooner I can make my GSoC project interesting again: integrating Freestyle with the internal renderer. That should then allow me to support render layers. I also wish to add a Freestyle tab in the UI this week, to finally be able to select style modules in the interface.

Even though there is still a lot more work to do, today is still a big achievement for me. For the first time, my work should be compiled on Windows stations without too many problems. I will try to contact platform builders to make sure my work is stable accross different systems. More on that in the next days too.

July 11, 2008

Quick feedback on SWIG removal advancement

Filed under: Notes, Other — The dev team @ 6:32 AM

I am very happy with my progress today. I have a greater understanding of how SWIG and the Python interpreter in Blender works. I feel like I have overcome the knowledge gap necessary to not only implement Freestyle’s Python API, but do it right. For short, I plan on implementing the bare essentials via the Python/C API and transfer the majority of the code in Python (currently done automatically by SWIG). I’ll remove all (currently strongly-typed) iterators for a list-based iteration and I’ll do away with all class casting code. I would want to elaborate on these details but frankly, I am exhausted… I have to get some sleep. I’ll try to describe my approach over the week-end, to make sure that I am getting this right. The resources that I found particularily helpful were:

On a totally irrelevant note, this blog received its first spam comment today. That’s something to celebrate.

July 10, 2008

Approaching SWIG replacement

Filed under: Other — The dev team @ 5:20 AM

I started filling up some classes today and I am finding out that the process is not as obvious as I thought. The major problem is that I am building up the Python support incrementally, with no real “vision”. Having read the way Blender’s Python API was coded in the past few days, I am trying to follow the same standards but I am not sure it is the way to go (especially on error handling). The lack of a clear API means I do not have the data structures to work with and I am challenged by what parts to keep.

The process is no doubt tedious and repetitive. I feel like I am keeping a badly toned-down version of SWIG, contracting the wrapper code it produced. Things get even more complicated with class inheritance: I would have to copy the code from the ancestors, with some slight modifications. I need to figure out with Jean-Luc how to best go about this migration. I hope we will have time to decide on an API and data structures tomorrow.

Finally, I gave the render buffer another shot. Besides continuing to play around with flags, I rewrote the code from scratch. I noticed that, under Blender, I would get crashes when I created buffers/textures attached to “different” attachment points (COLOR_ATTACHMENT2_EXT for example). Using glCheckFramebufferStatusEXT, I realized that the buffer drawn to and read from must be set to the one specified by that attachment point. Nevertheless, rendering to that renderbuffer corrupts the back buffer and the result image. If anyone is able to have frame buffer objects working directly within Blender’s rendering pipeline (a great example would be rendering a simple quad to a texture and copying the resulting texture back into a render layer’s float rect), I would be happy to try it on my machine.

Older Posts »

Blog at