[Bf-committers] Freestyle branch review

Tamito KAJIYAMA rd6t-kjym at asahi-net.or.jp
Sat Oct 27 01:36:56 CEST 2012


Hello Brecht,

Thanks again for many constructive comments.

> 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.

I agree.

> 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
> processing panel.
>
> 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.

These are definitely good ideas.  I like the idea of creating a new tab
for per render layer options and moving the Layers panel from the
Render tab to the new one.  In fact, what made me reluctant to move
Freestyle-specific options to a new tab was that the new tab would
require its own list of render layers in addition to the existing one in
the Render tab.  Otherwise, users might miss the logical link between
render layers and per-layer Freestyle options.  The suggested changes
will solve this quite nicely.  I will definitely give a try to this design plan
in the Freestyle branch.

> Some ideas:
>
> * 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
>
> Angle:
> (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.

Agreed.  I am going to address all these suggestions.

> > 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.

I agree.  I prefer keeping the naming issue open for now.

> > 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
> being ready.

Totally agreed.  I will return to this list when all the discussed elemenets
have been addressed.

Many thanks and with best regards,

-- 
KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>


-----Original Message----- 
From: Brecht Van Lommel
Sent: Friday, October 26, 2012 2:58 PM
To: bf-blender developers
Subject: Re: [Bf-committers] Freestyle branch review

Hi Tamito,

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
processing panel.

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.

Some ideas:

* 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

Angle:
(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
being ready.

Brecht.



More information about the Bf-committers mailing list