As of today, Freestyle runs without having to set the FREESTYLE_BLENDER_DIR environment variable: style modules and data files are now stored in the standard .blender/scripts/freestyle directory. This should allow all of you to compile and use the branch for your own tests.

I also generalized the glBlendEquation function verification to all platforms, not just for the Win32 build. Depending on your card and driver, glBlendEquation might not be supported or might only be accessible through glBlendEquationEXT.

I hope that these changes will make the program more robust and will allow a greater amount of people to use Freestyle. Let me know if you are experiencing problems with the latest revision. I am (finally…) moving on to an essential addition: strokes are going to be rendered by Blender’s internal engine (rather than by OpenGL).

I have not taken the time to update the project recently for many reasons and I wish I wasn’t keeping you all so anxious for more features and documentation. The good news is that I should have some free time in the next few days and I intend on getting some work done.

In the mean time, I made two little corrections today. I first incorporated Tamito Kajiyama’s patch, which he says resolves some stability issues on the Win32 build (particularly on older machines). Secondly, I removed the whole paper textures functionality, correcting the weird “hitepaper.jpg” loading misprint. Right now, strokes are rendered on a white background. In the future, strokes will be rendered directly in their own layer (as was intended in the proposal) so you will have complete creative control over the background.

Before working on the layer functionality, I will get the environment variable “issue” resolved once and for all. I will have the style modules and data directly stored in Blender’s standard directories. I do not know how to do that yet but I figure it shouldn’t be too hard.

I will keep you updated in the next few days on the blog.

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 !

Thanks to Nathan Letwory (jesterking), the Win32 build is now a reality ! Nathan and I were able to hunt down the last remaining problems:

• Freestyle was originally using extgl in its Windows version to determine if glBlendEquation is made available by the graphic card’s driver. Thanks to Apricot, glew was incorporated into Blender a few months ago. I used it to test for glBlendEquation’s presence.
• The original SConscript file for the Win32 build was somewhat buggy and would not compile the files in the rendering folder.
• Custom Python searchpaths provided by Freestyle (used to import style modules) would not be recognized by the Python interpreter due to format inconsistencies (Blender’s file functions would use a single forward slash for directory separators, while Windows require double backslashes). Nathan normalized the paths by adding the ‘r’ prefix to each pathname.

The latest revision (16442) can be used to produce a fully-working Win32 build (do not forget to define the system environment variable FREESTYLE_BLENDER_DIR, containing the full path to the source/blender/freestyle folder). I encourage you all to make a build a share it on graphicall.

