Freestyle integration into Blender

June 18, 2008

Sorry for lack of progress

Filed under: Other — The dev team @ 10:31 PM

Dear Blender community,

I’d like to apologize for the recent project slowdown in the past two weeks. I am aware of the level of expectation from many of you (I just read the post on BlenderNation a few days ago, thanks for all your words of encouragement) and I feel you all deserve more regular feedback. I am sorry I haven’t been able to keep up with substantial updates, in the branch or on the blog.

I am currently finishing up my last school term as a university student and I am trying to do that as best as I can, with the time that I have left. Of course, I am totally bogged down by exams and reports to hand in. Same situation every year and sadly always the same outcome… When will I ever learn ;)

I’ll be totally free on Friday, June 27. After that and until SIGGRAPH, I will be able to work on the project full-time.

Thanks for your patience,

— Yours Truly


June 15, 2008

Phase 1 finished, on to Phase 2

Filed under: Notes, Questions, Update — The dev team @ 11:21 PM

I finished the first phase tonight: Freestyle has been successfully integrated as an external renderer. The only important feature missing is the ability to select a style module. After discussing with Jean-Luc, we consider the phase 1 finished because all of Freestyle’s basic functionally has been integrated. I will implement a Freestyle panel for style module selection in either phase 2 or 3.

I spent quite some time tonight integrating the camera’s information into Freestyle’s rendering pipeline. I first based the integration on Yafray’s code but it turned out to be a waste of time. I had to look at how Blender generates and stores the view matrix and the camera information. I modified Freestyle’s internal camera’s position, view direction and up vector. When I first tested the camera, I would get inconsistent results: now matter what position I placed my camera at, if I selected a particular object, I would always see the same result. By testing with multi-object scenes, I understood that the camera was somehow resetted after it had been defined. Looking a little bit closer, I found out that the Controller::Load3DSFile function was responsible for resetting the camera, via its call to AppGLWidget::FitBBox(). Uncommenting that function resolved the problem. Here are a few sample results with the corrected camera:

First thing to mention, the result is not exactly the same as the one produced by Blender’s internal engine. When I look closer at where the image is cut off, I can see that Freestyle’s result covers a larger area than Blender’s. I suspect that the cameras’ field of view are different (I haven’t modified Freestyle’s camera’s fov yet). I will of course get that adjusted soon. Here is a comparison of the slight differences:

I also need to mention that Freestyle will crash if the scene is empty or if the view frustrum does not have any object in it. I am guessing the original Freestyle made the scene emptiness test in other functions, so I will also need to add that check soon. For the time being, do not use Freestyle on an empty scene. More precisely, only the currently selected objects are exported by Blender’s Python 3ds export script, so only these objects will be rendered. It is important to call the render function on at least one selected object else it might potentially crash. I have not tested thoroughly if selecting the camera and/or lamps has an impact on Freestyle’s stability.

As of now, Freestyle will only render the “2D scene”, that is the series of strokes resulting from view map information. I decided to remove “3D scene” rendering because it is not one of Freestyle’s objectives and it is a waste of computing resources. In the same spirit, I am suggesting removing all background-rendering related code (the so-called “paper textures”): while it made sense for Freestyle’s original program, it is already taken care of by Blender (with the Sky render layer, for example). Freestyle has to be integrated as a “transparent” render layer, only containing the strokes built from the view map.

I am starting work on Freestyle’s render layer tomorrow. I will spend most of this week reading Blender’s internals, to understand how render layers are implemented and how SWIG can be replaced with Blender’s Python API. Since I finished phase 1 a week later than originally planned, I updated the project schedule with new deliverable dates. Phase 2 should end in three weeks on June 6 (right in time for GSoC midterm evaluation…). Its objective is the implementation of Freestyle’s own render layer.

June 13, 2008

Removed compiled file paths, introducing environment variable

Filed under: Update — The dev team @ 10:46 PM

To make cross-compilation easier and prevent having to fix some metadata at compilation time, I modified the execution pipeline and the application configuration class Config. As of now, Freestyle requires the environment variable FREESTYLE_BLENDER_DIR to determine the different files needed for execution (style module, Python 3ds export script, paper texture….). Freestyle can now be run without any modification and on any platform, as long as the FREESTYLE_BLENDER_DIR environment variable correctly points to the directory [branch]/source/blender/freestyle and the SWIG wrapper module is compiled and linked correctly.

I should have the first phase finished this week-end, correctly transposing the camera parameters (position, orientation, field of view…) and allowing the user to choose the style module at runtime through Blender’s interface.

June 8, 2008

Scene rendering

Filed under: Update — The dev team @ 7:54 PM

Because of school, I have not been able to work on the project this whole week. Today, I modified Freestyle’s execution a bit. The current scene is now rendered (I modified Blender’s 3ds export Python script so that it calls its saving method when interpreted). The scene is still rendered with a fixed style and a fixed camera set in test_config.h. I will remove these dependencies in the next days. I modified the execution pipeline to initialize the view and the controller only once. Therefore, the subsequent renderings are faster.

I think that I also removed the pending ‘aspect ratio’ bug by calling the proper Camera setter function. In this revision, the BF_LIB3DS_LIBPATH variable is no longer here and corrects a linking warning/error.

Here is the render of Suzanne for the ‘contour’ style (note that the results is not exactly similar, as Freestyle uses a perspective projection) :

Blog at