Age | Commit message (Collapse) | Author |
|
|
|
|
|
Blender 2.5. As of I right now, Freestyle is back in the UI, but rendering still fails because of the texture manager.
|
|
|
|
|
|
source/freestyle/intern/blender_interface folder
|
|
|
|
|
|
|
|
- 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
|
|
|
|
Other parts outside source/blender/freestyle/ seem to have been overriden in
the merge r23341 (by just using trunk version?), so it probably does not build
or builds without Freestyle. source/blender/CMakeLists.txt does not make any
reference to freestyle/, for example.
|
|
some Freestyle-related pointers, which led to a crash when the
rendering was initiated or the Freestyle panel (in the Scene buttons)
was redrawn.
|
|
text object storing a Python script was not properly freed when an
error occurred during the execution of the script.
|
|
|
|
|
|
|
|
|
|
The main contribution of this commit is the possibility to save Freestyle configuration information inside .blend files. It required an extensive refactoring of the previous interface code.
The code has been tested and does not crash on my machine. If you encounter issues, please let me know (and if possible, sending me an sample .blend file).
DETAILS:
- refactored code to notify Freestyle when adding/removing render layers (FRS_freestyle_config.{h,cpp})
- corrected the freeing of style modules when files are read from / written to disk
- moved Freestyle configuration information into scene renderlayers, to allow loading / saving .blend files (DNA_scene_types.h DNA_freestyle_types.h FRS_freestyle.cpp)
- inserted temporary trick to prevent crashes when orthographic camera is used (SilhouetteGeomEngine.cpp), but outputting incorrect feature line calculations
|
|
Functions, and StrokeShader types.
|
|
There was a known issue for a long time that we occasionally encountered
strange "TypeError: an integer is required" and "RuntimeWarning: tp_compare
didn't return -1 or -2 for exception", as shown in the following unit test
log. The source of the former error was PyInt_AsLong(obj) being used by
IntegrationType_from_BPy_IntegrationType(obj), where "obj" was not properly
initialized in "__init__" before the converter was called. The TypeError
was left unattended for a while and showed up when a comparison occurred
and the TypeError was detected, which resulted in the latter warning.
> runTest (__main__.UnaryFunction1DDoubleInitTestCase) ...
> .\blender:211: RuntimeWarning: tp_compare didn't return -1 or -2 for exception
> ERROR
>
> ======================================================================
> ERROR: runTest (__main__.UnaryFunction1DDoubleInitTestCase)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "init_tests.py", line 211, in runTest
> TypeError: an integer is required
>
> ----------------------------------------------------------------------
* Also removed unnecessary error messages in "__init__" methods of
UnaryFunction1D types.
|
|
types: Interface0D, SVertex, ViewVertex, StrokeVertex, NonTVertex,
and TVertex.
|
|
Removed all castToSomething() methods from Interface0D's subclasses.
These methods are useless, because introspection-based automatic type
conversion takes place whenever it is applicable.
If you need to rewrite old style modules that rely on the cast methods,
apply the following rewriting rules:
- SVertex.castToSVertex()
- TVertex.castToViewVertex()
- TVertex.castToTVertex()
- NonTVertex.castToViewVertex()
- NonTVertex.castToNonTVertex()
These 5 methods return an object itself, so just removing a method
call will suffice. If you need to handle objects in a different way
depending on their types, then you can use Python's type checking
idioms such as "type(obj) is T" and "isinstance(obj, T)". Example:
[Original]
v = it.getObject()
# try to convert v into a TVertex object
vertex = v.castToTVertex()
if vertex != None:
... # do something on the TVertex object
# try to convert v into a NonTVertex object
vertex = v.castToNonTVertex()
if vertex != None:
... # do something on the NonTVertex object
[Rewritten]
vertex = it.getObject()
if type(vertex) is TVertex:
... # do something on the TVertex object
elif type(vertex) is NonTVertex:
... # do something on the NonTVertex object
- SVertex.castToViewVertex()
- SVertex.castToTVertex()
- SVertex.castToNonTVertex()
Use SVertex.viewvertex() instead. You don't need to care about
which cast method is appropriate. SVertex.viewvertex() does, if
necessary, introspection-based automatic type conversion for you.
- NonTVertex.castToSVertex()
Use NonTVertex.svertex() instead.
- CurvePoint.castToSVertex()
Let cp be a CurvePoint object, then this method can be expressed as
follows:
if cp.t2d() == 0.0:
return cp.A() # returns an SVertex
elif cp.t2d() == 1.0:
return cp.B() # returns an SVertex
return None
- CurvePoint.castToViewVertex()
- CurvePoint.castToTVertex()
- CurvePoint.castToNonVertex()
Similarly, these 3 methods can be expressed as follows:
if cp.t2d() == 0.0:
return cp.A().viewvertex()
elif cp.t2d() == 1.0:
return cp.B().viewvertex()
return None
|
|
|
|
* Fixed refcount issues in diffuse(), specular(), ambient() and
emission() methods. Also changed the type of their returned values
from list to tuple.
|
|
* Added to python/BPy_Convert.{cpp,h} 4 utility converters below for
better introspection-based automatic type conversion.
PyObject * Any_BPy_Interface0D_from_Interface0D( Interface0D& if0D );
PyObject * Any_BPy_Interface1D_from_Interface1D( Interface1D& if1D );
PyObject * Any_BPy_FEdge_from_FEdge( FEdge& fe );
PyObject * Any_BPy_ViewVertex_from_ViewVertex( ViewVertex& vv );
There are 4 corresponding converters without the "Any_" prefix. All
calls of them in the code base were replaced with these new converters
so that the introspection-based automatic conversion would take place
universally.
* python/BPy_Convert.{cpp,h}: Those C++ to Python converters having
had a "_ptr" suffix were renamed to a name without the suffix, and
their arguments were changed so as to take a reference (e.g.,
ViewVertex&) instead of a pointer (e.g., ViewVertex *). The changed
converters and their new function prototypes are listed below. These
converters now return a Python wrapper object that retains the passed
reference, instead of retaining a newly created C++ object by the
converters.
// Interface0D converters
PyObject * BPy_Interface0D_from_Interface0D( Interface0D& if0D );
PyObject * BPy_CurvePoint_from_CurvePoint( CurvePoint& cp );
PyObject * BPy_StrokeVertex_from_StrokeVertex( StrokeVertex& sv );
PyObject * BPy_SVertex_from_SVertex( SVertex& sv );
PyObject * BPy_ViewVertex_from_ViewVertex( ViewVertex& vv );
PyObject * BPy_TVertex_from_TVertex( TVertex& tv );
PyObject * BPy_NonTVertex_from_NonTVertex( NonTVertex& ntv );
// Interface1D converters
PyObject * BPy_Interface1D_from_Interface1D( Interface1D& if1D );
PyObject * BPy_Chain_from_Chain( Chain& c );
PyObject * BPy_FEdge_from_FEdge( FEdge& fe );
PyObject * BPy_FEdgeSharp_from_FEdgeSharp( FEdgeSharp& fes );
PyObject * BPy_FEdgeSmooth_from_FEdgeSmooth( FEdgeSmooth& fes );
PyObject * BPy_Stroke_from_Stroke( Stroke& s );
PyObject * BPy_ViewEdge_from_ViewEdge( ViewEdge& ve );
PyObject * BPy_directedViewEdge_from_directedViewEdge( ViewVertex::directedViewEdge& dve );
// some other converters
PyObject * BPy_ViewShape_from_ViewShape( ViewShape& vs );
PyObject * BPy_SShape_from_SShape( SShape& ss );
PyObject * BPy_FrsMaterial_from_FrsMaterial( FrsMaterial& m );
PyObject * BPy_StrokeAttribute_from_StrokeAttribute( StrokeAttribute& sa );
* Added a "borrowed" flag to the definitions of Python types being
used to wrap C++ components of Freestyle's internal data structures.
The flag indicates whether or not a Python wrapper object has a
reference to a C++ object that comprises the internal data structures.
The deallocation routines of the Python types check this flag and
release a wrapped C++ object only when it is not part of the internal
data structures. The following files were modified:
python/BPy_FrsMaterial.{cpp,h}
python/BPy_Interface0D.{cpp,h}
python/BPy_Interface1D.{cpp,h}
python/BPy_SShape.{cpp,h}
python/BPy_StrokeAttribute.{cpp,h}
python/BPy_ViewShape.{cpp,h}
python/Interface0D/BPy_CurvePoint.cpp
python/Interface0D/BPy_SVertex.cpp
python/Interface0D/BPy_ViewVertex.cpp
python/Interface0D/CurvePoint/BPy_StrokeVertex.cpp
python/Interface0D/ViewVertex/BPy_NonTVertex.cpp
python/Interface0D/ViewVertex/BPy_TVertex.cpp
python/Interface1D/BPy_FEdge.cpp
python/Interface1D/BPy_FrsCurve.cpp
python/Interface1D/BPy_Stroke.cpp
python/Interface1D/BPy_ViewEdge.cpp
python/Interface1D/Curve/BPy_Chain.cpp
python/Interface1D/FEdge/BPy_FEdgeSharp.cpp
python/Interface1D/FEdge/BPy_FEdgeSmooth.cpp
* view_map/Interface[01]D.h, python/BPy_Interface[01]D.cpp: Removed
from the Interface0D and Interface1D C++ classes a back pointer to a
Python wrapper object and all "director" calls. These classes (and
their subclasses) are used to build Freestyle's main data structures
(such as a view map and strokes) and their class hierarchy is static.
Python wrappers of these C++ classes are only used to access the data
structures from the Python layer, and not intended to extend the data
structures by subclassing the Python wrappers. Without the necessity
of subclassing in the Python layer, the back pointer to a wrapping
Python object and "director" calls would be useless (actually they
were not used at all), so they were all removed.
* python/Director.{cpp,h}: Removed the definitions of directors that
were no longer used.
* stroke/Stroke.{cpp,h}: Removed an (unused) back pointer to a Python
wrapper object.
* python/BPy_ViewMap.cpp: Fixed a possible null pointer reference.
* python/Interface1D/BPy_FEdge.cpp: Fixed parameter checking in
FEdge___init__().
|
|
BPy_directedViewEdge_from_directedViewEdge()
from list to tuple.
|
|
method returns a non-functional orientedViewEdgeIterator instance.
The iteration from the end to the beginning of the sequence relies
on orientedViewEdgeIterator::decrement() which is not actually
implemented in the C++ class. As a quick fix, the edgesEnd method
now raises a NotImplementedError.
|
|
to avoid an immediate crash. Now these methods raise a RuntimeError when
the iteration is already at the end.
|
|
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__().
|
|
|
|
|
|
a measure to avoid an infinite loop due to non-proper overriding
of the shade method.
|
|
|
|
iterator protocol. Now the following code in the conventional
SWIG-based syntax:
it = AdjacencyIterator(iter)
while not it.isEnd():
ve = it.getObject()
...
it.increment()
can be written using the iterator protocol as follows:
for ve in AdjacencyIterator(iter):
...
|
|
ChainingIterator::init() and ChainingIterator::traverse() were
not properly overloaded in a subclass.
|
|
* Fixed uninitialized fields in the "__init__" methods of UnaryFunction0D
types. Also added missing argument validation codes to some of the types,
and removed redundant validation error messages.
|
|
and UnaryFunction1DVectorViewShape::__call__().
* Added a Python wrapper of ViewEdge::qi().
|
|
"\\" (single backslash).
|
|
built-in types (the first was in revision 21877). When an exception
has raised within from the __init__ method of a user-defined class
derived from a built-in type (e.g., UnaryPredicate0D and
BinaryPredicate1D), some member variables of the base type are
left uninitialized, leading to a null pointer reference in the
"__dealloc__" function in the base type. To avoid this, pointer
checking was added in the deallocators of those built-in types that
can be used to define a subclass by a user.
|
|
|
|
callable(I, T) returns True when I is an object of a type T or
of a subtype of T. Also implemented a measure to avoid an
infinite loop when user-defined predicate and function classes
do not properly overload the __call__ method (including the
cases of directly instantiating the base classes such as
UnaryPredicate0D and BinaryPredicate1D).
|
|
|
|
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.
|
|
Now the following methods in the Freestyle Python API accept
not only Blender.Mathutils.Vector instances but also lists and
tuples having an appropriate number of elements.
FrsNoise::turbulence2()
FrsNoise::turbulence3()
FrsNoise::smoothNoise2()
FrsNoise::smoothNoise3()
SVertex::__init__()
SVertex::setPoint3D()
SVertex::setPoint2D()
SVertex::AddNormal()
FEdgeSharp::setNormalA()
FEdgeSharp::setNormalB()
FEdgeSmooth::setNormal()
CalligraphicShader::__init__()
StrokeAttribute::setAttributeVec2f()
StrokeAttribute::setAttributeVec3f()
StrokeAttribute::setColor()
StrokeVertex::setPoint()
* Added the following converters for the sake of the improvements
mentioned above.
Vec2f_ptr_from_PyObject()
Vec3f_ptr_from_PyObject()
Vec3r_ptr_from_PyObject()
Vec2f_ptr_from_PyList()
Vec3f_ptr_from_PyList()
Vec3r_ptr_from_PyList()
Vec2f_ptr_from_PyTuple()
Vec3f_ptr_from_PyTuple()
Vec3r_ptr_from_PyTuple()
Those converters with the suffixes _PyList and _PyTuple accept
only lists and tuples having an appropriate number of elements,
respectively, while those with the suffix _PyObject accept lists,
tuples, or Blender.Mathutils.Vector instances.
* Fixed a null pointer reference in Interface0D___dealloc__().
* Corrected the names of 3 methods in the FEdgeSmooth class.
|
|
|
|
|
|
blocks in BlenderStrokeRenderer::~BlenderStrokeRenderer().
|
|
in BlenderStrokeRenderer::~BlenderStrokeRenderer().
|
|
|