[Bf-committers] Freestyle branch status report May 2012

[Tamito KAJIYAMA]

Nicholas,

Here is a quick attempt of diff -ruN against the trunk revision 46787.

http://www.asahi-net.or.jp/~rd6t-kjym/tmp/diff_against_trunk_r46787.zip

The patch consists of 98070 lines.  Of these, source/blender/freestyle/ (83932 lines) and
release/scripts/freestyle/ (6239 lines) are C/C++ code and Python scripts, respectively,
based on the code from the original Freestyle program.  The rest of the diff (7899 lines)
concerns changes to the Blender code base.  The changes mainly reside in the following
directories:

release/scripts/startup/bl_operators/
release/scripts/startup/bl_ui/
source/blender/blenkernel/
source/blender/blenlib/
source/blender/blenloader/
source/blender/bmesh/
source/blender/editors/
source/blender/makesdna/
source/blender/makesrna/
source/blender/python/
source/blender/render/
source/blender/windowmanager/
source/blenderplayer/
source/creator/

Regards,

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


-----Original Message----- 
From: Nicholas Bishop 
Sent: Tuesday, May 22, 2012 12:09 AM 
To: bf-blender developers 
Subject: Re: [Bf-committers] Freestyle branch status report May 2012 

Do you have a diff against trunk available? I'd be interested to see
how big of a changeset this merge would be.

Thanks,
-Nicholas

On Mon, May 21, 2012 at 6:51 PM, Tamito KAJIYAMA
<rd6t-kjym at asahi-net.or.jp> wrote:
> Hi all,
>
> The scope of this message is to report the up-to-date status of the Freestyle branch and
> discuss the possibility of the merge into the trunk.
>
> Since the January 2011 status report [1], the Freestyle development has focused on
> stability improvements and the completion of selected unfinished components
> including an artist-friendly GUI for interactive manipulation of Freestyle parameters.
>
> The stability of the Freestyle renderer is the highest priority of the project.  Thanks to
> intensive testing by branch users, many instability issues were sorted out and important
> bug fixes were made, such as a fix for occasional straight lines [2], improved handling
> of face smoothness in view map construction [3], and a fix for degenerate triangles in
> imported mesh data [4].  It should also be highlighted that substantial performance
> enhancement of view map construction was contributed by Alexander Beels [5].
>
> The new Freestyle GUI has been improved in many aspects, including the addition of
> new stroke geometry modifiers (e.g., [4, 6, 7]), and easy duplication of line sets and line
> styles [7].  Moreover, new edge and face attributes (Freestyle edge/face marks) were
> introduced for fine-control of feature edge selection [3].
>
> As mentioned in the January 2011 report, the Freestyle integration project listed three
> unfinished components that were planned to be done before the merge into the trunk
> is asked:
> 1. The aforementioned artist-friendly GUI for Freestyle parameters (90%)
> 2. Freestyle Python API Improvements (80%)
> 3. Feature edge detection at face intersection (0%)
> Percent values in the parentheses are subjective achievement rates as of this writing.
>
> In the meantime, I have been receiving an increasing number of positive opinions from
> branch users about the merge.  In fact, the time when the merge will happen is the most
> FAQ of the branch these days.  Aware of the documented incompleteness of the branch,
> however, I personally have a mixed feeling.  Here are some of pros and cons.
>
> Downsides of the merge:
>
> - The feature edge detection at face intersection is a must but not implemented yet.
>
> - Documentation is not ready.
>
> Upsides of the merge:
>
> - More testers of the Freestyle renderer are expected, which will accelerate stabilization
> and improvements of the renderer.
>
> - Branch users no longer have to rely on multiple versions of Blender, which makes their
> workflow simpler.
>
> - More development force can be addressed to the unfinished and other Freestyle
> components.  So far a significant amount of time has been regularly spent for merging
> changes of the trunk into the Freestyle branch, which is not so productive.
>
> In conclusion, I tend to think that the merge is a good idea even at this stage of
> development.  The Freestyle branch is fairly stable and useful.  It has been kept well
> synchronized with the trunk.  For these reasons, the merge can be made at any time.
>
> I am open to discussions about whether or not the merge should take place right now.
>
> Any feedback on this matter would be much appreciated.
>
> With best regards,
>
> --
> KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>
>
>
> [1] http://code.blender.org/index.php/2011/01/freestyle-integration-report-january-2011/
> [2] http://freestyleintegration.wordpress.com/2011/09/25/development-updates-on-september-25/
> [3] http://freestyleintegration.wordpress.com/2011/10/25/development-updates-on-october-25/
> [4] http://freestyleintegration.wordpress.com/2012/04/03/development-updates-on-april-2/
> [5] http://freestyleintegration.wordpress.com/2011/03/18/development-updates-on-march-17/
> [6] http://freestyleintegration.wordpress.com/2011/08/28/development-updates-on-august-28/
> [7] http://freestyleintegration.wordpress.com/2011/12/19/development-updates-on-december-18/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers