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.
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.
to enable from python:
bl_options = {'REGISTER', 'UNDO', 'PRESET'}
from C:
ot->flag= OPTYPE_REGISTER|OPTYPE_UNDO|OPTYPE_PRESET;
- added context member 'active_operator'
- enable this for 'Add Torus' for testing.
Not sure why, but doing the same things as in script from FontForge UI, there's
no issues described in report. Probably matter of some default settings.
Hope it works now fine for everyone.