We were calling BLI_remlink and then BLI_insertlinkbefore/after quite often. BLI_listbase_link_move simplifies code a bit and makes it easier to follow. It also returns if link position has changed which can be used to avoid unnecessary updates.
Added it to a number of list reorder operators for now and made use of return value. Behavior shouldn't be changed.
Also some minor cleanup.
Error: `origin` and `edge` args were swapped in final `FindOccludee()` call of `ViewMapBuilder::ComputeRayCastingVisibility()`
Cleanup: main for loop in `Strip::createStrip()` was really confusing (though correct),
generated a false positive in coverity scan, now should be cleaner how it loops over its vprev/v/v2
triplet of consecutive items.
Group membership testing for including/excluding feature lines was not
accounting for object names possibly further qualified by library file
paths.
Also fixed a few potential (but unlikely) references of uninitialized
variables.
A big thank to Bastien Montagne for the insight on the cause of the
problem and how to fix it.
(A - A).norm() is always 0 so condition is always true.
(A - B).norm() and (B - A).norm() both compute the same distance so I
picked one to match surrounding code.
Found with PVS-Studio T48917
Now test_object_materials only handles one object. New test_all_objects_materials
checks the whole bmain->object list for cases where it is actually needed.
Should avoid some useless looping over all objects!
Two were actual bugs, though they existed only in unused code:
* In Freestyle it was unintentionally copying a scene rather than referencing it.
* In BLI_array_store_is_valid there was use of uninitialized memory.
FSAA sample files in EXR format are no longer always updated (after some
changes between 2.73 and 2.74 releases), and the reported bug was caused
by old samples from a previous frame that were being merged by mistake.
The present revision addresses the documented issue by entirely skipping
the rendering of auto-generated scenes when there are no Freestyle strokes
to render, which suppresses sample merging of the render layers that were
not rendered.
The addressed issue is a regression from Blender 2.75, after the internal
switch from double to single precision floating-point numbers in the
Freestyle code base. Face normal calculations require the higher
precision during the computations, even though the results can be stored
as single precision numbers.
This fixes reported issue, but there could be more of those hidden in Freestyle code,
it did not handle user refcount at all (and the fact it by-passes BKE in some places
for efficiency does not help here).
Note that this should be relatively harmless, since freestyle uses own Main during
render, so everything is cleaned up in the end in any case... But better try to
handle IDs correctly here too. :)
We have callbacks for that, they also do some checks and help ensure things are done
correctly. Only place where this is assumed not true is blenloader (since here we
may affect refcount of library IDs as well...).
The reported crash was confirmed as a segmentation fault in std::sort().
The cause of the crash was traced down to a binary comparison function
that was not satisfying the so-called strict weak ordering requirements of
the C++ standard sorting function. Specifically, the comparison operator
has to return false when two objects are equivalent (i.e., comp(a, a) must
be false), but that requirement was not met.
Since the binary comparison operator in question could be a user-defined
Python function, here a safety measure is implemented in the C++ layer to
make sure the aforementioned requirement is always satisfied.
Several class member variables were removed (at the cost of computing their values
when retrieved) or changed to a type of smaller size. Also fixed whitespace.
ImBuf types were getting stored as bitflags in a 32bit integer which had
already run out of space. Solved the problem by separating file type to
an ftype enum, and file specific options to foptions.
Reviewed by Campbell, thanks a lot!
This patch introduces a couple new stroke modifiers. The ones currently implemented are based on prototypes by @kjym3 and myself.
The new modifiers:
- Tangent
- Thickness noise
- Crease Angle
- Simplification
- Curvature 3D
The documentation for these new modifier types can be found [[ http://www.blender.org/manual/render/freestyle/parameter_editor/index.html | in the manual ]]:
{F134441}
(left: AnisotropicThicknessShader, right: NoiseThicknessShader)
{F140499}
(left: Curvature 3D, right: Simplification)
Author: Folkert de Vries (flokkievids)
Reviewers: kjym3
Subscribers: #user_interface, plasmasolutions, kjym3
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D963
This patch adds some new functionality to the Freestyle Python API, notably:
- MaterialBP1D, checks whether the supplied arguments have the same material
- Fixes a potential crash in CurvePoint.fedge (due to NULL pointer)
- Makes (error handling in) boolean predicates more robust
- Adds a BoundingBox type, to make working with bounding boxes easier
- Adds several new functions (get_object_name, get_strokes, is_poly_clockwise, material_from_fedge)
- Adds a StrokeCollector StrokeShader, that collects all the strokes from a specific call to Operators.create()
- Adds hashing and rich comparison to the FrsMaterial type
These new features (most of them, anyway) are needed for making a more robust SVG exporter that supports holes in fills.
Reviewers: kjym3, campbellbarton
Subscribers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1245
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
This calls are not strictly speaking needed for the old dependency graph, but
due to more granular nature of upcoming depsgraph more actions requires update
of relations of IDs.
On the one hand this extra tags could be wrapped with if() statements, but on
the other hand it makes sense to keep tag in sync so it's clear if some issue
is caused by missing/extra tag or by depsgraph itself.
