Freestyle getting stuck on view map creation + memory leaks #35245

New Issue

Antonis Ryakiotakis · 2013-05-07T10:12:06+02:00

2013-05-07 10:12:06 +02:00

%%%--- Operating System, Graphics card ---
Windows 7 - ubuntu 13.04 Geforce GT 540M

- Blender version with error, and version that worked ---

r56521 is buggy

- Short description of error ---

Blender stops at view map creation when rendering. This is no hang, it can be exited with escape but processing does not proceed. If the renderability of the visible plane is toggled off, a hard crash occurs (tested on Windows only)

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Press render on attached file.
%%%

%%%--- Operating System, Graphics card --- Windows 7 - ubuntu 13.04 Geforce GT 540M - Blender version with error, and version that worked --- r56521 is buggy - Short description of error --- Blender stops at view map creation when rendering. This is no hang, it can be exited with escape but processing does not proceed. If the renderability of the visible plane is toggled off, a hard crash occurs (tested on Windows only) - Steps for others to reproduce the error (preferably based on attached .blend file) --- Press render on attached file. %%%

Antonis Ryakiotakis commented

2013-05-07 10:12:06 +02:00

Changed status to: 'Open'

Brecht Van Lommel commented

2013-05-07 13:00:50 +02:00

%%%Confirmed. Looks like Freestyle has some problems with very small faces, the scale of these objects is animated to make them disappear.%%%

Tamito Kajiyama commented

2013-05-19 03:08:17 +02:00

%%%Made an attempt to fix the reported problems in the trunk revision 56905. Indeed there were two issues:

Line visibility computations are very slow in the case of the provided .blend file, which gave an impression that the rendering process got stuck. The slowness can be explained by a data structure used for the line visibility computations, together with a specific mesh distribution of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system to divide tris/quads into small groups in order to accelerate the line visibility computations. On the other hand, the test scene is populated by a big plane (made of one quad) and a moderately detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the tris concentrate in one grid cell, so essentially there is no performance gain from the grid data structure intended for speed optimization. It looks like a better grid data structure (possibly based on adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now the progress bar of Blender is employed to better inform users of the amount of work done in the line visibility computations.
A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid data structure are determined based on the average area of mesh faces in the given scene. When the big plane in the test scene is excluded from the rendering, the average area is almost zero (on the order of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very large number, causing a fatal memory allocation error. The present revision has introduced a hard upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.

It would be appreciated if you could test the fixes on your side. The development of a faster line visibility algorithm is kept as a future to-do item for now.%%%

%%%Made an attempt to fix the reported problems in the trunk revision 56905. Indeed there were two issues: - Line visibility computations are very slow in the case of the provided .blend file, which gave an impression that the rendering process got stuck. The slowness can be explained by a data structure used for the line visibility computations, together with a specific mesh distribution of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system to divide tris/quads into small groups in order to accelerate the line visibility computations. On the other hand, the test scene is populated by a big plane (made of one quad) and a moderately detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the tris concentrate in one grid cell, so essentially there is no performance gain from the grid data structure intended for speed optimization. It looks like a better grid data structure (possibly based on adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now the progress bar of Blender is employed to better inform users of the amount of work done in the line visibility computations. - A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid data structure are determined based on the average area of mesh faces in the given scene. When the big plane in the test scene is excluded from the rendering, the average area is almost zero (on the order of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very large number, causing a fatal memory allocation error. The present revision has introduced a hard upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability. It would be appreciated if you could test the fixes on your side. The development of a faster line visibility algorithm is kept as a future to-do item for now.%%%

Tamito Kajiyama commented

2013-05-22 01:46:32 +02:00

Changed status from 'Open' to: 'Resolved'

Tamito Kajiyama closed this issue

2013-05-22 01:46:32 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Freestyle getting stuck on view map creation + memory leaks #35245