[I originally posted this message on BlenderArtists in the Freestyle thread (http://blenderartists.org/forum/showthread.php?t=89986&page=7) to answer some questions that I found there. It is still waiting for moderator approval so I am putting it here too to make sure you all have this information.]

Hello everybody,
I have followed the thread throughout the summer and have wanted to answer some of your questions for a long time, but couldn’t due to lack of time. Now that I am back at school and  “settled” again, I have more time to communicate on the project. First and foremost, I want to reassure you all that despite the lack of recent progress, I still want to actively develop the remaining features of the original project proposal.

Let me now go over your different questions/remarks:

Win32/Linux 64 build
I have made a call on my blog for Win32 builders but have had no response. If you are interested in having a specialized build, are running the platform yourself and are not too scared to download the branch and compile it, please do let me know by sending me an email at maxime.curioni@gmail.com. I would work with you to make this build happen.

Crashes with animation
I haven’t myself tested Freestyle in such conditions. I am sure there is still quite a lot of redundacy in the current code and there is much room for improvement and optimization. If you encounter a crash and are able to recover a core dump or crash-related information, please do let me know. I’d be interested to resolve that issue.

strcmp issue
I added “#include <cstring>” to StringUtils.h. Hopefully, it will resolve the problem.

Trunk integration
I can understand that many of you would like to have Freestyle directly integrated in trunk now. Unfortunately, it is not production-ready and would not even pass Blender’s guidelines for release (I haven’t even started talking about trunk integration with the development team). I am sorry that the work cannot be distributed yet but it is better for long-term stability. I coded many parts of the project in a hurry and I would to go over many areas of my code, to clean it up.

User accounts on the blog
Apparently, my Wordpress was wrongly configured so email registration was not working all along… I will go over each of the user accounts, manually recreating them and noticing each person by email. After that, I’ll try to configure the blog properly so that registration works. Thank you for your understanding.

I hope I have answered most of your questions. Do not hesitate to share your comments/questions, either on this thread (that I’ll continue to follow) or on my blog.

Thanks,
Maxime

After meeting Ton at SIGGRAPH, elements of further development seem clearer:

• due to Freestyle’s internal geometric data format and the calculations based on it, there is no easy solution for using Freestyle on strands. I’ll have to study more into detail if a conversion to triangles is possible.
• strokes will be rendered by Blender’s internal renderer in separate layers, with one style module per Freestyle layer.  Hopefully, this limitation will be eased when the node-based system is in place.
• a lot of user feedback needs to be gathered about how to ease using and tweaking style modules. Either a front-end to important style modules could be built (therefore having the corresponding parameters configurable in a Blender panel), or style modules could be gathered on a web site and tested on simple scenes (similarly to http://www.blender-materials.org), made by more “technical” Blender users.

Usability is no doubt a big challenge to make Freestyle accessible to a larger array of users. I would therefore appreciate receiving more feedback on how to improve the current model and propositions.

I am also looking for someone to create a Windows build of my branch. I am wishing to collaborate closely with that person to get it working for all of the Blender users who have requested a Windows version of my GSoC work. I received some code patches during the summer from a couple of you but I am not sure I can use them with my last revision. I wish to incorporate them now. The summer program being over, I think it is important to make sure this type of integration is done to allow a bigger pool of users to test the code. While I am it, I am open to resolving any bug you might encounter using my branch.

Going back to school and settling to a new place these next few days, I cannot work on these issues right away. I should be able to start working on the project again later next week.

As of today, the integration is technically achieved: Freestyle runs natively in Blender without the use of any of its former libraries (Qt, SWIG, lib3ds). There are still remnants of libQGLViewer in the code, but they can considered part of Freestyle. This is great news as you should now be able to compile and test my branch on about every platform that Blender runs on. One thing to note is that only vlak-based shapes are supported. That means that strands or halos cannot be rendered by Freestyle yet (sorry, no BBB rendering this month…). I’ll see with Ton how to support these shape types.

Because I am going to SIGGRAPH tomorrow for a whole week and the Google Summer of Code ends on August 18, this is all that I would have been able to produce this summer. Looking back, I greatly underestimated the amount of work needed to replace SWIG. Removing SWIG and lib3ds took me about 5 weeks altogether, while I had only planned for 2-3 weeks. I also wasted two weeks trying to make renderbuffers work within Blender, which wouldn’t have been useful for the project anyway (strokes are to be rendered by Blender’s internal engine eventually).

I am proud of how far the project has gone but I am not totally satisfied. A lot more needs to be done:

• a good amount of code needs to be refactored.
• the last remaining style modules have to be supported.
• Stéphane’s corrections have to be incorporated.
• it would great to support a list of style modules, rather than just one.
• the background paper texture should be removed eventually.
• removing the need for an environment variable would be appreciated by non-technical users.

I’ll start making these changes today and I’ll continue again starting on August 18. Once I have strokes rendered by the Blender’s internal engine, I’ll continue implementing the original project proposal’s features, which will allow Freestyle to be manipulated and tweaked directly in the compositor via Python nodes.

Finally, due to requests, I have opened up comments on the blog. I won’t be able to monitor it much for a week so I hope it won’t get bogged down by spam…

The past two days have been important in stabilizing the SWIG replacement. I have had to face many issues while testing. Style modules with Python shaders would not “hold” the stroke attributes and some valid modules would not show up at all. By carefully studying which data structures needed to be given by reference rather than value and by making sure that the most important methods were available from the Python interpreter, I was able to correct most problems. Here is an example of a tractor model rendered using the latest revision (the style modules are respectively thickness_fof_depth_discontinuity.py, split_at_highest_2d_curvatures.py and cartoon.py):

I tested all of the original style modules tonight, comparing the results produced by Blender with the one created by the native Freestyle application:

I consider the system stable enough to work on replacing lib3ds now. Hopefully, the job won’t be as tricky as getting SWIG out was. I’ll keep you all updated on that progress soon.

Finally a big usability improvement ! You can select the style module for your own tests, without having to recompile Freestyle… Right now, only the style module pathname textbox and the file selection button are available. I’ll try to add more of the original Freestyle preferences if it is useful for the project:

As you should see it in your own test logs, not all style modules execute properly. This is due to either the shade method not yet functioning correctly or the API not taking into acccount all of the possible constructor definitions. This should be fixed soon.

I wanted to jump right on the lib3ds work before testing the new system further, but bad intuition kept me from doing that. I got intrigued by the errors I had gotten when testing and I was not content with the current work-around. Testing the system, I understood that the system was (read: is) unstable and unfinished. I realized it was missing an important feature, that Stéphane had mentioned very early in the project: cross-language polymorphism.

Basically, cross-language polymorphism allows the system to automagically support implementations in both language. If a C++ implementation is not present, the system tries to use the Python version if it is available. SWIG supports this feature through directors. To replace this feature, I had to study in more detail how directors are implemented in SWIG and how I could “recreate” them easily within our system.

The same way that I created a proxy mechanism to support Python to C++ redirection, I decided to support directors by having C++ objects store a reference to the Python object owning them. This gives  them the capability to “redirect” some of the execution back unto Python methods. If a C++ object uses the interface class method at runtime (instead of its own implementation), it will use the related Python object’s method if it is available, else will print an error message.

So far, the contour style module works correctly but style modules with shading function in Python do not work yet. To ease testing, I will (finally) have the style module selectable from the UI.