Line styles now have a set of new options for rearranging the stacking order of lines.
This gives artists more control to determine which lines should be drawn on top of others.
Two available sort keys are the distance from camera and curvilinear 2D length.
Since the distance of a line from camera may vary over vertices, another option called
integration type is used to compute the sort key for a line from the values computed at
individual vertices. Available integration types are MEAN, MIN, MAX, FIRST and LAST
(see the tool tips for more detail).
Seems like custom data indices can be mangled when many layers are
present in the mesh, so use more strict calculation of offset (copied
over from BM_CD_LAYER_ID).
I was under the impression that all custom data would be deleted on
entering dyntopo, it seems this is not the case though.
It makes code more tidy (avoids having to call invalidation on a myriad
places). Also makes sure other invalidation cases (some mesh change,
e.g.) work as expected.
Don't use a dedicated node layer but use temporary int layer instead.
Works like a charm as long as we are careful resetting the layer when
needed (after pbvh clearing and always after bmesh has been filled in
undo)
Tip by Campbell, thanks!
It shouldn't create issues in practice because modified face ids should
have been reclaimed from an added face on a previous entry, but add for
completeness.
This commit makes it so CameraIntrinsics is no longer hardcoded
to use the traditional polynomial radial distortion model. Currently
the distortion code has generic logic which is shared between
different distortion models, but had no other models until now.
This moves everything specific to the polynomial radial distortion
to a subclass PolynomialDistortionCameraIntrinsics(), and adds a
new division distortion model suitable for cameras such as the
GoPro which have much stronger distortion due to their fisheye lens.
This also cleans up the internal API of CameraIntrinsics to make
it easier to understand and reduces old C-style code.
New distortion model is available in the Lens panel of MCE.
- Polynomial is the old well-known model
- Division is the new one which s intended to deal better with huge
distortion.
Coefficients of this model works independent from each other
and for division model one probably want to have positive values
to have a barrel distortion.
- pass label strlen since in many cases its already known.
- use single linked list for cached text drawing.
- add BLI_link_utils.h for single linked list macros.
own tests give approx 22% overall speedup.
(See commit e1771e72fbbf828dbf5bed871b814288389f3611 for more detail of
the problem).
Fix for a C++ scope issue caused by 'using namespace Freestyle' that was assumed
even within the Freestyle namespace definition.
(See commit e1771e72fbbf828dbf5bed871b814288389f3611 for more detail of
the problem).
Made changes to intern/view_map/Interface0D.h and intern/python/Director.h to
avoid #include <Python.h> and keep non-Python header files independent of it.
(See commit e1771e72fbbf828dbf5bed871b814288389f3611 for more detail of
the problem).
Fixed for #include <Python.h> not properly put in the extern "C" { ... } construct.
Also removed redundant inclusion of the header file in the Freestyle Python API code.
The issue was caused by including both Python.h and BLI_math.h. Since the macro
definition in Python.h was unconditional, it was necessary to include it first and then
BLI_math.h.
Addressing the issue turned out to affect many Freestyle source files. There were several
other coding flaws that complicated the situation:
1. intern/system/FreestyleConfig.h was abused just to include BLI_math.h which was in
fact unnecessary in FreestyleConfig.h. While addressing this, inclusion of both math.h
and BLI_math.h had to be duly dealt with to avoid a compiler error about round().
2. #include <Python.h> was not properly put in the extern "C" { ... } construct.
3. intern/view_map/Interface0D.h and intern/python/Director.h, both of which included
Python.h, were included from within Freestyle header files that were almost or completely
independent of Python. These non-Python header files were used everywhere in the
Freestyle code base, causing many cases of the reported macro redefinitions.
4. The Director.h file was also declaring 'using namespace Freestyle', which was causing
another scope issue in several Freestyle header files.
This commit is intended to address the first problem above. Subsequent commits will deal
with the other three.
