| Age | Commit message (Collapse) | Author |
|---|
|
For now only affects blender internal renderer and viewport.
Currently it's possible to define overscan (in %%) manually
or make it so distortion matches the motrack displacement
model.
Still need to do loads of things in compositor, but it's
not such a bad starting point.
We can even start a branch for this.
Reviewers: dfelinto
Differential Revision: https://developer.blender.org/D462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
As suggested by Martijn, this is slower than cuLaunchGrid.
|
|
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
|
|
Seems to be some sort of namespace conflict or so which is
solved by reshuffling the includes a bit.
|
|
|
|
|
|
|
|
|
|
Own logic error in previous commit...
|
|
|
|
- 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.
|
|
also rename BLI_omp_thread_count -> BLI_system_thread_count_omp
|
|
|
|
These qualifiers were leftovers of the stand alone Freestyle program and not used
(set to an empty string) in Blender for years.
|
|
|
|
|
|
|
|
(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.
|
|
|
|
type enum
|
|
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
|
|
obsolete compileflag magic
|
|
|
|
|
|
|
|
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.
|
|
This reverts to the 2.69 behavior, where the snap-to-midpoint option
affected the intermediate crossed edges as well as the endpoints.
|
|
While not exactly a bug, switching to scale isnt generally useful to keep normal constraint.
|
|
|
|
Fixed this issue and another similar one, and some minor optimizations.
|
|
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.
|
|
properly.
|
|
|
|
|
|
build the matrix directly rather then calculating with axis/angle
also remove unused function calc_poly_plane
|
|
passing in a unit length vector wouldn't always compute unit length vectors because the epsilon tested was too small.
|
|
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.
|
|
|
|
Missing check when looking for appropriate LoD
|
