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.
Otherwise devices used for display will lock up the UI too much. This means
you might still get 100% CPU for the display device, but for others CPU usage
should be low still.
The check to see if a device is used for display may not be entirely reliable,
it checks if there is a watchdog timeout on the device, but I'm not entirely
sure that always exists for display devices or is disabled for non-display
devices, though some tools like cuda-gdb seem to make the same assumption.
Ref T39559
- 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
This makes it easier to have per kernel number of registers. Also, all the
tunable parameters for this are now in kernel.cu, rather than spread over cmake,
scons and device_cuda.cpp.
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.
