Freestyle integration into Blender

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.

Advertisements

3 Comments »

  1. Nice work Maxime!
    I see some of freestyle bugs showing up in these images: Some of the triangle strips are twisting and, if I’m right, you’re using the “contours” style module which should theoretically only show the outmost contours of each object (not every silhouette lines, as the qi0.py style module for instance). I’ll try to have a look at these bugs as soon as possible.

    Comment by stephane — June 16, 2008 @ 6:11 AM

  2. That’s right, I am currently using the contour.py style module for tests. I know the teapot was actually made up of two objects, the main body and the lid. I appended the teacup from a .blend model I found online. Let me know if you want me to send them to you.

    How does Freestyle handle object groups/unions ? Does it calculate a different result on each group member or is it applied on the whole object ?

    Comment by maxime — June 16, 2008 @ 4:33 PM

  3. Each geometric primitive loaded in Freestyle has an ID. Currently, the IDs are extracted from the 3DS file by the lib3ds and assigned to the freestyle primitives. If two different primitives have the same ID, they will be considered the same “object” as far as visibility is concerned (a silhouette line which has, on both sides, primitives with the same ID is not flagged as a contour).

    Comment by stephane — June 16, 2008 @ 5:26 PM


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: