User:Kjym3/DevFundProject/2014

From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

Weekly Reports

Week 27: 29th-30th September

New targets for Blender 2.73 release

Now that a release candidate of Blender 2.72 was release last week and the development cycle has moved on to the BCon1 phase, it's time to define development targets for the next Blender 2.73 release. Here's a list of 2.73 targets that have involved me since a while:

  1. Freestyle memory consumption optimization (results of the BF funded project).
  2. Freestyle integrated SVG export (patch D785).
  3. Blender Windows IME support (patch D765).

Small additions and updates to Freestyle line rendering options are also foreseen.

Development tasks

Fixes (unreported)
Patch review
  • D765: Blender input method editor support for windows.
  • D785: Freestyle integrated SVG export.

Acknowledgement

This week concludes the present BF funded project. All the financial and management supports provided to me are duly acknowledged. Special thanks go to Ton Roosendaal and Anja Vugts-Verstappen for their dedicated support for the project.


Week 26: 22nd-28th September

Bug hunting still continued

The final release of Blender 2.72 is yet expected in the middle of the next week, most work hours of the week were addressed to bug fixes and cleaning of pending tracker items.

Some hours were hence spent to further investigate the old report of wrong line visibility in Freestyle (T36350). After a few attempts following the previous debugging trials documented earlier, it turned out that the wrong assumption of linearity in the projected spherical grid space is found everywhere in the code base for line visibility computations. In fact, a major fraction of the line visibility code has been shared by another grid data structure called BoxGrid for orthographic cameras. The BoxGrid data structure relies on a linear grid space, so that the assumption of linearity in line visibility computations is valid. However, the shared use of the same code basis also for the spherical grid data structure seems almost impossible as of this writing. A major revision of the line visibility code for perspective cameras is foreseen as soon as time permits.

Development tasks

Fixes (unreported)
Patches
Patch review
  • D745: Improvements to the cpp-defined Freestyle stroke shading.
  • D765: Blender input method editor support for windows.
  • D801: Freestyle: remove old and unused stroke shaders.


Week 25: 15th-21st September

Bug hunting continued

In view of the upcoming Blender 2.72 release, major revisions were made to the Freestyle Python API documentation. Unfortunately the Freestyle section of the Blender API reference manual was missing due to the reorganization of Freestyle Python modules done in Blender 2.70. It is recalled that the majority of the API reference manual including the Freestyle section is auto-generated by a Blender Python script executed within a release build of the program. The missing Freestyle section was hence recovered this week by relevant code revisions and docstring updates in Freestyle-specific Python modules.

The updated Freestyle Python API manual is found in http://www.blender.org/documentation/blender_python_api_2_72_0/freestyle.html.

Development tasks

Fixes (unreported)
Patch review
  • D785: Freestyle integrated SVG export.


Week 24: 8th-14th September

Bug hunting continued

Still in the BCon3 phase, most work hours of the week were spent to address a few reported bugs (some of them related to the 2.72 new feature of Freestyle line rendering in Cycles). Since one of the bugs was traced to an issue outside Freestyle, a patch was submitted for code review (D779).

Windows IME support

During the week some effort was also made for UI review of patch D765 for Windows input method editor (IME) support in Blender. A proper support of Windows IME has been a missing feature long awaited by blenderheads willing to type Chinese, Japanese and Korean text in Blender. A test build for 64-bit Windows was prepared to reach a wider range of testers relying on Windows IME for composite text editing.

Development tasks

Fixes (reported)
Fixes (unreported)
Patch submission
  • D779: Fix for Freestyle crash in bordered animation rendering.
Patch review
  • D765: Blender input method editor support for windows.
  • D787: Cycles: Add per Render Layer "Film Transparent" Override.


Week 23: 1st-7th September

Bug hunting continued

In the beginning of the week, hours were spent to address a newly identified issue related to the previous solution (commit eb8964f) for the T41464 material boundary bug. The new issue was coming from a combination of old and new forms of iterations (loops over vertices) in Freestyle. Specifically, the Freestyle Python API contains conventional C++-like iterator classes having .increment() and .decrement() methods, as well as a complementary support for the Python iterator protocol based on iter() and next() built-in functions. We concluded that this is a documentation issue and it is up to users to avoid error-prone combinations of old and new Freestyle iterator constructs.

