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.
