| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
this can be added back on case-by-case basis, but better not assume ownership of another projects work by default.
|
|
|
|
again!
|
|
Reported by Bastien Montagne, thanks!
|
|
of _POSIX_C_SOURCE and _XOPEN_SOURCE. There are no functional changes.
Tested with GCC 4.4.1 on Ubuntu 9.10 (karmic).
|
|
orientedViewEdgeIterator.
* Simplified Python-related error handling in C++ class definitions.
The definitions of the following C++ methods were simplified and most
code segments using the C/Python API were moved to Director.cpp.
ChainingIterator::init()
ChainingIterator::traverse()
UnaryPredicate0D::operator()()
UnaryPredicate1D::operator()()
BinaryPredicate0D::operator()()
BinaryPredicate1D::operator()()
UnaryFunction0D::operator()()
UnaryFunction1D::operator()()
StrokeShader.shade()
* Moved part of the introspection-based automatic type conversion code
from BPy_Interface0DIterator.cpp and Director.cpp to BPy_Convert.cpp
for the sake of better code organization.
* Fixed an uninitialized member in StrokeVertexIterator___init__().
|
|
AdjacencyIterator::isBegin() and AdjacencyIterator::isEnd() always
returned a False value and printed a "not implemented" warning message.
This caused an infinite loop in a few chaining iterators, resulting in
a crash of the program. The origin of the issue seemed to be a fact
that in the C++ layer, the AdjacencyIterator class had not properly
overloaded the definitions of the methods in the Iterator superclass.
The fix here looks okay, although I'm not sure why this inconsistency
was not addressed for a long time.
|
|
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);
|
|
polymorphism for the following classes: BinaryPredicate0D (__call__), BinaryPredicate1D (__call__), UnaryPredicate0D (__call__), UnaryPredicate1D (__call__), StrokeShader (shade), ChainingIterator (init, traverse).
Other methods could easily be supported in the future. The method now works as planned for the contour style. For style modules with Python shaders, there still is a problem that I will fix right away.
|
|
SShape, ViewShape. Also corrected a few typos (Get#->get#).
|
|
Freestyle (on the C++ side). Created the equivalent in Python BPy_Iterator with the simple interface:
- 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)
|
|
source/blender/freestyle
|
