[Bf-committers] Freestyle branch review

[Brecht Van Lommel]

Hi all,

I was asked to look into the freestyle branch, to see what needs to be
done to get it included in an official release. For those not familiar
with how it works, there is some documentation here:
http://wiki.blender.org/index.php/User:Flokkievids/Freestyle

My impression from testing and reading code is that this feature is
extremely flexible, and there's been some great renders, however the
user interface and terminology are very technical and also
inconsistent with other parts of Blender. If it would be a core
feature, I think it should be designed from the point of view of
adding a line drawing feature for the internal renderer, not as a way
to get all freestyle settings available. Blender is not always
consistent but for core features we should at least try to set a
higher bar.

It could also become an external render engine, but it relies quite a
lot on the internal renderer and integrates in some ways that are
currently not possible though or python API. If the purpose of this is
to make a straight integration of freestyle, then I think for a design
point of view it would work best as an external engine, but from a
technical point of view this seems challenging.


UI NOTES:

* Many of the terms are very technical. For example the raycasting
algorithm, from my understanding only two of these are recommed to
use. So why not remove all algorithms but those two, and make it an
on/off option to take out-of-view edges into account? This is just one
example, there's a dozen such options which could get better names and
descriptions. Some names might always remain a bit technical but at
least the tooltip should give good clues then.

* Getting started could be easier, right now it's pretty hard to find.
There's a Freestyle panel but you have to go into the post processing
options to enable it (the Freestyle panel is not grayed out so it's
not clear it is disabled). Why not make that a toggle button in the
Freestyle panel header? Then you have to add a LineSet (could be done
automatic on enable). Then the result renders shows lines but they're
pretty strange on models that I've tested other than a cube. The way
this should work is that you enable freestyle, and it gives you a
reasonable result, from which you can then start tweaking.

* Most of the freestyle panels probably should be moved outside of the
Render properties, right now it's pretty crowded there. It could
become it's own tab perhaps, visible when freestyle is enabled? Also
it might be good to only show things like "mark freestyle edge" when
freestyle is enable, to avoid UI clutter.

* General button placement, labels, etc should be improved. The way
they are aligned and sized things looks a bit messy and inconsistent
with the style used in other parts of Blender. Some buttons are also
organized in strange ways, for example, why isn't the line sets list
in the line sets panel?


DATA DESIGN:

* The data that it adds to the Blender core is basically a LineStyle
datablock, various RenderData and RenderLayer setttings, and per
edge/face marking flags. Besides that there are some python style
scripts.

* The distinction between python scripting mode and parameter edit
mode seems quite drastic, it seems you can only use one or the other?
Once you do this you can only add python scripts and nearly all the
other options no longer have any influence. Maybe this is difficult
because of the freestyle design, but it's a bit strange that you can
no longer assign a style to a particular group of objects from the UI
then.

* The Line Style data block feels a bit out of place between the other
datablocks, maybe it should have a better name but I don't have an
immediate suggestion. Mostly it is strange that this is separate from
the python scripting mode and only works with parameter edit mode. If
I were working on a project and wanted some datablock to reuse line
drawing styles, I wouldn't care if the line style was written in
python or not, both types should be contained in this datablock.

* Python style module scripts are specified with their full paths, to
the scripts folder that comes with the blender executable. This will
not work when trying to use the .blend file on another computer with
Blender installed in a different location. User written scripts should
get relative paths, the built in ones I'm not sure about. Maybe they
should be referred to only by their name, or work more as presets for
users to write their own and place them next to the .blend file or in
a text datablock.


CODE:

* Overall the integration code looks well implemented. The way
datablocks, edge/face marking, operators, properties etc were added
seems ok.

* I did notice some code in blender modules not following style and
naming conventions, but this is not so hard to fix.

* The blender_integration code in the freestyle module I didn't
analyze completely yet, though it looks like it could use some
refactoring to fit better. It's got some strange indentation, missing
GPL license headers, etc too.

* Python script line style follow the freestyle API, which in terms of
code style this is very different from the other API's in Blender. I'm
not sure how strict we want to be here...


So anyway, this is my personal impression, and it looks to me like
this would not be ready for the 2.65 release. I'm not sure what the
best way forward is, if the freestyle developers have time to address
these issues or even agree with them, or if it's ok to keep it a
branch, or if people think it should go in anyway without bigger
changes. Besides the bigger design decisions I think there's a few
pretty clear things that should be fixed for an official release
anyway.

Brecht.