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.
This change introduces a new checkbox to deactivate the sensors, controllers and/or actuators. It is useful during the development phase to avoid delete sensors, controllers or actuators if you want to test something new.
NOC: The wiki page is being updated (the images mostly), but the feature is already in the 2.71 release log.
{F61628}
Reviewers: moguri, dfelinto, campbellbarton, dingto, #user_interface, billrey
Reviewed By: moguri
CC: billrey
Differential Revision: https://developer.blender.org/D16
Tessellated split normals CDlayer had no swap func, hence ugly little test_index_face()
could not rotate its values correctly when rotating tessellated faces...
Extra-reported in T39735.
There was some deadlock due to trying manage Python's GIL. Instead of
continuing to fight with it, anything needing to call into Python while
conversion during lib loading is just delayed until it can be done in
the main thread.
The problem here was that animation buffers got initialized with zeros in the beginning for unknown parts. Now it gets initialized with the first known value.
The bug's result was that the animation of the pitch started with 0 on first playback and thus any seeking while the pitch is zero resulted in seeking to the beginning.
For a long time, one of the bottlenecks when drawing summary channels in the dopesheet
(especially with many objects) was how the long keyframes feature (i.e showing holds
between keyframes) got built. Specifically, it was the step where we check on the previous
keyframe to see whether there's a hold between those two.
The old code performed some elaborate checks, which made sense back when we used to handle
certain summary channels (e.g. object-action/ipo, and groups IIRC) differently. However,
nowadays, everything just does it by going over the FCurves one by one, so the offending
code wasn't really providing much benefit. Unless I've forgotten some other reason why
that old method is necessary, this commit should provide a decent speedup here, making
things somewhat interactive now (if still a bit jerky).
Other Tweaks:
1) Introduced float-precision threshold when checking to see whether an existing long
keyframe could be reused. This should hopefully reduce the number of fp-jitter issues
when creating summaries for many channels, reducing the number of duplicates created.
2) Precompute colours used for shading the long keyframes, instead of recomputing for
each block.
Since this is now pretty much the de-facto "minimum distance between keyframes",
we might as well expose this in this header so that other places which need similar
thresholds can perform similar checks (needed for my next commit)
Issue fixed by:
* Not having constant width for all columns, but adapt each to its content's width;
* Adapting undo's menu height to undo list length (so that we never have more than three columns).
It is still possible to get issues in extreme cases (small screen, high DPI size,
long op names everywhere...), but this should now be rare corner cases.
Also fixes a minor glitch with undo menu (first column had one item less than the others...).
Many parts of the compositor are unnecessarily complicated. This patch
aims at reducing the complexity of writing nodes and making the code
more transparent.
== Separating Nodes and Operations ==
Currently these are both mixed in the same graph, even though they have
very different purposes and are used at distinct stages in the
compositing process. The patch introduces dedicated graph classes for
nodes and for operations.
This removes the need for a lot of special case checks (isOperation etc.)
and explicit type casts. It simplifies the code since it becomes clear
at every stage what type of node we are dealing with. The compiler can
use static typing to avoid common bugs from mixing up these types and
fewer runtime sanity checks are needed.
== Simplified Node Conversion ==
Converting nodes to operations was previously based on "relinking", i.e.
nodes would start with by mirroring links in the Blender DNA node trees,
then add operations and redirect these links to them. This was very hard
to follow in many cases and required a lot of attention to avoid invalid
states.
Now there is a helper class called the NodeConverter, which is passed to
nodes and implements a much simpler API for this process. Nodes can add
operations and explicit connections as before, but defining "external"
links to the inputs/outputs of the original node now uses mapping
instead of directly modifying link data. Input data (node graph) and
result (operations graph) are cleanly separated.
== Removed Redundant Data Structures ==
A few redundant data structures have been removed, notably the
SocketConnection. These are only needed temporarily during graph
construction. For executing the compositor operations it is perfectly
sufficient to store only the direct input link pointers. A common
pointer indirection is avoided this way (which might also give a little
performance improvement).
== Avoid virtual recursive functions ==
Recursive virtual functions are evil. They are very hard to follow
during debugging. At least in the parts this patch is concerned with
these functions have been replaced by a non-virtual recursive core
function (which might then call virtual non-recursive functions if
needed). See for example NodeOperationBuilder::group_operations.
