[Bf-committers] Freestyle branch review
Brecht Van Lommel
brechtvanlommel at pandora.be
Fri Oct 26 15:58:26 CEST 2012
Thanks for your detailed reply :)
On Fri, Oct 26, 2012 at 2:19 AM, Tamito KAJIYAMA
<rd6t-kjym at asahi-net.or.jp> wrote:
> The location of the Freestyle toggle button in the post processing options
> has been a matter of discussion with a lot of criticism from branch users.
> I also find it a bit bothersome that one has to go to the Post Processing
> panel to enable Freestyle. The present location of the toggle is however the
> most logical one among those proposed so far.
> The rationale of the present location of the toggle button is two-fold:
> (1) it globally turns Freestyle on and off; and (2) other Freestyle-related UI
> panels are associated with a specific render layer.
> Individual render layers can have a distinct set of Freestyle parameters.
> The Freestyle panel in the Render options is intended to accommodate
> these per-layer parameters. The Freestyle toggle in the Include secion of
> the Layers panel is used for enabling/disabling Freestyle on a per-layer basis.
> When Freestyle is disabled by the Include: Freestyle toggle in a render layer,
> the Freestyle panel does not show up. For this reason, it seems out of place
> to put the global toggle button in the Freestyle panel header.
> One possibility here is to change the default settings as follows: enabling
> Freestyle in the Post Processing panel, and disabling the Include: Freestyle
> toggle in the Layers panel.
Ok, I guess the first simple thing to fix would be to show the panel
contents grayed out (layout.active = False) in case freestyle is
disabled, that at least make it more clear that you need to enable
something outside of the freestyle panels.
Further, I think it would be a good idea to have a panel with global
freestyle settings in the render properties, like the line thickness
(and maybe the raycasting should become a global option too?). This
could then include the toggle in the header instead of the post
The other panels with per render layer settings could move to a
separate properties editor tab. In fact why not call this the Render
Layers tab, and move the Layers panel there too? That panel is
ridiculously big anyway and a Render Passes panel could be split off.
The freestyle panels would fit there fine then. I think this could
make what is per scene and what is per layer more clear.
> I agree that the default settings of Freestyle-related parameters can be better.
> Having a pre-defined line set with simple black lines would be of great help
> for new users. The present default settings is admittedly not well maintained,
> as Freestyle-specific settings in startup.blend tend to be overwritten and lost
> by updates of that file in the trunk. The merge of the branch into the trunk
> will solve this issue.
Ah, that explains it.
>> * 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?
> The general comment is appreciated, and I welcome any further comments
> and suggestions in detail. Concerning the line sets list, I agree to move it to
> the Line Sets panel.
* Don't create buttons with the width of the entire panel, things are
usually grouped in two columns.
* Better to gray out stuff than show/hide it on toggling settings. I
guess you have to be more conservative with panel space in the render
properties, but in a separate tab there could be a few more panels.
* The Line Set "Selection by" could perhaps become 3 tabs or so, like
the Line Style tabs.
* Misc Like Style tab could be removed.
* Chaining could be an enum No Chaining, Plain Chaining, Sketchy Chaining
* Dash/Gap buttons could be aligned to each other.
* Min/Max angle for example could be made more compact, like
(v) ( Min: 0.0° )
(v) ( Max: 0.0° )
Further, the layout code isn't that great at showing groups of options
but you can use some tricks to make things like grouped better.
Usually takes a bunch of tweaking though.
> The development of the Parameter Editor mode is in the first stage at the
> moment. For now, the high programmability of Freestyle is maintained by
> just keeping the old way for using Python style modules. For this reason,
> you may find it strange to have these two completely independent manners
> of line stylization. I expect this situation can be improved in the future.
> The Python Scripting mode and the Parameter Editor mode can be mixed.
> Individual render layers can be set to one of the two modes.
Ok, sounds good. The parameter edit mode indeed already makes things
100x more user friendly.
> I am open to suggestions of better naming for the Line Style datablocks.
I couldn't think of a good name yet, something like "Freestyle Style"
makes sense but sounds strange of course. "Line Drawing Style", "NPR
Style", "Line Rendering Style", "Freestyle Shader", .. none of those
are obviously best to me. The name is just a minor point really.
> For what concerns the time when the merge happens, I am completely open.
> The best way to go is a matter of discussion, and I am more than willing to
> hear opinions.
> I am not so optimisitic about the amount of time required for the implementation
> of the discussed elements, since I am the only active branch developer and I tend
> to be time-constrained. Hence I tend to avoid providing estimated arrival time.
> That said, I have been able to keep working on the Freestyle branch, and I think
> I am going to continue the integration work no matter what the decision is.
Sure, we don't have to make a decision about a time frame. It's not
that I want this to be merged as soon as possible, but it would be
nice if all the work you're doing can end up in an official release at
some point. But I guess currently the conclusion is, development
continues, and we can schedule it for a release when it's closer to
More information about the Bf-committers