[Bf-committers] Freestyle integration in Blender 2.5 branch

[Brecht Van Lommel]

Hi,

Sorry this took so long, wanted to take time to understand the code properly.

> Ton has contacted Tamito and me regarding the state of the Freestyle
> integration into Blender. A first draft of the status report is available on
> the wiki and we have just started documenting the internals:
> 
> http://wiki.blender.org/index.php/User:Mx/Freestyle_status_report_Summer_2009
> http://wiki.blender.org/index.php/User:Mx/Freestyle_Internals_Overview
> 
> We are preparing a merge with the 2.5 branch in the upcoming days. Before
> going ahead, we would like to hear your opinion on some issues.

The main thing that is not clear to me is how exactly freestyle gets
it's data from Blender. From my perspective, when I do refactoring in
the render engine, I would like the interface and interactions between
freestyle and Blender to be clear. Maybe it would help if the code that
interfaces with the rest of Blender would all be in one folder (with
the exception of things like BLI_* or BKE_utildefines.h).

One thing that doesn't seem right to me is what happens in
BlenderStrokeRenderer, it looks like a hack to me to create an own
temporary scene and then call RE_BlenderFrame, but I don't have an easy
alternative.

> - Freestyle is currently stored in three locations:
> 
> style modules: release/scripts/freestyle/
> Freestyle DNA: source/blender/makesdna/{DNA_freestyle_types.h,
> DNA_scene_types.h}
> core engine: source/blender/freestyle/
> 
> I remember some core developers finding some of these locations
> inappropriate.

I don't see any problems with those locations. For scripts in 2.5, we
haven't decided on a directory structure yet, but perhaps
release/freestyle would be more in line with 2.5.

> FYI, Freestyle should be considered as part of the internal
> renderer. We aim to replace the toon-edge functionality as a whole, if
> possible and if you all agree. We are aware that it would increase the
> computation time for silhouettes, as the view map computation time is
> proportional to the number of scene triangles (if I am not mistaken, the
> current toon-edge implementation in contrast directly calculates edges from
> the depth buffer at the "proper" image resolution). We are open to both
> systems existing in parallel if a general consensus is made that the
> toon-edge functionality does not overlap with Freestyle's.

I think it's no problem to remove the old toon edge code. It's just not
even remotely as good. The only thing that it has over freestyle seems
to me that color + edge intensity are easy to understand, I think the
freestyle panel should be improved to make setting edge intensity and
color as simple as edge render. "kr Derivative Epsilon" is a very
cryptic option as well, that kind of thing should be
renamed/reparametrized into easier to understand properties.

Regarding modules, I think this could really benefit from working in a
2.5 like way. The python API can be preserved, that would be too much
work to change probably, but I think style modules should register
themselves and then appear in a menu, rather than the user having to
browse scripts. Doing own scripting should be possible too, but for
other extensions we'll probably add a way to run included text files
when the .blend file loads, so that you can easily bundle your own
styles as well and they will be in the menu for the .blend file.

What that would mean is that in RNA you define a FreeStyleModuleType or
something like that, and allow it to be subclassed in python (there's a
generic mechanism for this). There's also a system to add own properties
to such a module, and this class would then have two callbacks. render()
to render, which allows you to retrieve the properties and call all the
standard freestyle modules and functions, and ui() to make a UI layout
for the properties in the panel.

If you think this is a good idea, I can help setting it up, it shouldn't
be much work for me since this is very similar to what already happens
in other places.

Brecht.