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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
