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 onQPoint
- 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 ?
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
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