Freestyle integration into Blender

May 20, 2008

Lib3ds works, libQGLViewer replacement from its source code

Filed under: Update — The dev team @ 5:57 PM

After finally having Freestyle compiled with the previous code change, I got a little farther in the first phase. The whole process of creating a render is there, it is still not functioning because libQGLViewer’s functionality has not been totally replaced.

The controller execution goes as follows (Stéphane, tell me if I am missing something):

  1. instantiates the config path, the controller and the view
  2. sets the controller’s view
  3. loads a 3ds file (right now a fixed file)
  4. inserts a style module (right now, also fixed)
  5. computes the view map
  6. draws the image

I am currently on step 5. In Freestyle’s code, this step depended on the libQGLViewer widget to obtain the necessary camera information for raycasting calculations. I had originally replaced the Camera class with an empty stub, but that led to view map calculation crashes. I have no choice but to also merge the Camera and Frame code from the libQGLViewer source (that’s thankfully available). The problem that I am currently facing is that merging the code has a ‘snowball effect’ on the required dependencies: Camera requires manipulatedCameraFrame, which requires manipulatedFrame, which requires Frame…. You get the picture, I am going to have to integrate most of libQGLViewer’s code !

The only good news of the night is that model and style module loading runs smoothly without a hitch (I am surprised how lib3ds is working out of the box). I know I am getting closer to a render, even though I am not totally there yet. Besides finishing the libQGLViewer migration, I also need to figure out where to find the required OpenGL context needed for the actual render

Patience, patience, patience….


  1. I don’t think you’re missing anything on the execution flow. I would maybe split the “draws the image” step into two steps, “build strokes” and “render”. There is no preferred order in which to load the camera or the model or the style modules. The only order constraints are that 1) you have a camera and a model before you compute the view map and, 2), that you have a view map and one or several style modules before you compute the strokes.

    Also, I wonder whether you really need to pull that much of the QGLViewer… The main goal of the QGLViewer is to be an interactive trackball-based viewer. That makes its camera management slightly more complicated than for, let’s say, an offline renderer. Do you think there would be a way to retrieve a camera from blender and to not integrate anything from the QGLViewer?

    Comment by stephane — May 21, 2008 @ 9:43 PM

  2. We are in phase I, where freestyle is used like an external renderer. At the moment, it is not a problem to have bits of QGL viewer in code.

    However, in the final phase, we will need to integrate as close as possible in the compositor. In particular, strokes will have to be done in an exr plane (or in an offline buffer and copied to it), so it could be worthwhile to try to decouple as much as possible from QGLw.

    Similary, in the end we will need only the strokes.

    Concerning the GLcontext, blender use a single context per window (See GHOST_WindowCarbon.cpp in intern/ghost/intern) and adjust the space with glscissor.

    For first tests, use the window context, taking care of setting glscissor first. But, as you want to render an image that is potentially bigger than the (blender) window, that wont do it in final phase.

    From there, you can either use an hidden render window the size of your image (the simplest solution, but may cause problems as blender does (incorrectly) some hackeries with its own render window), or use pbuffers.

    Frame buffer objects could be used too and are probably easier, but are a lot less common on older cards, so i would prefer pbuffers.

    Such support will have then to be added to ghost.

    Comment by jean-luc — May 22, 2008 @ 12:18 AM

  3. Thanks for both of your replies and all of the detailed information and suggestions. That will help me a lot in the weeks to come.

    I am not migrating QGLViewer’s code out of real desire or for religious reasons, but for pure convenience. In the first phase, I am only interested in the shortest path to a render, however ugly it is code-wise. I am not concerned about how QGLViewer works, I just want it to work for the time being: that’s why I am “stupidly” translating code to make it Qt-free. But your point is well taken; I will reconsider carefully tomorrow whether it’s worth going that path. Based on that assessment, I’ll see for sure. I have isolated the libQGLViewer methods that are used in Freestyle so I will be able to gauge whether to continue in this direction or not. The nice part about not going the QGLViewer way is that the code could be reused in further phases.

    Comment by maxime — May 22, 2008 @ 6:18 PM

  4. I would also tend to think getting rid altogether of QGLViewer is the way to go (even at step 1), since you just need it to get camera parameters before view-map computation. For the time being, you can probably enter these parameters manually for some test scenes, rather than translate all QGLViewer methods from which the camera depends.

    Comment by emmanuel — May 23, 2008 @ 3:30 AM

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

You are commenting using your 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

Create a free website or blog at

%d bloggers like this: