More feedback

Before I start answering your questions, I just want to remind you all that Freestyle is currently a development branch that is prone to crashes, memory leaks and all of the worst you can expect from the integration of two very different code bases. I understand your frustration for all of the crashes and the “monochrome” renders, but this is what happens when you use an unstable branch. Use it at your own risk and try to help me fix your situation by sending bug reports. If you expect production-quality execution, I would advise you do not use the branch at all (it will ease some of the frustration I have read on the thread ;) ). Also, note that some of your questions can be answered by reading/searching the blog.

I want to particularily thank Ronin and Jesterking for helping me out answer some of the questions for me. I am impressed by the animation provided by Ronin on the BA thread (demo1 and demo2)

Finally, I don’t know why but none of my posts on the BA thread are listed. I registered 4 days ago. Is that normal to wait for that long for getting moderator approval ?

---

Let me now go over some of your questions from the BA thread.

Interpretation problem (‘Error executing Python script from PythonInterpreter::interpretFile:’)
For all of you whose style modules are not found, that means you have not set up the FREESTYLE_BLENDER_DIR environment variable correctly (either the path or the path format is wrong). FREESTYLE_BLENDER_DIR should point to the directory where the data and style_modules_blender folders are stored. Examples:
– *nix:  (I set it in ~/.profile)
export FREESTYLE_BLENDER_DIR=/Users/joe/branches/soc-2008-mxcurioni/
– Windows:
set FREESTYLE_BLENDER_DIR=C:\freestyle\befree-win32\.blender\scripts

General problems

– “warning: you may want to set the $home environment variable to use APPNAME. Otherwise, the current directory will be used instead”
this message will be removed. The $HOME directory is not used by Freestyle.

– “glBlendEquation unavailable on this hardware -> switching to strokes basic rendering mode”
from my understanding of the original code, it means your graphics card driver does not support the glBlendEquation function, that is part of the GL_ARB_imaging subset. This problem only seems to show up on Windows and that’s why the original Freestyle authors probably defined two rendering modes (with and without blending).

– “when I drag the renderwindow out the screen,the part of the out screen will be rendered in black. Is it a bug?”
I am not having this problem on my Mac. This is probably related to the OpenGL implementation of your card. It is important to remember that strokes are currently rendered using OpenGL in the render window’s back buffer before being copied to Blender’s internal memory.

yellow’s questions (which were answered by Ronin for the most part)

– Do I have to set the env variable everytime I fire up blender? or as I have done can I set it the usual way?
It doesn’t matter how you set the environment variable, as long as it is available :) BTW, this environment variable is not a “design choice” on my part; that’s how it was set up originally. Like Nathan mentioned, it will be removed altogether in the future (the style modules and the differents data will be copied to the Blender folder).

– Getting a warning about setting $HOME to use APPNAME if I set $FREESTYLE_BLENDER_DIR in the above way, if I remove it the warning changes to ‘you may want to set the $FREESTYLE_BLENDER_DIR to use APPNAME? Does the $HOME warning matter?
Only FREESTYLE_BLENDER_DIR is required for Freestyle execution.

– Do I have to have ‘Freestyle’ selected in the ‘Output’ panel? The tooltip suggests so? Or is it just for style modules that use edge rendering? It’s in the edge rendering part of the Output panel?
To obtain a result, select ‘Freestyle’ from the rendering engine list (among ‘Blender Internal’ and ‘Yafray’). Then a ‘Freestyle’ tab should appear. By default, the full path of the contour style module should appear. You can click the folder icon in that ‘Freestyle’ panel to choose another style.
The ‘Freestyle’ button in the ‘Output’ panel was inserted when I started work on layers. It is currently not used. It will activate the use of Freestyle in render layers (the same way that the ‘Edge’ button was working).

– Does the camera lens value matter ?
The lens value is actually supported. Unfortunately, only perspective projection is supported. Orthographic projection will be supported later.

– Do I have to have the meshes I want rendered selected?
You don’t select the rendered models by hand. Freestyle only uses geometry that is accessible in your render layer. For example, if your scene has models in layers 1 and 2 but you only select layer 1 for your rendering (in the ‘Output’ panel), then the algorithm will only be applied to the models in layer 1 (I hope it was clear enough…).

– Do I have to have the camera selected?
No.

– Do I need a light in the scene?
No.

– Do all the style modules in the Style_Modules_Blender folder work with current implementation?
The currently supported modules are listed on the page http://maximecurioni.com/gsoc2008/?p=37. I will regroup them on a single blog page soon. I’ll keep you all posted.

