- Replace set of booleans with menu, so now you'll simply be unable to choose
unsupported refine combination
- Some internal code cleanup and minor refactor
This bug is caused by exactly the same reason as #26316: differences in how new vertices/edges
are getting calculated first and how they're adding later. In some cases extra vertices are
creating which weren't counted before.
This patch prevents crash in such situations, but result mesh can be a bit wrong.
This should work fine in bmesh, so think it's acceptable to have such workaround
before actual fix coming with bmesh.
ended up having to add a new pointer into the uiBlock (which I'd rather have avoided), but setting the uiLayoutSetContextPointer(..) was complicated to properly use for submenus and popus.
Beforehand, a few problems were in view: some of the indexing was changed towards the end to use the more efficient stack structure, but needed to use the correct def group indices.
Also, the designated selected group would use its own value to acquire the standard to base change distributed to the others.
Lastly, the total_change was used rather than -left_overs in the formula to compute the new designated weight within the means of the locks' allowed changes.
Now, while maintaining the ratios of the selection, it correctly returns left over change that could not be redistributed to the unlocked groups.
* OpenEXR doesn't need debug suffix
* Fix libmv template issue when linking by removing duplicate libmv inclusion. I wonder how this never turned up in release builds as well.
Important: Since OpenImageIO went into trunk, OpenEXR, possibly along with other image libraries will need to be turned on too because OIIO depends on them.
- Add support for refining the camera's intrinsic parameters
during a solve. Currently, refining supports only the following
combinations of intrinsic parameters:
f
f, cx, cy
f, cx, cy, k1, k2
f, k1
f, k1, k2
This is not the same as autocalibration, since the user must
still make a reasonable initial guess about the focal length and
other parameters, whereas true autocalibration would eliminate
the need for the user specify intrinsic parameters at all.
However, the solver works well with only rough guesses for the
focal length, so perhaps full autocalibation is not that
important.
Adding support for the last two combinations, (f, k1) and (f,
k1, k2) required changes to the library libmv depends on for
bundle adjustment, SSBA. These changes should get ported
upstream not just to libmv but to SSBA as well.
- Improved the region of convergence for bundle adjustment by
increasing the number of Levenberg-Marquardt iterations from 50
to 500. This way, the solver is able to crawl out of the bad
local minima it gets stuck in when changing from, for example,
bundling k1 and k2 to just k1 and resetting k2 to 0.
- Add several new region tracker implementations. A region tracker
is a libmv concept, which refers to tracking a template image
pattern through frames. The impact to end users is that tracking
should "just work better". I am reserving a more detailed
writeup, and maybe a paper, for later.
- Other libmv tweaks, such as detecting that a tracker is headed
outside of the image bounds.
This includes several changes made directly to the libmv extern
code rather expecting to get those changes through normal libmv
channels, because I, the libmv BDFL, decided it was faster to work
on libmv directly in Blender, then later reverse-port the libmv
changes from Blender back into libmv trunk. The interesting part
is that I added a full Levenberg-Marquardt loop to the region
tracking code, which should lead to a more stable solutions. I
also added a hacky implementation of "Efficient Second-Order
Minimization" for tracking, which works nicely. A more detailed
quantitative evaluation will follow.
GSoC11-Pepper changes forward to the version patch in place for Cycles +
Tracking.
It turns out that the original version patches introduced for these settings
were being done for the wrong version, and hence did not show in trunk as they
should have (2.59 came out before the branch was merged, so this kindof slipped
under the radar). The affected settings were:
- default handle-type (which was supposed to be "auto-clamped" but was "auto" in
trunk)
- theme settings for these handle colours
Regarding merge status, there should be no build failures, but cycles may not
be enabled in your build, we are still solving:
* Windows: CUDA kernel compile at runtime is failing, probably will have to
do precompiled kernel again.
* Mac: scons is not building cycles yet.
* Linux doesn't have boost + openimageio libs available in lib/ yet, so it
requires manual install of those libs still.
The __imp__ prefix on glew lib linking errors should have been a good indication: the code was looking for the glew dll.
Bypassed by adding GLEW_STATIC to the definitions.
* It seems we have a problem compiling the CUDA kernel at runtime on Windows,
will need to investigate more how to solve this best, CPU render should go
fine though.
* Change OPENIMAGEIO to OPENIMAGEIO_ROOT_DIR on linux for consistency.
