Freestyle integration into Blender

May 25, 2008

View map calculation finally works, Python crashes

Filed under: Questions, Update — The dev team @ 6:31 PM

Since last post, I have continued integrating libQGLViewer’s code and it’s been a painful process: I have wasted a lot of time fixing recursive and Qt dependencies. Until today, I was still working on migrating that code. I decided to backtrack a little to concentrate on only the strict necessary, being a little more selective. I don’t know whether I was lucky or not but that seemed to work:

  • I kept the Camera, Constraint, Frame, ManipulatedCameraFrame, ManipulatedFrame, Quaternion, Vec classes
  • I introduced a Point class, based on QPoint
  • I removed all remaining Qt-specific information (slots, QOBJECT….), interaction-related code (mouse and keyboard code) as well as the keyFrameInterpolator methods

View map building executes smoothly now, looking at the logs (and it doesn’t crash…). The issue seems resolved. Of course, all of the above classes will have to be replaced in the future; I am just happy not to have to do it now.

I tried to move on to next steps (drawing the strokes). The Python interpreter seems to crash as soon as it is sent a command (Python initialization seems fine). My crash dump lists:

0 org.python.python 0x0168eb27 PyImport_AddModule + 22 (import.c:320)
1 org.blenderfoundation.blender 0x00ae4241 PythonInterpreter::initPath() + 65
2 org.blenderfoundation.blender 0x00ae463d PythonInterpreter::interpretFile(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 29
3 org.blenderfoundation.blender 0x00aa4fa3 Canvas::Draw() + 755

I have spent the rest of the night trying to figure out what could cause the crash but haven’t found any real information. I tried including __main__ before importing the module sys, like I saw recommended in certain forums but it did not change anything. I am not sure whether the crash is due to Python, to Blender’s environment or to other reasons. I am confronted with the earlier choice of trying to integrate Blender’s Python environment. Should I do that ? Do I really have a choice ? I don’t know what’s best for me.

I am also interested in integrating the swig wrapper but I am not sure about how to best go about it. Right now, I have compiled it as a shared library (as it is done in Freestyle) and made it available via the Python path. I wonder if linking conflicts are going to appear, since Freestyle’s code in Blender is linked as a static library (while Freestyle as an application is linked with a series of dynamic libraries). Should I still compile the wrapper as an independent dynamic library ?

2 Comments »

  1. Swig docs recommends to build the python extension module as a shared library. They suggest that static linking is possible but might require rebuilding the python interpreter. Here is the link to the relevant section in the swig doc:

    http://www.swig.org/Doc1.3/Python.html#Python_nn8

    Comment by stephane — May 27, 2008 @ 6:41 PM

  2. Thanks for the reference. I managed to get Freestyle’s Python wrapper as a shared library and it seems to execute fine.

    Comment by maxime — May 28, 2008 @ 3:52 PM


RSS feed for comments on this post. TrackBack URI

Leave a reply to stephane Cancel reply

Create a free website or blog at WordPress.com.