| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Addition of the path to the Freestyle Python API modules to 'sys.path' was delayed until
the first Freestyle rendering, so that any import attempt of the modules in the Python
Console always failed. Now the update of 'sys.path' is done at Blender start-up.
This allows the Freestyle-specific modules to be imported without running Freestyle,
facilitating quick interactive testing in the Console.
|
|
|
|
|
|
|
|
|
|
getter/setter methods..
These data elements are undocumented and of little use. For now they are commented out
in the implementation in favor of less memory consumption, and a very limited support for
these data components in the Python API was just removed (should be easy to recover).
|
|
Symbol 'real' is an alias of double and is subject to future change, while the interface of
0D/1D functions is part of the stable Freestyle Python API. So all occurrences of this type
in the class definitions were replaced with double.
|
|
Vertices of two edges were swapped by mistake. Also fixed indentation and added
a couple of debug prints to make it easier to visualize the lines using Matlab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the Nature class.
|
|
|
|
|
|
|
|
boolean values.
The problem is that comparisons involving the constants Nature.POINT (for vertices) and
Nature.NO_FEATURE (for edges) were evaluated in a wrong way. It is recalled that the
Nature class is a subclass of Python's built-in int type, and that these two constants are zero
when evaluated as numbers. The issue was caused by the implementation of the constants
in an incompatible way for comparison with Python int (and boolean) values. Specifically,
the zero of Python int is represented by an empty array of digits, whereas the zero-valued
Nature constants were represented by an array of size 1. Python int comparison operators
first check the lengths of the arrays of two operands, and then start comparing the digits
only when the array length is the same. For this reason, the two Nature constants were
not properly compared with int values (and thus with boolean values). It is noted that the
zero-valued Nature constants may result from bitwise operations on other Nature constants
(e.g., Nature.SILHOUETTE & Nature.BORDER), so this issue must have affected many
existing style modules.
The problem was reported by Folkert de Vries (flokkievids) through personal communications.
Thanks a lot!
|
|
|
|
Many thanks to flokkievids for identifying the inconsistency.
|
|
edge marks and at material boundaries.
Problem report by Postoman on the BlenderArtists.org Freestyle thread, thanks a lot!
|
|
|
|
|
|
The revision is concerned with Interface0DIterator and StrokeVertexIterator.
These iterators can be generated by Interface1D::vertices_end() and
Stroke::stroke_vertices_end(), respectively. These methods return an
iterator poinitng the next index of the last 0D element (i.e., iterator's is_end
property is true). When the iterators created in this way are used with
Python's iterator protocol (e.g., in a for-loop), iterations over 0D elements
are automatically performed in the reversed order. This functionality was
broken after recent revisions concerning Freestyle iterators.
Also made minor code cleanup (white space).
|
|
|
|
|
|
utility functions.
Also changed the type of the 'reversed' flag from int to bool.
|
|
|
|
Both C- and Python-coded API components were rearranged into logical groups.
New Python modules are packaged as follows:
freestyle - Top-level package
freestyle.types - Classes for core data structues (e.g., view map)
freestyle.chainingiterators - Pre-defined chaining iterators
freestyle.functions - Pre-defined 0D and 1D functions
freestyle.predicates - Pre-defined 0D and 1D predicates
freestyle.shaders - Pre-defined stroke shaders
freestyle.utils - Utility functions
The Python modules are installed in scripts/freestyle/modules. Pre-defined
styles are installed in scripts/freestyle/styles.
To-do: update styles according to the new Freestyle API package structure.
|
|
compile with those enabled.
|
|
Was a regression since e618d8238e0e and was caused by the wrong
main being tagged for update.
|
|
This is a regression since threaded dependency graph landed to master.
Root of the issue goes to the loads of graph preparation being done
even if there's nothing to be updated.
The idea of this change is to use ID type recalc bits to determine
whether there're objects to be updated. Generally speaking, we now
check object and object data datablocks with DAG_id_type_tagged()
and if there's no such IDs tagged we skip the whole task pool creation
and so,
The only difficult aspect was that in some circumstances it was possible
that there are tagged objects but nothing in ID recalc bit fields.
There were several different circumstances when it was possible:
* When one assigns object->recalc flag directly DAG flush didn't
set corresponding bits to ID recalc bits. Partially it is fixed
by making it so flush will set bitfield, but also for object
types there's no reason to assign recalc flag directly. Using
generic DAG_id_type_tag works almost the same fast as direct
assignment, ensures all the bitflags are set properly and for the
long run it seems it's what we would actually want to.
* DAG_on_visible_update() didn't set recalc bits at all.
* Some areas were checking for object->recalc != 0, however it is was
possible that object recalc flag contains PSYS_RECALC_CHILD which
was never cleaned from there.
No idea why would we need to assign such a flag when enabling
scene simplification, this is to be investigated separately.
* It is possible that scene_update_post and frame_update_post handlers
will modify objects. The issue is that DAG_ids_clear_recalc is called
just after callbacks, which leaves objects with recalc flags but no
corresponding bit in ID recalc bitfield. This leads to some kind of
regression when using ID type tag fields to check whether there objects
to be updated internally comparing threaded DAG with legacy one.
For now let's have a workaround which will preserve tag for ID_OB
if there're objects with OB_RECALC_ALL bits. This keeps behavior
unchanged comparing with 2.69 release.
|
|
source/blender ;)
|
|
Vectors were being assigned as an array of classes in Vec2f_ptr_from_PyObject and similar functions,
rather then assigning a number to each axis.
|
|
This gives undefined behavior - in my case stays the same value and crashes.
Check for finite input resolves the issue.
|
|
|
|
Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
|
|
|
|
reached
the end, any reference of the object pointed by it will now lead to a RuntimeError
instead of returning None, with the aim of forcing Python API users to check the
end of iteration rather than implicitly indicating the error condition.
Acknowledgement to flokkievids for API discussions in the BlenderArtists.org
Freestyle for Blender thread.
|
|
Now the method checks if the iterator is at the end, and returns None if that is the case.
|
|
Freestyle.
|
|
Freestyle color blending.
|
|
elements.
This bug was causing wrong color blending results in Freestyle color modifiers.
Problem report from Light BWK through personal communications, thanks!
|
|
|
|
LINEAR_LIGHT.
|
|
noise modifiers with a large 'octaves' value.
Problem report by Light BWK through personal communications, thanks a lot!
|
|
linestyles in some places.
|
|
|
