| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This removes Python version checks needed to build with 3.8+ and 3.7x.
Ref D10381
|
|
The header files in freestyle utilize the using-directive at the global
file scope. This is a bad practice as it pollutes the global name space
causing possible ambiguous reference compilation errors. In particular,
the DNA files that are included by freestyle will cause those ambiguous
reference errors when the developers adds a DNA member with a type name
that also exist in the Freestyle name space, such as Curve and possibly
others.
This patch does the minimal work needed to resolve that by moving the
using-directives from the headers into the corresponding translation
units.
Reviewed By: Brecht
Differential Revision: https://developer.blender.org/D10351
|
|
While `tp_print` was deprecated, Python 3.8+ uses this for
'tp_vectorcall_offset' which wasn't stated in the comment from
efd71aad4f22ec0073d80b8dd296015d3f395aa8.
Instead of suppressing clang-tidy, use preprocessor a check since
this properly represents the difference between Python versions.
|
|
|
|
Clang-tidy behavior changes from Python 3.7 to 3.8+ so it's simplest
to suppress the warning in this instance.
|
|
Caused by 16732def37c5a66f3ea28dbe247b09cc6bca6677,
This is a 'Py_ssize_t' in Python 3.8,
replace with zero as this works in both 3.7 and 3.8.
|
|
|
|
Replace `NULL` with `nullptr` in C++ code.
No functional changes.
|
|
Also enable it in the configuration.
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3744
|
|
Automated using clang-tidy.
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Needed for clan-format not to wrap onto one line.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
this can be added back on case-by-case basis, but better not assume ownership of another projects work by default.
|
|
|
|
|
|
|
|
API users no longer need to define them in user-defined Functions, Predicates and StrokeShaders.
Also removed all .getName() and .getExactTypeName() definitions in pre-defined Functions,
Predicates and StrokeShaders subclasses.
|
|
*)self)->ob_type->tp_name.
|
|
implementation
of the attribute (meant to be a shortcut of .__class__.__name__).
|
|
Handling of keyword arguments in Python wrapper class constructors was revised.
This revision is mainly focused on Interface0D, Interface1D, Iterator, and
their subclasses, as well as a few additional view map component classes.
Implementation notes: Because of the extensive use of constructor overloading
in the underlying C++ classes, the corresponding Python wrappers try to parse
arguments through multiple calls of PyArg_ParseTupleAndKeywords() if needed.
The downside of this implementation is that most argument errors result in the
same error message ("invalid argument(s)") without indicating what is wrong.
For now this issue is left for future work.
* Now the instantiation of ViewVertex is prohibited since the underlying
C++ class is an abstract class.
* Removed the .cast_to_interface0diterator() method from CurvePointIterator
and StrokeVertexIterator. Instead the constructor of Interface0DIterator now
accepts the instances of these two iterator classes to construct a nested
Interface0DIterator instance that can be passed to Function0D functor objects.
Specifically, an iterator 'it' is passed to a functor 'func' as follows:
func(Interface0DIterator(it))
instead of:
func(it.cast_to_interface0diterator())
* Boolean arguments of class constructors only accept values of boolean type.
Input values of other types are considered as error.
* Additional code clean-up was made.
|
|
Major API updates were made as in part 3 to address code review comments.
This revision focuses on Python wrappers of C++ iterators.
* Most getter/setter methods were reimplemented as attributes using PyGetSetDef.
* The naming of methods and attributes was fixed to follow the naming conventions
of the Blender Python API (i.e., lower case + underscores for methods and attributes,
and CamelCase for classes). The only irregular naming change is the following, to
better indicate the functionality:
- ChainingIterator: getVertex --> next_vertex
* In addition, some code clean-up was done in both C++ and Python. Also duplicated
definitions of predicate classes were removed.
|
|
|
|
should have been used.
|
|
(http://freestyle.sourceforge.net/doc/html/index.html) has been
incorporated into the Blender/Freestyle Python API implementation
in the form of Sphinx-based embedded docstrings. Some C++-specific
descriptions of classes and functions were revised so that they are
suitable for Python programmers. Missing docstrings were filled,
and sparse descriptions were extended. By means of the new
documentation system for Blender, an up-to-date Freestyle Python
API reference will be part of the Blender 2.5 documentation.
|
|
|
|
to avoid an immediate crash. Now these methods raise a RuntimeError when
the iteration is already at the end.
|
|
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.
|
|
of the original styles are supported: stroke attributes are correctly taken into account, Python shaders are supported. Added SamplingShader.
|
|
modules having with strokes without a representation and iterators not being correctly routed. For example, the cartoon style module should work now.
|
|
classes, except EdgeModifier and TimestampModifier (which aren't even ported via SWIG), are available under the Blender.Freestyle module. Testing of the porting will now begin to make sure the SWIG-less system works as the original.
Quite a few modifications were made to finish the API:
- Freestyle's SConscript was modified to catch all files within the intern/python directory, allowing integration of future shaders implemented in C++.
- the Operators class was ported, with a special care of making its methods static (using the METH_STATIC flag in the tp_methods method definitions)
- all of the type-checking functions [ BPy_[class name]_Check(obj) ] were changed to allow subclasses to be seen as that type too: instead on looking at the ob_type value, the PyObject_IsInstance function is used.
- all of the iterators can now retrieve the object pointed to by the operator, using the getObject() method. A directedViewEdge pair is returned as a list of the two elements in the pair.
- all of the style modules were copied to a style_modules_blender/ folder and were modified to use Freestyle as a Blender's submodule. IntegrationType and MediumType was also integrated (for example, changing MEAN to IntegrationType.MEAN).
Testing now begins. If everything works correctly, I'll move on to lib3ds removal right away.
|
|
and ChainSilhouetteIterator
|
|
ChainingIterator. Updated UnaryPredicate{0D,1D}
|
|
Interface0DIterator, CurvePointIterator, StrokeVertexIterator, SVertexIterator, orientedViewEdgeIterator.
|
|
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)
|
