Finally some good news about the integration with the internal renderer ! Having a bit more time this week, I was able to implement an old idea I had during the summer: exporting the stroke information as a Blender Python scene and render it to an image file. The image can then be imported back into Blender and composited on top of the render result produced by the renderer (or saved in its own render layer).
This phase took me longer than expected. Even though the information needed for rendering is very simple (a bunch of triangles with color and texture), rendering the actual triangles is not straightforward in code, especially if I want to respect the selected renderer settings. After some discussion with Tamito, I had even considered using a third-party library as rendering back-end (such as Cairo or Anti-Grain Geometry), but the idea of adding an extra library to the branch and having to support its compilation motivated me to try again to leverage the internal renderer’s capabilities.
I will now create the same pipeline using Blender’s native C functions and extend it as much as I can (for example, adding texture mapping support for the strokes). I will try my best to get that code released in the next few days for testing. Hopefully, I won’t run into unexpected issues with the migration to native functions. If that is the case, I will release the Python-based code. Either case, I will post updates and results on the blog soon.
Thanks Maxime for the kind introduction. I am very happy to be a member of the Freestyle integration team. I was one of many Blender users who were eagerly waiting for the completion of the Freestyle integration, so that I understand the high and ever growing demand for Freestyle as a quality NPR renderer for Blender. I would like to do my best to facilitate the integration. In the next weeks, I will be working on better usability of the renderer’s (currently C++-like) Python API. I hope I will be able to make full use of my experience as a longtime Python programmer.
I merged the so-called antialiasing patch to the Freestyle branch. Now you can obtain antialiased renders. I believe the present implementation of antialiasing in Freestyle is useful and stable enough, but please note that this addition is HIGHLY EXPERIMENTAL. Technically speaking, the current implementation of antialiasing is based on OpenGL accumulation buffer and has required some global changes outside the Freestyle renderer. This means that
- Antialiasing may not work depending on your hardware.
- It might cause unexpected (I mean, bad) side effects in other functionalities of Blender.
- And thus it might cause data loss and other damages to your products.
So please use the Freestyle branch at your own risk. A good news is that the hardware-dependent implementation of antialiasing is temporary and will be removed when we move to a new renderer core that does not rely on OpenGL. One more news is that now the OSA settings for Blender’s internal renderer are respected by the Freestyle renderer as well. You can change the sampling level and disable antialiasing (although the use of accumulation buffer cannot be disabled).
Great news for all of you who would like the project to advance at a faster pace. Tamito Kajiyama (a.k.a. T.K. in BA and other places) will also be involved in the integration work from now on. I am thankful of all the time he has already spent improving last summer’s work and I know how much of a boost he will be to keep the project on track. Expect new improvements in the upcoming weeks !
This week, Tamito contributed a patch to enable line parameters present in the original Freestyle program (ridges/valleys and suggestive contours). You can control these features in Blender in the Freestyle tab.