Why is there a second modules folder?
For development :) The style modules to use for rendering are stored in the style_modules_blender folder. I use the style_modules folder as a backup of the legacy code, in case my modifications go terribly wrong (I could just delete and get all of the original modules with previous svn revisions, but it’s troublesome in practice to do that).

Would it make sense to avoid confusion if all the modules in the Style_Modules_Blender folder are the only ones known to work?
I never said you could use the style_modules folder :) Please, use the instructions given on the blog.

– I’ve added the /data/textures/papers folder from the freestyle site as blender tells me it can’t find hitepaper.jpg, has that screwed it up? It seems to load the paper but not render it? and I guess thats a typo though it doesn’t matter I guess whitepaper.jpg
This error message has been driving people crazy (me included) for a while but it is nothing important. It is another example of code that made sense when Freestyle was a stand-alone application, but which doesn’t when it is integrated within Blender’s pipeline. It will be simply removed altogether (you’ll set the background yourself as you wish).

– Is it possible to get camera shift working with current implementation?
It is not supported yet and is not at the top of my immediate priorities. Sorry !

Phase 1 finished, on to Phase 2

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.

View map calculation finally works, Python crashes

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 ?

Stuck at the linking stage

I am currently at a halt because of linking issues: gcc cannot resolve the dependencies. Apparently, because of the current linking order, Imbuf functions within my module are not recognized and the final linking stage for the blender program fails. I spent the whole night yesterday trying every possible combination, but to no success. I have asked jesterKing to help me on this and because of compilation issues under Windows, we were not able to work on my current problem.

mfoxdogg also did a compilation under linux today and a few unexpected errors were found. Particularly, one error is pretty worrying: his configuration did not recognize the OpenGL glBlendEquation function. That’s of course totally out of my reach, I don’t expect to know how to correct and support these low-level issues. What should I do ? I asked him to comment the related parts but that’s of course a temporary solution.

I am going to wait for jesterKing’s feedback first. If you could try to compile the current revision and tell me what bugs/warnings/errors you encounter, that would be greatly appreciated.

Update:
Thanks to Jean-Luc, the problem was resolved tonight ! Jean-Luc analyzed the linking order and understood that regardless of the position of the imbuf library in the linking process, nothing would change. He then looked inside freestyle’s library and realized that Imbuf’s functions mangling names were of C++ type (while Imbuf is coded in C). By putting extern "C" {...} around Imbuf’s headers, gcc was able to find the functions in the libbf_imbuf.a library and linking is now working again. Now, I have to debug the Freestyle crash within Blender…

Towards Freestyle's compilation… let the pain begin !

I just finished resolving the first set of dependency problems, compiling lib3ds and swig as independent external libraries. That is of course no real achievement… Nevertheless, this last two days were important for me, as I learned how to use Blender’s SCons building system in practice. I have a rough idea of how configuration, compilation and linking works.

Jean-Luc, I am going to follow your advice and set up an imbuf-based canvas remplacement. I am first going to study how it is used within Blender, and I’ll go from there.

You mentioned that I can use the compiled swig library as a binary. Can you show me how to do that ? I’ll need to run the equivalent of the following command: swig -c++ -python -o ModuleWrapper.cpp $<

Update:
I actually reverted back to my initial solution: I am compiling swig as a program, rather than a library. I also had to modify the BlenderProg function in Blender.py to circumvent the .app creation process. I am aware this is a hack, but it’s temporary. When Freestyle becomes SWIG-free in phase 2, I’ll remove it.

Issues/remarks from application process

Remaining Freestyle bugs
The Freestyle BUGS.TXT mentions a list of remaining bugs. I have personally experienced crashes (not necessarily on big models) and some rare but incorrect silhouette calculations.
Stéphane: how do you want to deal with these bugs ? how about long-term maintenance ?

Mesh structure in Freestyle
This is not a question, just a note to myself. Jean-Luc mentioned that Blender uses an internal mesh structure called vlak (render/intern/include/renderdatabase.h: cf VlakTableNode) to render objects: every object (except strands) is converted to a vlak (triangles) before it is rendered.
I’ll have to see how this might interfere with Freestyle’s inner mesh structure: in the second phase, will I have to convert Freestyle’s mesh structure to vlaks ?

Friendly names for style API
We’ll maybe have to change some of the API’s method/class names, to make them more adapted to artists’ use. We could also ask some feedback from Blender users.