The rest of the week was mostly addressed to the issue T36350 on incorrect line visibility in the case of a perspective camera. Since the issue has been traced down to a design problem of a spherical grid data structure, a revision of the grid structure was attempted. Simple test cases confirmed the effectiveness of the revision, while some complex scenes still resulted in wrong line visibility. Further development in this direction is foreseen in the following weeks.

Development tasks

Fixes (reported)
Fixes (unreported)
Patch review
  • D752: Freestyle: further fixes for iterators.


Week 22: 25th-31st August

Bug hunting continued

This week some work hours were spent for patch reviews. The rest of the weekdays were mostly addressed to the continued work on T36350. After lots of code reading and many attempts to fix the bug, the cause of the reported issue was finally identified in a wrong assumption of linearity in the spherical coordinate system used for the SpherialGrid data structure. The finding has been reported in the task comment T36350#12 in detail. The documented problem turned out to require a major revision of the spherical grid data structure. Further development of the task is foreseen in the next week.

Development tasks

Fixes (unreported)
Patch review
  • D745: Improvements to the cpp-defined Freestyle stroke shading.
  • D752: Freestyle: further fixes for iterators.
  • D765: Blender input method editor support for windows.


Week 21: 18th-24th August

Bug hunting

BCon3 bug hunting started on the 17th of August, so most work hours were directed to fixing bugs. Task T41464 absorbed quite a lot of time and efforts to trace down the real causes of the reported issue. Part of the committed fix for T41464 led to a discussion of a better solution (D752) involving a revision of the Freestyle Python API in view of improved support for the Python iterator protocol (i.e., Python's iter() and next() built-in functions).

In addition, some work hours were spent for a one-year-old bug report (T36350: Freestyle renders extra lines). The reported problem is that some hidden Freestyle lines are not properly occluded by large faces. This issue is only seen with a perspective camera, so the cause seems to be in a grid data structure called SphericalGrid in Freestyle that is used to optimize ray-casting line visibility computations. Initial steps for addressing the bug involved lots of code reading and naive testing to better understand what is going on in the spherical grid data structure.

Development tasks

Fixes (reported)
Fixes (unreported)
Patch review
  • D752: Freestyle: further fixes for iterators.


Week 20: 11th-17th August

Freestyle memory optimization

Work hours were mostly spent for the ongoing work on reduced memory consumption in Freestyle. Many attempts to optimize Freestyle memory consumption were made, including:

  • Remove unused tesselated forms of silhouettes for displaying in the UI.
  • Less memory-consuming and faster stroke rendering by avoiding repeated merging of mesh custom data.
  • Further internal switch from double to float.

Some efforts were also addressed to additional optimization for speed:

  • Avoid copying vertex coordinates where possible.
  • Avoid float-to-double conversion in the camera-to-grid space transformation.

After these optimization attempts, preliminary performance tests showed appreciable space-time trade-offs (between memory consumption and rendering time) with regard to the code changes for memory optimization. Specifically, the following portions of the optimized code turned out to be run-time speed bottlenecks:

  • Using std::map (instead of std::vector) to compress a set of pointers to 3D vectors in grid data structures for line visibility computations.
  • Computing 3D bounding box coordinates of triangular faces on the fly when needed (instead of storing the minimum and maximum bounding box coordinates into vectors).

Experimental results below show performance comparisons among (a) the non-optimized baseline version, (b) faster optimized version excluding the time-consuming code changes listed above, and (c) less memory-consuming optimized version including all optimization attempts. Table 1 compares the peak memory consumption in units of megabytes, whereas Table 2 highlights differences in overall rendering time in seconds. All results concerned the full rendering of an input test scene including both Blender Internal and Freestyle render components.


Table 1. Peak memory consumption in megabytes.
Test case (#verts, #faces) (a) Baseline (b) Opt. faster (c) Opt. less memory
ichiotsu (75K, 121K) 320.33M (100%) 291.45M (91.0%) 273.51M (85.4%)
ramskull (370K, 741K) 1616.9M (100%) 1409.3M (87.2%) 1309.0M (81.0%)
lily (460K, 749K) 1550.8M (100%) 1361.8M (87.8%) 1206.0M (77.8%)


Table 2. Overall rendering time in seconds.
Test case (#verts, #faces) (a) Baseline (b) Opt. faster (c) Opt. less memory
ichiotsu (75K, 121K) 6.93 sec (100.0%) 7.50 sec (108.2%) 7.93 sec (114.4%)
ramskull (370K, 741K) 35.6 sec (100.0%) 37.0 sec (104.1%) 41.6 sec (117.0%)
lily (460K, 749K) 14.5 sec (100.0%) 17.6 sec (121.3%) 18.8 sec (129.6%)


Further attempts to balance the documented space-time trade-offs are foreseen in the next weeks.

Freestyle for Cycles

The review process of the patch D632 was finalized and the merge of code changes into Git master was approved by Sergey Sharybin. After the merge has been done, the Freestyle section of Blender 2.72 release notes was duly prepared to introduce the new line rendering solution in Cycles, as well as to describe additional new Freestyle features and improvements.


Week 19: 4th-10th August

Freestyle memory optimization

Work hours during the week were spent for optimizing Freestyle for less memory consumption. Memory optimization attempts that led to a significant reduction of memory consumption include:

  • Less memory-consuming stroke rendering by packing stylized strokes into the minimum number of mesh objects.
  • Compression of a set of pointers to 3D vectors in grid data structures used for line visibility computations.
  • Internal switch from double to float in the grid data structures.

Development tasks

Fixes (unreported)


Week 18: 28th July-3rd August

Freestyle memory optimization

In this week most work hours were addressed to Freestyle memory optimization. Careful code revisions were made up on experimental renders for evaluating performance improvements and checking visual consistency before and after the code updates. Performance optimization attempts made during the week include:

  • Internal switch from double to float (except for curvature computations) in the FEdgeXDetector class used for view map building.
  • Optimization for space in the WXFaceLayer class used for silhouette detection.

Considering three test cases (named ichiotsu, ramskull, and lily), performance improvements so far are within the range from 6% to 9% with respect to the peak memory consumption of the baseline (unoptimized) version.

Freestyle peak memory consumption in megabytes.
Test case (#verts, #faces) Baseline Optimized
ichiotsu (75K, 121K) 320.33M (100%) 296.75M (92.6%)
ramskull (370K, 741K) 1616.9M (100%) 1520.5M (90.8%)
lily (460K, 749K) 1550.8M (100%) 1408.1M (94.0%)

Development tasks

The code review of the patch (D632) for Freestyle line rendering in Cycles was ongoing during the week and some patch revisions were also made in reply to review comments.


Week 17: 21st-27th July

Freestyle memory optimization

The patch for Freestyle line rendering in Cycles (D632) was submitted for code review by core Blender developers in the beginning of the week. Hence development focus was moved on to Freestyle performance optimization for less memory consumption. It is recalled that the Freestyle rendering process is divided into several steps as follows:

  1. Mesh loading - Input scene data is received from Blender and cleaned up.
  2. Winged edge building - A graph data structure (called winged edges) for bidirectional traversing of edges is created.
  3. Silhouette detection - Silhouette lines and other feature edges are identified based on winged edges.
  4. View map building - A 2D representation of the input scene (called a view map) is created from winged edges.
  5. Stroke drawing - A set of stylization options is applied to identified feature lines by Python scripting.
  6. Stroke rendering - A raster image of stylized lines is rendered.

Individual rendering steps are implemented in a modular manner, which permits step-by-step performance optimization for space. Several memory optimization attempts were made during the week, including:

  • std::string was replaced by a pointer to a const char array where possible, to avoid string duplicates.
  • Concerning the mesh importing up to the silhouette detection, several class member variables were removed (at the cost of computing their values when retrieved) or changed to a type of smaller size.
  • Redundant instantiation of vector objects was removed.
  • Internal switch from double to float in mesh loading and construction of winged edges.

Memory consumption has been evaluated using the MEM_guardedalloc library with the WITH_CXX_GUARDEDALLOC build option enabled. A couple of helper functions for memory consumption evaluation were implemented to this end.

Freestyle Python API updates

Also in this week, the implementation of the Freestyle Python API was updated with an emphasis on code readability and performance for speed in close collaboration with flokkievids (Folkert de Vries).

Development tasks

Fixes (reported)
Fixes (unreported)
General tasks


Week 16: 14th-20th July

Freestyle for Cycles

Node-based line style textures were worked out and finished in this week. A new UV Along Stroke shader node (in line with the UV Map node) was introduced to allow users to feed to the UV input of texture nodes the UV maps that will be defined on the fly along Freestyle strokes. It is noted that the conventional UV Map node cannot be used for this purpose, since users never see the mesh objects that are auto-generated to represent Freestyle 2D strokes, and thus users are unable to select a UV map name that has to be already defined as part of mesh data. By the end of the week the code updates were almost done and tested to get updates of Patch D632 ready for code review with a view to inclusion in Blender 2.72 release.

Development tasks

General tasks


Week 15: 7th-13th July

Freestyle for Cycles

This week most work hours were spent for addressing the design issues related to Freestyle line rendering for Cycles as documented in the last weekly report.

As to the issue of material color/alpha/thickness modifiers, a new per-material line color property was introduced. This line color property is available regardless of rendering engines so as to provide a reliable standard way for material-based stylization of Freestyle stokes.

For what concerns the texture UI design issue, it was decided to implement a node-based texturing framework, instead of relying on the conventional texture mapping and influence panels. Specifically, line styles were extended to include a shader node tree for defining textures that will be mapped onto strokes. The output of the node tree is a Line Style Output shader node which gives Freestyle access to colors and alpha transparency of the textures as well as influence factors for mapping to the base color and transparency of Freestyle strokes. The core part of line style shader nodes was finished by the end of the week.

Development tasks

General tasks
Fixes (unreported)
Patch review
  • D623: Freestyle Python API: Updates and speedups for the parameter editor


Week 14: 30th June-6th July

Freestyle for Cycles

The initial patch set of Freestyle for Cycles was finalized and extensively tested. In the meantime, investigations of Cycles' integration into Blender were continued to address a design issue related to a proper support of material colors and textures. There are two related problems on the Freestyle side.

One is concerned with Freestyle's builtin Material color/alpha/thickness modifiers. These modifiers allow users to modify line color and other line properties based on materials' diffuse color, alpha transparency and so forth. In the Blender Internal (BI), these material properties are static (unless nodes are in use) and fairly easy for Freestyle to retrieve their values. In Cycles, however, most material properties are embedded in shader node trees and are difficult to retrieve relevant values from within Freestyle.

The other issue concerns textured strokes. Freestyle relies on the legacy texture mapping and influence panels for the BI to allow users to stylize textured strokes. In Cycles, textures are first defined in shader node trees, and the textures' properties then appear in Cycles-specific option panels in the UI. It seems that a fixed set of UI components (e.g., based on texture slots) is suitable for stroke texturing in Freestyle since stroke rendering is done by generating on the fly a temporary scene which users will never see and interact with. These contradictory UI requirements make UI design for Freestyle textured strokes uneasy.

The code reading during the week concluded that evaluating shader node trees outside the Cycles render pipeline is not easy and hence Freestyle won't be capable of information retrieval from node-based materials any soon. The texture UI issue also requires further development. Different approaches to a proper support of material colors and textures in Freestyle for Cycles will be studied in the next week.

The work-in-progress patch set D632 for Freestyle line rendering in Cycles was posted to the bf-blender-npr mailing list with the aim to call for testers (link to the posted message).

Development tasks

Fixes (reported)
Fixes (unreported)
Patch submission
  • D632: Freestyle line rendering in Cycles


Week 13: 23rd-29th June

New targets for Blender 2.72 release

Discussions with Blender NPR stakeholders were held on the bf-blender-npr mailing list, and new development targets for the next Blender 2.72 release were selected as shown below in the descending order of priority:

  1. Freestyle performance tuning for space and time.
  2. Freestyle integration into Cycles.
  3. Adding Z depth information to rendered Freestyle lines.
  4. built-in SVG export.

As stated in the summary message posted to the mailing list, "The first item takes the highest priority since that is a specific request from the Gooseberry project which is going to use Freestyle for film production. However, performance tuning efforts may just fail and there is no guarantee of a success, so I will try to make sure some of the other targets will be delivered to 2.72 so that the funded project will be justified by deliverables visible to end users."

Freestyle for Cycles

For the aforementioned reasons, this week's development focus was put on Freestyle integration into Cycles. By the end of the week a working version of Freestyle for Cycles was developed, where the Blender Internal (BI) is used for Freestyle line rendering. An attempt to use Cycles for that purpose was also made, which turned out to be successful to some extent. Specifically, most line stylization options are available even when Cycles are used for stroke rendering, but a proper support for material colors and textures is missing because Freestyle is not capable of accessing node-based material setups. Further code refinements and investigations of Cycles shader nodes are foreseen in the next week.

Development tasks

General tasks
Fixes (unreported)

Week 12: 15th-22nd June

Degenerate triangles

Bug hunting efforts were continued from Week 11 and hours were spent for focused development of the edge traversal algorithm for Freestyle intended to address incorrect face normals due to degenerate triangles coming from Ngons. Initial coding and tests have been done, although the algorithm development needs further fixes and tuning.

Non-ASCII, MBCS-compatible paths on Windows

In the meantime, some hours were used to improve support for non-ASCII paths with characters of a multi-byte character set (MBCS) on Windows. A few related patches (D603, D604, and D605) were submitted for code review. With all these patches applied, Blender can start from a path with non-ASCII characters on Windows when the system locale is set to an MBCS code page (such as Chinese, Japanese and Korean). The patches are still under review.

Development tasks

General tasks
Fixes (unreported)
Fixes (reported)
Patch review
  • D319: Freestyle Python scripts update
Patch submission
  • D603: Better support for loading OCIO configuration from a path with non-ASCII chars on Windows
  • D604: Fix for incomplete retrieval of system/user resource paths due to a Blender installation path with non-ASCII chars
  • D605: Fixes for proper handling of wchar_t paths in MinGW


Week 11: 9th-15th June

Bug fixes continued

The week started with the BCon4 phase of the Blender 2.71, so most work hours were spent for bug fixes. A patch for fixing T40065 was submitted as patch D594 (still under review).

Also a relatively old bug report T40163 was further investigated. The problem is that Ngons tend to have degenerate triangles when tessellated and cause unwanted lines in Freestyle renders. An issue coming from degenerate faces is incorrect face normals (no way to reliably compute it since the area of a degenerate face nearly equals to zero). To address the face normal issue, a new idea has been developed. Basically degenerate faces cause mesh edges overlapping with each other. The idea is then to traverse overlapping edges and identify a non-degenerate face that is "visually adjacent" to a degenerate face. If such a non-degenerate adjacent face is found, then its face normal is used as that of the degenerate face. Hours were spent for the development of the edge traversal algorithm.

Development tasks

Patch review
  • D319: Freestyle Python scripts update
Patch submission
  • D594: Fix T40065: Pressing Esc in separate render result window does not focus main window


Week 10: 2nd-8th June

Bug fixing continued

Most of work hours were spent for bug fixing and related actions. A highlight of this week is the fix for viewport render not updating with changes of Freestyle settings (269b14f184bc). Now that all parameter changes in the Freestyle GUI will be immediately visualized in the view port render, this is going to be the most intuitive way for artists to try out different line stylization options in Freestyle starting from Blender 2.71.

Some hours were also spent to look into the open issue T40163 concerning unwanted Freestyle lines due to degenerate faces coming from Ngons. In-depth discussions in the task T40163 explored different approaches (including an experimental patch of mine) to fix the issue, but none of them turned out to be a general solution. It is my impression that degenerate faces coming from Ngons should be addressed in the first place through a better tessellation algorithm. Addressing degenerate faces much later in Freestyle is a very tricky exercise.

Additional efforts were directed to patch review so as to be able to close associated open tasks as soon as the Blender 2.71 has been out:

  • Patch D319: Freestyle Python scripts update (T37565: Freestyle API changes and further scripting integration).
  • Patch D545: Freestyle Python API: new methods for Stroke and StrokeVertexIterator (T37839: Iterator incremented() and decremented() methods)

RGB-to-grayscale conversion schemes

A bug fix for a wrong formula used for RGB to grayscale conversion (de280ffa32e4) raised a concern (again) that Blender has multiple RGB-to-grayscale conversion schemes, and different methods are used here and there for some unknown reasons. This seems a bigger issue than it appears that needs to be addressed from a general perspective of color management in Blender.

Development tasks

Fixes (unreported)
Patches
  • D545: Freestyle Python API: new methods for Stroke and StrokeVertexIterator.


Week 9: 26th May-1st June

Bug hunting continued

Still in BCon4, bug hunting efforts were continued to reduce the number of open bugs in the Blender bug tracker. A couple of days in the beginning of the week were spent for addressing the issue T40315: Boolean modifier with Freestyle edges. After many hours of code reading about boolean and subsurf modifiers as well as the depsgraph, a patch set D558 was proposed to fix the issue. Discussions with Sergey showed that the proposed fix was trying to address a bigger problem in the depsgraph, so that a different approach focusing only on the Freestyle stuff was taken in the end.

Development tasks

Fixes (reported)
Fixes (unreported)


Week 8: 19th-25th May

Bug hunting

Because of the BCon4 phase in the Blender release cycle, most hours were specifically spent for bug fixes.

One of old Freestyle bugs was addressed. The problem was that visible lines may suffer from sudden thinning of stroke width at intersections with background hidden lines. A description of the problem is found in the comment #19 of T36425. Since initial attempts to properly fix the issue were unsuccessful, a temporary solution was introduced by an old commit in August 2013 (2a5b6d9c8f16). After many further attempts with a fresh look into the problem, this time the causes of the bug were finally identified in an algorithm that tries to prevent stroke vertices from overlapping at the same coordinates (this kind of singularity may become annoying sources of visual artifacts in stroke rendering). A partial fix was then done during this week.

Development tasks

General tasks
Fixes (reported)
Fixes (unreported)


Week 7: 12th-18th May

Freestyle Python API updates

As foreseen in the last weekly report, further Freestyle Python API updates were done with regard to collection property types. Specifically, conventional .new() and .remove() methods were added to collection types of line style modifiers and Python style modules.

The collection of Python style modules is an ordered list whose elements are processed from top to bottom. The order of Python style modules will determine the stacking order of lines drawn by Freestyle. Hence Freestyle provides a couple of operators to manipulate the place of modules in the list. It was then observed that the Blender Python API does not have a general way to re-order elements in a collection. This observation was confirmed by a discussion in the bf-python mailing list. It is still an open question as of this writing whether an element reordering method (like a .move() method) can be added to individual collection types or should be done at a higher level of the API. No decision was made in this regard at the moment.

Filled caps of 2D extruded curves

Many hours were then spent to address a problem report T39669. The original problem was a number of Freestyle warnings about edge duplicates in a 2D extruded curve, but a closer look into the issue showed that there was a bug in automatic curve-to-mesh conversion carried out in the beginning of rendering (a convincing visualization of the problem). The conversion output was inconsistent with that of manual curve-to-mesh conversion. After a lot of code reading and several attempts to fix the problem, a proposed fix D532 was reviewed and accepted.

Screen-space coordinates in the operator redo panel

Through personal communications a usability issue was identified and posted to the bf-committers mailing list. The problem is that since Blender 2.69 screen-space coordinates are not shown in the operator redo panel. For instance, the Weight Gradient tool has four parameters specifying the start and end points of a straight line segment in screen-space coordinates. These parameters were available in the redo panel up to Blender 2.68a, allowing artists to manually refine the line segment along which vertex weights are updated. No reply was offered to the post in the list. Additional actions are foreseen most likely after the upcoming Blender 2.71 release.

Development tasks

General tasks
Fixes (reported)
Fixes (unreported)


Week 6: 5th-11th May

Textured strokes in Freestyle

Since the patch for Freestyle textured strokes was merged into Git master, further testing and bug fixes were done in collaboration with the patch author Paolo Acampora.

The use of textured strokes in Python scripting was also investigated. Different implementations for providing access to line style texture slots in Python style modules were discussed with Paolo. An example Python style module was implemented to demonstrate the use of textured strokes in Python scripting.

An illustrated description of textured strokes and demo files were added to the Freestyle section of Blender 2.71 release notes.

Performance optimization

Based on a crash report through personal communications, an attempt was made to optimize memory requirements in Freestyle stroke rendering.

It is recalled that a stroke may consist of alternate visible and invisible segments. Previously temporary mesh objects were created for individual visible stroke segments. This could result in an excessive memory consumption in stroke rendering when strokes are composed of many short visible segments (for instance by means of dashed lines and/or blueprint geometry modifiers). Now mesh objects represent individual strokes instead of stroke segments, which tends to reduce the number of generated mesh objects by an order of magnitude.

Freestyle Python API improvements

Motivated by an online discussion, revisions of the Freestyle Python API have been started. The discussed problem was that the Freestyle Python API did not follow the general data creation/removal convention of the Blender Python API. Specifically, there was no easy and reliable way to add/remove a data element to/from the collection of line sets defined as part of scene render layer settings.

Now that Freestyle has been increasingly adopted, automated workflows by Python scripting are more likely. Hence Python API revisions towards Freestyle line rendering automation are considered an urgent task. As a first step, the aforementioned issue concerning the collection of line sets has been addressed. Further API revisions are foreseen in the next days.

Development tasks

General tasks
Fixes (reported)
Fixes (unreported)


Week 5: 28th April-4th May

Textured strokes in Freestyle

Many hours were spent for revisions of Patch D246 through personal communications with the patch author Paolo Acampora. Code development elements included:

  • Pinning of line style ID datablocks in the properties window.
  • Support for node-based textures in line styles.
  • Fix for visual artifact in the tail tip of strokes (due to a bug in the calculation of UV texture coordinates).
  • Fix for line style textures in the Outliner.

The patch set was reviewed by Brecht and me, and finally merged into Git master for inclusion in the upcoming Blender 2.71 release.

Preview rendering in the 3D viewport

A crash report T39941 related to Freestyle preview rendering in the 3D viewport was addressed by a fix in commit 182e97a2cd4b. Upon a comment to the fix, a detailed description was posted to document how the 3D viewport preview rendering works when primary and/or other scene render layers are deactivated. This led to a better solution of the observed preview rendering glitch (6ec2d72eca61).

Development tasks

Patches
Fixes (reported)


Week 4: 21st-27th April

Textured strokes in Freestyle

Patch D246 was revised on my side to address some bugs identified by independent tests. Some texture settings worked fine, while some other did not. Hours were spent for in-depth debugging and code revisions related to UV loops. A revised patch set was then sent to Paolo for evaluation and inclusion into D246. Additional UI fixes for Freestyle textured strokes were done independently on my side.

Also hours were spent for unsuccessful attempts to figure out the cause of an annoying issue that the texture preview window for Freestyle textured strokes was not properly updated when tabs in the Properties context window were switched (for example from Render Layers to Texture, and vice versa). This problem seems due to fact that the preview window is not in the Texture tab.

In the meantime, a request for UI design review was sent to the Blender UI team, and Brecht kindly offered prompt UI review comments. According to his suggestion, Freestyle texture settings will be moved to the Texture tab of the Properties window to keep the UI consistent with existing texture options in other parts of Blender.

Documentation

The Freestyle section of the Blender 2.71 release notes was worked out to document the new set of sorting options. Example renders were created to demonstrate the new features.

Link/Append workflows with Freestyle-enabled assets

A new discussion has been ongoing in the bf-blender-npr mailing list to address the issue that there is no easy way to Link/Append animation character assets together with Freestyle settings. Some thoughts were fed to the discussion to gather ideas for Blender/Freestyle improvements to address the issue.

Development tasks

General tasks
Fixes (reported)


Week 3: 14th-20th April

Freestyle demo at a meet-up in Tokyo

A local meet-up event was held on Monday, 14th April in Tokyo for 3D CG artists working on cel-look (cartoon) rendering and its applications. It was a small meeting of about 20 participants including professionals, students and amateurs. A demo of Freestyle for Blender was presented with the aim to showcase selected Freestyle applications (movie clips, still renders, and breakdown slides) and inform potential stakeholders of recent advances in the development of Freestyle and Blender NPR capabilities. The artists contributing to the demo included Light BWK (Malaysia), Lee Posey (USA) and mclelun (Malaysia). The demo turned out to be a big success, since many questions about the presented visual results and feature requests to Freestyle were asked during and after the demo session. This clearly indicates lots of enthusiasm for Freestyle and Blender emerged on the side of the presentation audience. The event was also quite motivating to me.

New options for sorting Freestyle lines

New options for sorting lines were added to line style IDs to arrange their stacking order in a render (f60a66f). These options give artists more control to determine which lines should be drawn on top of others.

Freestyle edge/face marks in the Outliner

A lot of code reading was done to address a known issue (not filed in the bug tracker) that Freestyle edge/face mark properties in Mesh data were not shown in the Outliner in the Datablocks display mode. The cause of the issue was missing RNA property definitions of these Freestyle-specific flags (cad4bfe). Now Freestyle edge/face marks can be keyframed through the outliner, as well as by means of keying sets.

Python scripting integration into Freestyle GUI

Some hours were also spent for code reading to investigate different options for better Python scripting integration into the Freestyle interactive GUI in Blender. The idea is to allow artists to write Python expressions to build custom line styles. Two solutions were analyzed:

  • A name space is introduced to register user-defined style components (predicates, functions and stroke shaders) written in Python. The registered components are then used in Python expressions embedded in line styles. This approach is in line with Python drivers for animation (user-defined functions and variables are added to bpy.app.driver_namespace).
  • bpy.utils.register_class() is used to make user-defined style components accessible from within line styles. In this case, base classes for defining predicates, functions and stroke shaders have to be exposed as RNA types that can be derived by inheritance and registered to the bpy.types namespace.

More API design work is foreseen during the project.

Development tasks

General tasks
Fixes (unreported)


Week 2: 7th-13th April

Discussions in the bf-blender-npr mailing list

The proposal document was transformed into a personal Wiki page (wiki.blender.org) to inform general audience with the planned development work. An announcement was sent to the bf-blender-npr mailing list to make people aware of this project.

Discussions were started in the bf-blender-npr mailing list to check priority tasks in the planned Freestyle development and talk about ideas of Freestyle improvements. Preliminary coding was done to show a proof-of-concept implementation of ideas that came up through the discussions.

  • Crease angle dependent line thickness. The idea is to determine crease line thickness as a function of the angle between the two faces on both sides of the crease line. A quick video clip (vimeo.com/91306354) was made to demonstrate the idea.
  • Curvature dependent line thickness. Another Freestyle issue discussed in detail was sudden vanishing and appearance of contour lines along with camera movement. This kind of visual artifact leads to a distraction from the animation flow. It was agreed that what we want was a real number that quantifies the closeness of a contour to a vanishing point. We came to the idea of using radial curvatures to address this problem. An experimental line thickness shader was then implemented and a quick test video clip (vimeo.com/91383521) was created to prove the concept.

The implemented experimental code is presented in a blog post. These features are expected to be part of future Freestyle development (likely to be targets for the 2.72 release).

Development tasks

General tasks
  • Problem report T39669 revealed a data inconsistency between manual and render-time curve-to-mesh conversion (the latter occurs in Freestyle). Additional investigation was asked to Campbell, since the issue is related to different ways of curve-to-mesh conversion and not directly to Freestyle.
Patch review
  • Patch D246: Texture Marks for freestyle strokes.
Fixes (unreported)


Week 1: 1st-6th April

Freestyle performance improvements

To start with the planned development for improved Freestyle performance, initial attempts were made to reduce memory consumption during Freestyle line rendering.

It is remarked that Freestyle extensively uses double-precision floating-point numbers for internal data structures. Hence, initial code updates were intended to achieve reduced memory consumption by using float (instead of double) for internal data elements.

Simple performance tests showed that the use of float led to a 10% reduction of memory consumption when compared with that of the 2.70 release, but in the case of a test model, the rendering time got approximately a 20% increase. The cause of this slow down was traced to a failure of inverse perspective projection transformation (IPPT) from 2D to 3D. Since both data elements and operations on them were in single precision, Freestyle was more prone to numerical errors due to rounding.

It is noted that Freestyle involves a lot of geometry calculations in the 2D image coordinate system whose extent is defined by the dimensions of the image being rendered. When the render size is large (e.g., 5000-by-5000 pixels), 2D vertex coordinates are likely to suffer of insufficient sub-pixel precision during geometry calculations since single-precision floating-point values have at most 7 significant decimals.

Further code updates were done to use double precision for the IPPT algorithm, which turned out to work fine in most cases. The rendering time is now comparable with the 2.70 release. There are a few cases where IPPT fails. This remaining problem needs to be further addressed.

Course material review

An international team of Blender artists is working on a self-tutoring course on line art with Freestyle and Blender. The course consists of 15 stages covering Freestyle basics, all aspects of the interactive GUI controls, and advanced topics. The course material is full of Freestyle tips and pieces of advice for newcomers.

The course authors asked me to review the recorded audio of course scripts. The audio material for all the 15 stages was duly reviewed from a technical perspective, and a few remarks on the audio and written scripts were sent back to the authoring team.

Development tasks

Fixes (unreported)
Retrieved from "https://wiki.blender.org/index.php/User:Kjym3/DevFundProject/2014"

Contents