Because of strange reason, cone boundbox was rotated and it wasn't
reflecting physics engine which used "correct" cone boundbox.
Changed displaying of cone bounding box type.
In some cases solving can take a while (especially when refining is used)
and keeping interface locked is a bit annoying. Now camera solver is moved
to job system and interface isn't locking.
Reporting progress isn't really accurate, but trying to make it more linear
can lead to spending more effort on it than having benefit. Also, changing
status in the information line helps to understand that blender isn't hang
up and solving is till working nicely.
Main changes in code:
- libmv_solveReconstruction now accepts additional parameters:
* progress_update_callback - a function which is getting called
from solver algorithm to report progress back to Blender.
* callback_customdata - a user-defined context which is passing
to progress_update_callback so progress can be updated in needed
blender-side data structures.
This parameters are optional.
- Added structure MovieTrackingStats which is placed in MovieTracking
structure. It's supposed to be used for displaying information about
different operations (currently it's only camera solver, but can be
easily used for something else in the future) in clip editor.
This statistics structure is getting allocated for time operator is
working and not saving into .blend file.
- Clip Editor now displays statistics stored in MovieTrackingStats structure
like it's done for rendering.
This commit implements:
- Configurable settings for newly creating tracks
Now it's possible to set tracking algorithm and it's settings for
all newly creating tracks including manual tracks creation and
tracks creation by "Detect Features" operator.
- Moves margin, frames limit and adjust frame inside per-track
settings.
Was request from Francois for this.
- Adjust Frames replaced with menu called Pattern Match where it's
possible to choose between matching pattern from keyframe frame
or from previously tracked frame.
Didn't see somebody used adjust frames values differ from 0 and 1,
and this menu should make things more clear here/
- curve map insert point had a nested loop which used the same value to index different arrays.
- dynamic paint used ternary operator where both outcomes were the same.
- Force libsamplerate linking statically
- Remove global compiler flags for sse2 and sse.
Tests of release builds didn't show big difference in time of
tracking using SAD algorithm or time of solving,
so this shouldn't introduce big slowdown.
Currently this stuff is used for 2d tracking job only, but the same
thing would necessary for camera solver job, so moved it into more
general utility stuff.
The problem was in fact in the changes made to blend_ramp() func at rev42164. The checks on green pointer (if(g) {...) were checking the existance of a valid value (i.e. if input color was rgb or only shades of grey in r pointer), but as we get now a full float[3] pointer, this test is no more possible. And doing if(r_col[1]) {... was wrong, as it only broke things in case green was 0.0 (which was the case with the generated glare color of bug report).
So, just removed all those tests!
Transparent rendering can't be implemented in way it gives accurate shading in
3d viewport. It's acceptable for object mode, but when you're in edit mode
it gives more problems than benefits of seeing transparent faces.
This is possible fix for for weird polygons in [#29255] Object invisible and weird polygons appearance
"Just a simple check for non power of two support (GLEW_ARB_texture_non_power_of_two), to avoid what seems to be a very slow, and very unnecessary gluScaleImage call."
This is the only part of the VideoTexture that does the POT calculation, so the check seems good.
It would be interesting if some opengl guru would like to benchmark the use of this in other areas of Blender (e.g. 2D Filters, and all GLSL materials).
Note that mipmap should also be supported automatically by this extension, so it's not something to worry about.
