This brings new copyright header which supports GPL2 and 3.
It wasn't really an issue before because we had agreement with
Tobias, but now it's all documented in sources.
Brings new bounds limiting and also prepares build system
for the changes in the upstream.
Namely shared_ptr header and namespace is now being detected
by a build system rather than by hacks in the code.
This commit includes some changes to auto-detection flags
in SCons, presumably adding more consistency there. This
is main changes which are suppoed to be reviewed here.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D581
In the future i'd rather have this reported to an
upstream instead of adding local changes. It's really
easy to override this changes if patchset is not added
and this is to be fixed in upstream. Also the function
was never used so it was rather totally harmless warning
for us.
Pass the arrays by reference rather than by value,
should give some percent of speedup.
Also don't pass the dimensions to the function but
get them from the images themselves.
Hopefully this will give some %% of tracker speedup.
This means if one makes change to either SConscript or CMakeLists.txt
there he MUST update bundle.sh.
Also made it so *.cc files from intern/libmv are matching which would
make it easier to add more .cc files there if needed.
And one more thing is removing 'simple_pipeline/distortion_models.cc'
which doesn't match any of the files.
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.
This gives a huge speedup gain for cases when you've got
rather huge markers on a byte images.
Done by skipping IMB_float_from_rect()/IMB_rect_from_float()
for such cases. We can sample the buffers without color space
conversion.
This was a nasty bug which was caused by specific of how face-edge
attributes are stored in Carve.
Face pointer is used in the map key which works just fine in all
cases except for the cases when some face is getting freed after
it was stored in the map.
This might give real issues when new face is allocating because
it's possible new face would have the same address as the freed
one.
Such cases used to happen when union of separate manifolds is
needed for the operands AND jemalloc is enabled.
Solved by dropping attributes for the freed faces from the map.
Maybe not the fastest ever approach, but not sure how to make
it faster actually. Should work just fine. It only happens for
complex setups with intersecting manifolds in the operands.
-ffast-math is evil, not sure why it was enabled...
I seems to work better on OSX but it's still not a good idea.
The SConscript for bullet is a mess, I don't understand why
we use different flags for different platforms in the first place.
Seems to be a historical artifact but I don't know enough about scons
to try and clean it up.
Using unordered_map and unordered_set C++ container types currently
requires careful testing or usage of boost, due to the various confusing
C++ version differences in include paths and namespaces.
Libmv defines tests for these cases in cmake and scons, such that ceres
can use any available implementation, or fall back too std::map/std::set
if none can be found.
This patch generalizes this buildfile code by providing a Blender macro.
* cmake: defines both the variables used by libmv at them moment as well
as 2 variables UNORDERED_MAP_INCLUDE_PREFIX and UNORDERED_MAP_NAMESPACE,
which can later be used in other C++ parts for convenience.
* scons: adds a tool script returning the include prefix and namespace.
Libmv checks these to define the appropriate definitions for ceres.
Differential Revision: https://developer.blender.org/D425
This is mainly a maintaince commit which syncs changes
between Blender and Libmv upstream also bringing new
GLog version.
This GLog version is presumably have better support of
MinGW from "the box".
This commit is also aimed to make further 3d part libs
update easier.
This re-applied patch from 25cbd13 which was lost at some point
since missing patchset in series.
This revision is to be back-ported to the final release.
I overlooked in cmake my fix same time changed the optimization level to 0,
so not use optimization is the real fix ( postponed for after 2.70 ).
I appears we should investigate scons anyway: compileflags does not apply to c and c++ same time as expected.
This was caused by static variables used in plNearestPoints().
For now solved by making the solvers allocated in the stack,
seems no noticeable affect on the simulation speed so far.
There were loads of issues in the code still which are mow likely fixed:
- Hole resolver hook had memory leak -- it didn't free face with holes
when triangulating it.
- Original edge mapping didn't work correct. old code related on the fact
that loop order is not changing when constructing the MeshSet class, but
in fact it does change.
Currently used edge map for this because it was easiest way to do it now,
but after the release we're to change it. Main reason is that face mapping
is not correct as well (and it was never correct actually). So we'll need
to construct Mesh structures by our own to be sure we're using correct
original index mapping.
- Carve might produce faces with ears, which is forbidden in Blender.
it wasn't an issue in old integration because triangulation will remove
the ears. So for now simply added ears removing back as a hook.
But actual reason of the ears is to be investigated really.
This hook will only work for NGons, quads are assumed not be able to
have ears. So this additional hook shouldn't slow down things much.
- Carve's hole resolver produces duplicated faces in some cases. Still not
sure what is the reason of this. Code here is not so much straightforward,
this is to be investigated later.
For now solved the issue as own hole resolver which checks for duplicated
faces after the hole resolving.
The additional checks here will only run if the mesh actually have hole
and wouldn't introduce slowdown for faces which doesn't have holes.
- Made it so if edge user triangulation gets a split (for example, in cases
when this edge intersects with the second operand) it wouldn't be dissolved.
This prevents cases of crappy topology after dissolving in several cases.
- Edge dissolver didn't check for whether edge is a non-manifold. We couldn't
really dissolve open manifold edges.
The bad thing about this is that mesh triangulation might produce non-manifold
edges and they wouldn't be dissolved. Not worst case in the world, but would
be nice to have it solved somehow.
- Exporting mesh form Carve to Blender might have produced duplicated edges
in cases when several non-manifold faces shared the edge. This is also fixed
now.
- Mesh triangulation might have produced duplicated faces, which is really bad.
Fixed by keeping a track on which faces we've created and skipping adding new
triangle if we already have one.
This all might introduce some slowdown, but we're too close to the release now,
so would rather have it slower but robust. After the release we might look into
ways to speed things up.
This is needed to minimize their reprojection error over the footage.
Without this extra step positions of such tracks were calculated by
algebraic intersection code only, which doesn't give best precision.
Avoid zero-sized problem when doing euclidean intersection
Zero-sized problem might occur when intersecting track with
constant zero weight. For such tracks we'll just use result
of algebraic intersection.
TODO: We probably need to have a separate BA step to adjust
positions of tracks with constant zero weight.
It doesn't make sense to use zero-weighted tracks as a correspondences
in keyframe selection.
Such tracks are not guaranteed to be tracked accurately because their
purpose is to add reference points in 3D space without affecting the
solution.
This gives much worse results on mango footage (see 04_2e)
so disabling for now for until proper prediction model is landed.
The thing is, currently blender sends input coordinates as the guess to
region tracker and in case of fast motion such an early out ruins the track.
This commit implements dissolving of edges which were used
to triangulate non-flat faces. This slows things down a bit
(around 5% on heave mesh with all faces triangulated).
We could improve speed of dissolve a bit here (so not a bell
to add an option for triangulation yet).
Also fixed wrong edge origindex mapping.
Goal of this commit is to support NGons for boolean modifier
(currently mesh is being tessellated before performing boolean
operation) and also solve the limitation of loosing edge custom
data layers after boolean operation is performed.
Main idea is to make it so boolean modifier uses Carve library
directly via it's C-API, avoiding BSP intermediate level which
was doubling amount of memory needed for the operation and which
also used quite reasonable amount of overhead time.
Perhaps memory usage and CPU usage are the same after all the
features are implemented but we've got support now:
- ORIGINDEX for all the geometry
- Interpolation of edge custom data (seams, crease)
- NGons support
Triangulation rule is changed now as well, so now non-flat
polygons are not being merged back after Carve work. This is
so because it's not so trivial to support for NGons and
having different behavior for quads and NGons is even more
creepy.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D274
First thing changed by this commit is making it so
Euclidean intersection takes track weight into account
when solving minimization problem. This behaves the
same exact way as it is for BA step.
Second thing is related on how average reprojection error
is being calculated. It didn't take track weight into
account which could confuse users. Now average reprojection
error will give the same result as intersection/BA uses
during minimization which gives much more predictable
behavior.
Differential Revision: https://developer.blender.org/D265
Using tracks with constant zero weight used to crash
keyframe selection since it was trying to use missing
parameter blocks for Jacobian evaluation,
Also fixed possible issues with wrong camera block being
marked as variable. This could technically happen when
having zero weighted tracks. Made it so all camera blocks
are marked as variable for now.
Switch the detector API to a single function which accepts
a float image and detector options. This makes usage of
feature detection more unified across different algorithms.
Options structure is pretty much straightforward and contains
detector to be used and all the detector-specific settings.
Also implemented Harris feature detection algorithm which
is not as fast as FAST one but is expected to detect more
robust feature points. It is also likely that less features
are detected, but better quality than quantity.
Blender will now use Harris detector by default, later we'll
remove FAST detector.
Fixes some issues with NaN vertices in special cases.
Also adds edge interpolation routines which are currently
unused but which are requires to implement edge CD interpolation.
Mainly fixed some style warnings reported by cpplint.
Also changed how camera (un)distortion happens internally
by replacing number of channels as a template argument
with number as channels passing as function argument.
Makes code easier to follow by eliminating loads checks
how much channels are used and which argument to pass to
the template.
Summary:
This brings up much easier termination type usage,
which for us means we might use:
ceres::Summary::IsSolutionUsable()
instead of doing manual funky enum values check.
Reviewers: keir
Differential Revision: https://developer.blender.org/D153
Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
The issue was caused by the fact that in this version
of MSVC unordered_map class is defined in <unordered_map>
header file, but this file declares the class int std::tr1
namespace.
This confused existing assumption that if there's an
existing <unordered_map> file then class is declared
in std namespace.
Added an extra check to CMake which detects whether
it's std or std::tr1 which actually contains class
of unordered_map.
This might be changed/cleaned in the future, for
now committing to our repository to solve compilation
error on windows.
Details of the patch in upstream can be found there:
https://ceres-solver-review.googlesource.com/#/c/4371/
- A richer Problem API.
- DynamicNumericDiffCostFunction.
- Faster ITERATIVE_SCHUR solver.
- Faster SCHUR_JACOBI preconditioner.
- Faster Jacobian evaluation.
- Faster visibility based preconditioning using single linkage clustering.
Also re-wrote rules for unordered collections detection,
should work on all platforms and compilers now :)
- random.hpp was only removed from actual include
directory, but not from patches/files.
- Files list generator didn't ignore config.h file
which in fact is not needed.
- A bit more reasonable name for the estimation option
structure and estimation functions.
- Get rid of unclear function and parameter tolerance,
it wasn't clear at all in which units they are.
Now we've got expected_average_symmetric_distance as
an early output check and as soon as average symmetric
error goes below this threshold refining finishes.
This distance is measured in the same units as input
points are.
It is arguable whether we need callback for this or not,
but seems Ceres doesn't have some kind of absolute
threshold for function value and function_tolerance
behaves different from logic behind expected symmetric
error.
- Added option to normalize correspondences before
estimating the homography in order to increase estimation
stability. See
R. Hartley and A. Zisserman. Multiple View Geometry in Computer
Vision. Cambridge University Press, second edition, 2003.
https://www.cs.ubc.ca/grads/resources/thesis/May09/Dubrofsky_Elan.pdf
