Once a dupli had a valid bbox, that bbox would be used for all following objects
without bbox, instead of skipping clipping check.
Issue unveiled by rB3fa0a1a5bc0ff2, but not related at all (in fact, bug was present before that commit).
Current startup .blend has old (percent?) values for particle brush strength.
Since rBe4e21480d6331903c90ab073746484498441e1ac, UI controls do not clamp automatically values anymore,
which means when you first enable comb (or any other brush) you get a 50 strength, waaaayyyy to powerful.
This commit fixes this in `BLO_update_defaults_startup_blend`, note that it does not fix custom users'
startup files, nothing to do here...
Handling `me` data here is not good idea anyway, we override it completly with data
from `tmp` (crash came from freeing already existing bb from me, while pointer still existed in tmp).
(rediscovered it while working on T47676...).
To be backported to 2.77.
Pointers of faces were passed as face keys during parametrizer's face creation. Since those
addresses were different for every run, the layout of the faces ended up being different
in the internal hash, leading to inconsistent order of their evaluation during LSCM solving,
and slightly different UV maps.
Solved by simply using faces' indices as key instead, which ensures we always get same results
with exact same input data now.
Many thanks to Roman Nagornov (RomanN) for raising the issue, investigating it and finding
the solution! And thanks to Brecht for quick review too.
Code was using degrees as radians.
Still unclear why default cube will have 180 degrees angle, but new meshes 30,
but that's kinda separate topic which is to be addressed separately.
This is a subject for final 2.77 release.
See rB935e241fa6ea095493 for details of the issue, but first fix caused regression T47632.
So for now handling the issue in a localized way, this is not a real solution (since this could happen
in other cases), but will do for 2.77.
This commit is to be backported to 2.77.
This reverts commit 935e241fa6.
Issue will be fixed in a more localized way for now (not that nice, since this use-after-free can possibly happen
in other places too, but only safe solution for 2.77).
This commit is to be backported in 2.77.
ked->iterflags actually already had an enum defined, but at the time of the previous
fix, I'd forgotten that it was defined. As a result, "f1 needs NLA remap" got given
the same flag as "include handles when doing keyframe selection checks".
In response to user feedback, this commit brings back the ability to
limit motionpath clearing to only happening for those on selected
objects/bones.
By default, the "Clear" operator will clear from all objects/bones,
unless the Shift key is held.
With continuous grab disabled, non-linear mapping for int buttons
wasn't working usefully with small mouse movements.
Now 2x pixels motion adjusts by at least 1 w/ int buttons.
Took me some time to figure out what was going on here... Was again that delayed button
callback stuff (`ui_apply_but_funcs_after()`), first calling button op, and then
its callback func.
Issue was that 'open file' op (through call to `WM_file_read()`) would clear
the splash screen (as more or less the entire 'dynamic' UI), but callback func of that splash
(`wm_block_splash_refreshmenu()`) would still try to access that freed menu's region.
So, root of the issue seems to be that setting context's wm/win/etc. would not clear
context's menu pointer (while clearing all other 'sub' pointers). I could not find
nor imagine any case where this behavior could be desired, so simply added nullification
of that pointer when setting context's wm/win/etc.
Note that crash was due to read-after-free, infuriating debug builds with asan,
but seems like release builds never actually crashed on it.
