In the last 2 weeks, we fixed a few showstopper bugs found during the last minute of full Freestyle integration into Blender 2.5. Now the Freestyle branch should compile and run without a hitch.
In the meantime, the dev team was working on SVGWriter as a pilot investigation of the new RNA API in Blender 2.5. This made us aware of an API design issue in the branch concerning the notion of context. In Blender 2.5, a context refers to a target object to which a certain operation is applied. For example, rendering is an operation, and a scene and associated objects/data used in the scene comprise the context of the rendering operation. The problem is that as of this writing, Freestyle does not have a mechanism that allows style modules to access the context.
Contexts do not matter if you have only one scene in a .blend file, since all data is basically associated with the scene, and it is obvious which scene is the target of the rendering operation. When we have multiple scenes, however, we need a way to know which scene is the target. Try to open a new Blender window (Ctrl Alt w) and add a new scene (by pressing the “+” button next to the current scene name on top of a Blender window). Now you have 2 scenes being manipulated in 2 separate windows at the same time. You can start rendering with respect to each scene by hitting the render button in the corresponding window. Clearly, it does matter to know which scene should be rendered.
Note that the context issue is new in Blender 2.5. Before that, Blender was able to manipulate only one scene, since Blender did not have multiple main windows. That is why there was the notion of the current (active) scene, which can be retrieved by Blender.Scene.GetCurrent() in Python. In 2.5, this API function is no longer available.
As a temporary workaround, SVGWriter always refers to bpy.data.scenes to get the first scene in the list of available scenes in a .blend file. This means that even if you have multiple scenes, the rest of the scenes never get rendered.
It is likely that the Freestyle Python API needs to be revised in the manner that style definitions are placed either in a method or in a function (instead of the module body) and a context is passed as an argument of the method/function. We are going to work on this in the next weeks.
Last week, Tamito completed the final integration of Freestyle into Blender 2.5 ! You should be able to recreate the images that you produced before the transition to the new codebase.
Below, you can find screenshots of the new interface. The workflow has not changed much:
- click the global Freestyle checkbox in the “Post Processing” section to enable/disable the use of Freestyle in the rendering pipeline. (first screenshot)
- click the layer Freestyle checkbox in the “Layers” section to enable/disable the use of Freestyle in the currently selected layer. (second screenshot)
- as you toggle the checkbox, the layer’s style module configuration appears. You can set all of the parameters used by the pipeline: add (filechooser) or remove (black cross) style modules, determine the intended style module order (top/down arrows) or select the style modules to include in the render. (third screenshot)
You should be able to compile the latest branch revision without any problem. Tamito has reported that the program renders correctly on his Windows machine. I am experiencing crashes on my Macbook, due to OpenGL.
You might ask yourself why OpenGL is interfering with Freestyle: great question ! It is unfortunately one of the latest remaining dependency of Freestyle. Even though it is not used in any way during rendering, Freestyle’s internal texture manager still depends on it to instantiate the default stroke texture. Prior to the transition to the new codebase, the OpenGL code would not have any side-effect but things have apparently changed, at least on my machine.
This is clearly a showstopper. My short-term priority is to refactor Freestyle’s texture manager to use Blender’s texture system and have an almost fully-functional Freestyle soon. Let me know if you are experiencing similar crashes. We have also been merging the trunk code into our branch weekly so compiled binaries of our branch follow the latest 2.5 developments.
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.