[Bf-committers] Freestyle integration in Blender 2.5 branch

Maxime Curioni maxime.curioni at gmail.com
Mon Aug 31 02:49:36 CEST 2009


Hello Brecht,

Thank you for taking the time to review our code and sorry for my late
reply.

    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.


You make a legitimate point about Freestyle's interface with Blender being
spread amongst many files. Currently, these interactions can be understood
with the following files:
- source/blender/freestyle/FRS_freestyle.h: high-level call to launch
Freestyle from Blender's internal renderer, manipulation of Freestyle's
panel parameters
- source/blender/freestyle/FRS_freestyle_config.h: call-back function to
add/delete Freestyle configurations as render layers are added/deleted.
- source/blender/freestyle/intern/scene_graph/BlenderFileLoader.h: imports
geometrical and material data into Freestyle's native format, allowing
computation of its internal data structures (view map being one of them)
- source/blender/freestyle/intern/stroke/BlenderStrokeRenderer.h: renders
shaded strokes natively using the internal.

The reason Blender{FileLoader,StrokeRender}.h were not stored at the same
level as FRS_freestyle{_config}.h was to be consistent with Freestyle's
original file organization. We can definitely move them to a single
directory and group all interface-level headers.

Regarding BlenderFileLoader and BlenderStrokeRender, in a perfect world, we
would not need them: we would directly calculate Freestyle's data structures
using Blender's data and would render the strokes without the current hack.
Unfortunately, things aren't as simple as they seem.

For robust processing, Freestyle needs to import and normalize the
geometrical data it operates on. In the original program, the geometrical
data was only imported once, so that step wasn't much of a problem. The
current set-up naively imports it at every frame. It is over-kill, but it is
the only temporary solution if we want to use Freestyle for animation. We
definitely need to correct it; it is just hard to estimate how much effort
the correction would need.

Same thing for BlenderStrokeRender. Like you said, the current setup is a
hack: it builds up a scene with the result stroke triangles, rendered with
the internal renderer. A naive yet more suitable approach would be to
incorporate a triangle renderer into Blender, which is by no-means a simple
task if you want anti-aliasing, textured triangles and integration with the
different rendering parameters. Sure, the current approach is not the best,
but it just works: the rendered strokes are not produced at the expense of
quality or speed. Freestyle's current pipeline is slowed by the geometrical
data import and the view-map computation, not the actual rendering. If you
find a better solution, we are more than open to it.

    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.


I totally agree with your comments. Much work has to be done to make
Freestyle's use easier to a greater pool of users, for simple scenarios
(matching the toon edge parameters) and by finding meaningful
artist-friendly parameter names. I have come to realize that the toon edge
is really fast and robust. I don't really know if it would make sense to
remove it after all. Maybe after a year or two, we could make a sensible
decision. We can settle for the best of both worlds for now.

    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.


The registering approach is a great idea. Tamito implemented a similar
approach for style module parameterization with his Freestyle Parameter
Editor, allowing each style to register its parameters. I hadn't thought of
your solution due to my lack of understanding of the technical changes in
Blender 2.5 (especially at the RNA and UI level).

The current approach for Freestyle's style module selection is directly in
line with the original program. I am definitely open to your solution and
welcome your help to set it up. Tamito and I still haven't finalized how to
deal with UI issues, both in the compositor and in the panel. Once we get it
right, we'll shoot you another email for your approval.

Before integrating Freestyle's codebase into Blender 2.5, I will unify the
interface as you demanded. Let me know if you any other requirement or
suggestion. Finally, if you could also tell us about how you plan to
integrate the code base into trunk, that would be great.

Thanks for your help,

Maxime


More information about the Bf-committers mailing list