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 the present
data structures used for the line visibility computations, together with the 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 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 optimized for speed. 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.
This means main database is no longer pollutes with
temporary scene and objects needed for freestyle
render.
Actually, there're few of separated temporary mains
now. Ideally it's better to use single one, but it's
not so much trivial to pass it to all classes. Not
so big deal actually.
Required some changes to blender kernel, to make it
possible to add object to a given main, also to
check on mesh materials for objects in given main.
This is all straightforward changes.
As an additional, solved issue with main database
being infinitely polluted with text blocks created
by create_lineset_handler function.
This fixes:
- #35003: Freestyle crashes if user expands objects in FRS1_Scene
- #35012: ctrl+f12 rendering crashes when using Freestyle
A crash in the Freestyle renderer was reported by Ton on IRC with a stack trace
below. Note that #2 is in Freestyle, whereas #1 is in the compositor. The problem
was observed in a debug build on OS X 10.7 (gcc 4.2, openmp disabled, no llvm).
----------------------------------------------------------------------
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 72386 thread 0xf303]
0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
43 delete (this->m_outputsockets.back());
Current language: auto; currently c++
(gdb) where
#0 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
#1 0x0000000100c29066 in Node::~Node (this=0x10e501c80) at COM_Node.h:49
#2 0x000000010089c273 in NodeShape::~NodeShape (this=0x10e501c80) at NodeShape.cpp:43
#3 0x000000010089910b in NodeGroup::destroy (this=0x10e501da0) at NodeGroup.cpp:61
#4 0x00000001008990cd in NodeGroup::destroy (this=0x10e5014b0) at NodeGroup.cpp:59
#5 0x00000001008990cd in NodeGroup::destroy (this=0x114e18da0) at NodeGroup.cpp:59
#6 0x00000001007e6602 in Controller::ClearRootNode (this=0x114e19640) at Controller.cpp:329
#7 0x00000001007ea52e in Controller::LoadMesh (this=0x114e19640, re=0x10aba4638, srl=0x1140f5258) at Controller.cpp:302
#8 0x00000001008030ad in prepare (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:302
#9 0x000000010080457a in FRS_do_stroke_rendering (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:600
#10 0x00000001006aeb9d in add_freestyle (re=0x10aba4638) at pipeline.c:1584
#11 0x00000001006aceb7 in do_render_3d (re=0x10aba4638) at pipeline.c:1094
#12 0x00000001006ae061 in do_render_fields_blur_3d (re=0x10aba4638) at pipeline.c:1367
#13 0x00000001006afa16 in do_render_composite_fields_blur_3d (re=0x10aba4638) at pipeline.c:1815
#14 0x00000001006b04e4 in do_render_all_options (re=0x10aba4638) at pipeline.c:2021
----------------------------------------------------------------------
Apparently a name conflict between the two Blender modules is taking place.
The present commit hence intends to address it by putting all the Freestyle C++
classes in the namespace 'Freestyle'. This revision will also prevent potential
name conflicts with other Blender modules in the future.
Special thanks to Lukas Toenne for the help with C++ namespace.
on the console during Freestyle rendering. The debug prints are turned off
by default now. Errors are still printed on the console.
A patch set implementing this functionality was provided by Bastien Montagne.
Many thanks! :)
This commit is meant to improve the response of the ESC key for stopping Freestyle rendering
throughout the rendering process. The rendering with Freestyle consists of several steps
including: (1) mesh data loading, (2) winged edge construction, (3) silhouette edge detection,
(4) view map construction, and (5) stroke drawing. All these steps have been extended to
frequently check if the ESC key is pressed, so that users can abort time-consuming rendering
at any point of time.
Conflicts resolved:
source/blender/blenkernel/intern/material.c
source/blender/blenkernel/intern/subsurf_ccg.c
source/blender/blenloader/intern/readfile.c
source/blender/editors/animation/anim_channels_defines.c
source/blender/makesrna/intern/rna_scene.c
Additional changes:
* Fix for recent changes of BKE_* function renaming.
* Fix for an "attempt to free NULL pointer" in BlenderStrokeRenderer::RenderStrokeRepBasic().
* View map calculation has been intensively optimized for speed by
means of:
1) new spatial grid data structures (SphericalGrid for perspective
cameras and BoxGrid for orthographic cameras; automatically switched
based on the camera type);
2) a heuristic grid density calculation algorithm; and
3) new line visibility computation algorithms: A "traditional"
algorithm for emulating old visibility algorithms, and a "cumulative"
algorithm for improved, more consistent line visibility, both exploiting
the new spatial grid data structures for fast ray casting.
A new option "Raycasting Algorithm" was added to allow users to choose
a ray casting (line visibility) algorithm. Available choices are:
- Normal Ray Casting
- Fast Ray Casting
- Very Fast Ray Casting
- Culled Traditional Visibility Detection
- Unculled Traditional Visibility Detection
- Culled Cumulative Visibility Detection
- Unculled Cumulative Visibility Detection
The first three algorithms are those available in the original
Freestyle (the "normal" ray casting was used unconditionally, though).
The "fast" and "very fast" ray casting algorithms achieve a faster
calculation at the cost of less visibility accuracy.
The last four are newly introduced optimized options. The culled
versions of the new algorithms will exclude from visibility
calculation those faces that lay outside the camera, which leads to a
faster view map construction. The unculled counterparts will take all
faces into account. The unculled visibility algorithms are useful
when culling affects stroke chaining.
The recommended options for users are the culled/unculled cumulative
visibility algorithms. These options are meant to replace the old
algorithms in the future.
Performance improvements over the old algorithms depend on the scenes
to be rendered.
* Silhouette detection has also been considerably optimized for speed.
Performance gains by this optimization do not depend on scenes.
* Improper handling of error conditions in the view map construction
was fixed.
The PseudoNoise class for generating a series of noise values had a bug
involving a signed integer overflow when renders were at high image resolution.
This caused the noise generator to yield very large noise values, putting
strokes out of the renders' image boundary.
Parameter Editor mode. This is a WIP commit. Only the base line
color, base alpha transparency, and base line thickness are respected.
More additions are anticipated to account for other parameters.
* Added FRS_finish_stroke_rendering() to clean Freestyle-related
temporary resources after stroke rendering.
* Some functions in FRS_freestyle.cpp are now declared as static
functions, so as not to mess up the program-wide name space.
* Made the StyleModule class inheritable, and defined new subclass
BlenderStyleModule that takes a Text object instead of a file name.
initializing Freestyle and specifying contexts, making the API a bit messy.
Now FRS_initialize() is only for initialization, and contexts are specified
by new FRS_set_context() function just before starting rendering.
- proper Freestyle initialization, with support for undo/redo
- re-added FreestyleStyleConfig data structure
- Freestyle Python interpreter updated
This commit should compile without errors. More work is necessary to complete the migration:
- add Freestyle in the UI
- set up RNA support
propagation up to the toplevel error handler in BPY_txt_do_python_Text().
Before these changes were made, the operator() methods of predicates
and functions, for example, returned a value of various types such as
bool, double and Vec2f. These returned values were not capable to
represent an error state in many cases.
Now the operator() methods always return 0 on normal exit and -1 on
error. The original returned values are stored in the "result" member
variables of the predicate/function classes.
This means that if we have a code fragment like below:
UnaryPredicate1D& pred;
Interface1D& inter;
if (pred(inter)) {
/* do something */
}
then we have to rewrite it as follows:
UnaryPredicate1D& pred;
Interface1D& inter;
if (pred(inter) < 0)
return -1; /* an error in pred() is propagated */
if (pred.result) {
/* do something */
}
Suppose that pred is a user-defined predicate in Python, i.e. the predicate
is likely error-prone (especially when debugging the predicate). The first
code fragment shown above prevents the proper error propagation because
the boolean return value of UnaryPredicate1D::operator() cannot inform the
occurrence of an error to the caller; the second code fragment can.
In addition to the operator() methods of predicates and functions, similar
improvements have been made to all other C++ API functions and methods that
are involved in the execution of user-defined Python code snippets. Changes
in the signatures of functions and methods are summarized as follows (note
that all subclasses of listed classes are also subject to the changes).
Old signatures:
virtual void Iterator::increment();
virtual void Iterator::decrement();
virtual void ChainingIterator::init();
virtual ViewEdge * ChainingIterator::traverse(const AdjacencyIterator &it);
static void Operators::select(UnaryPredicate1D& pred);
static void Operators::chain(ViewEdgeInternal::ViewEdgeIterator& it,
UnaryPredicate1D& pred, UnaryFunction1D_void& modifier);
static void Operators::chain(ViewEdgeInternal::ViewEdgeIterator& it,
UnaryPredicate1D& pred);
static void Operators::bidirectionalChain(ChainingIterator& it,
UnaryPredicate1D& pred);
static void Operators::bidirectionalChain(ChainingIterator& it);
static void Operators::sequentialSplit(UnaryPredicate0D& startingPred,
UnaryPredicate0D& stoppingPred, float sampling = 0);
static void Operators::sequentialSplit(UnaryPredicate0D& pred, float sampling = 0);
static void Operators::recursiveSplit(UnaryFunction0D<double>& func,
UnaryPredicate1D& pred, float sampling = 0);
static void Operators::recursiveSplit(UnaryFunction0D<double>& func,
UnaryPredicate0D& pred0d, UnaryPredicate1D& pred, float sampling = 0);
static void Operators::sort(BinaryPredicate1D& pred);
static void Operators::create(UnaryPredicate1D& pred, vector<StrokeShader*> shaders);
virtual bool UnaryPredicate0D::operator()(Interface0DIterator& it);
virtual bool BinaryPredicate0D::operator()(Interface0D& inter1, Interface0D& inter2);
virtual bool UnaryPredicate1D::operator()(Interface1D& inter);
virtual bool BinaryPredicate1D::operator()(Interface1D& inter1, Interface1D& inter2);
virtual void StrokeShader::shade(Stroke& ioStroke) const;
virtual T UnaryFunction0D::operator()(Interface0DIterator& iter);
virtual T UnaryFunction1D::operator()(Interface1D& inter);
New signatures:
virtual int Iterator::increment();
virtual int Iterator::decrement();
virtual int ChainingIterator::init();
virtual int ChainingIterator::traverse(const AdjacencyIterator &it);
static int Operators::select(UnaryPredicate1D& pred);
static int Operators::chain(ViewEdgeInternal::ViewEdgeIterator& it,
UnaryPredicate1D& pred, UnaryFunction1D_void& modifier);
static int Operators::chain(ViewEdgeInternal::ViewEdgeIterator& it,
UnaryPredicate1D& pred);
static int Operators::bidirectionalChain(ChainingIterator& it,
UnaryPredicate1D& pred);
static int Operators::bidirectionalChain(ChainingIterator& it);
static int Operators::sequentialSplit(UnaryPredicate0D& startingPred,
UnaryPredicate0D& stoppingPred, float sampling = 0);
static int Operators::sequentialSplit(UnaryPredicate0D& pred, float sampling = 0);
static int Operators::recursiveSplit(UnaryFunction0D<double>& func,
UnaryPredicate1D& pred, float sampling = 0);
static int Operators::recursiveSplit(UnaryFunction0D<double>& func,
UnaryPredicate0D& pred0d, UnaryPredicate1D& pred, float sampling = 0);
static int Operators::sort(BinaryPredicate1D& pred);
static int Operators::create(UnaryPredicate1D& pred, vector<StrokeShader*> shaders);
virtual int UnaryPredicate0D::operator()(Interface0DIterator& it);
virtual int BinaryPredicate0D::operator()(Interface0D& inter1, Interface0D& inter2);
virtual int UnaryPredicate1D::operator()(Interface1D& inter);
virtual int BinaryPredicate1D::operator()(Interface1D& inter1, Interface1D& inter2);
virtual int StrokeShader::shade(Stroke& ioStroke) const;
virtual int UnaryFunction0D::operator()(Interface0DIterator& iter);
virtual int UnaryFunction1D::operator()(Interface1D& inter);
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
- getExactTypeName()
- increment()
- decrement()
- isBegin()
- isEnd()
Contrary to previously stated, I am reverting back to implementing iterators in the (Python) API, for different reasons:
- it will make testing quicker to achieve, as I won't have to recode a big chunk of the original Python files
- it will be a base for API refactoring
- it won't prevent the use a list-based approach later (it is simple to get it from the Iterator)
I also corrected a simple GLStrokeRenderer bug for texture loading (not in original Freestyle code). Apparently, IMB_loadiffname doesn't recognize the paper's texture depth so a work-around will have to be found.
I analyzed the crash with gdb and PyImport_AddModule ("__main__") in Python/import.c:320 seems responsible for the crash: apparently, "__main__" is not found and causes the error "No such file or directory".
I have to figure out what's wrong with the current configuration, especially whether Freestyle's PythonInterpreter can be used as is. I am going to see whether it's just quicker to use Blender's functions.
1. instantiates the config path, the controller and the view
2. sets the controller’s view
3. loads a 3ds file (right now a fixed file)
4. inserts a style module (right now, also fixed)
5. computes the view map
The next and final step is running the Python script. A lot of information are fixed and should be changed to test the following code: see source/blender/freestyle/app_blender/*.cpp and search for fixed paths (starting in /Users/).
I am currently evaluating whether it's worth making Python run on its own environment (right now, the program crashes because of PyImport_AddModule) or whether it should use Blender's Python capabilities. Also, I need to figure out how to integrate the SWIG wrapper dynamic library into the current scheme.
