Caused by wrong alpha value in rB34b30f847429ac (used 0.01, should've been 0.1). Also made sure all editors initialize same default theme values for panels and cleaned up code a bit.
Works fine with old userpref.blend files.
Basically, issue is that outliner stores editbones for an edited armature, which are only valid during EditMode.
When more than one object use the same armature, selecting ebones from same armature but under non-edited object
would first select that object (and hence switch out of editmode), and then try to select editbone while editdata
no more exist.
Solution for now is to not change active object in this case - it's not totally ideal (not consistent),
but other solutions (like switching edited object without leaving editmode, or rebuilding (part of)
outliner tree in-between) are horribly hackish and most likely prone to epic failure anyway.
Shift-space was reserved for IME support, however IME will only
be enabled on certain languages. We can avoid any IME-related
exceptions form other languages without too much trouble.
There's one weak point around ui_ime_is_lang_supported() tho,
which is it might be doing string comparison a bit too much
often now, this we can avoid by handling those checks from BLT.
Not very efficient solution -- it'll update mapping node on init ntree exec and will
not work for viewport GLSL shading perhaps, but it's as good as it could be within
current dependency graph.
The issue here is that manual edit of values will cause cached matrix re-evaluation.
but using animation does not use rna update callbacks hence no matrix update was
happening.
- scripts that execute directly need to include their basedir in the sys.path
- modules which are in a directory without an __init__.py weren't importing.
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_n are not defined on this architecture
for some reason, however those functions are available.
Adding a workaround for newly used __sync_fetch_and_and() function.
Own regression from rB019ce363b01bba0af, not totally sure why removing the heading
zero value in element_sum broke binary search distribution in random branch, but...
New code makes thing sooo much simpler, by simply getting rid of all zero-weight
items in element_sum (at the cost of adding a temporary extra index mapping array),
that way neither random nor 'even ordered' distribution code has to wory anymore
about skipping zero-weighted items!
In some cases, we can have nodegroups without attached nodetree, this case is checked
in top `node_group_has_output()` entry point, but not in recursive `node_group_has_output_dfs()`.
Issue appeared after rB42824f4403db3a35, presumably because check on node flag itself
was skipping that case, which is no more possible when using ID tags.
Reported by sebastian_k over IRC, thanks.
This commit mostly:
* removes some (very) old messages or hacks (like those for ubuntu 10.4...).
* Moves lib-specific dependencies installations to upper level
(simpler to manage, and those are small enough packages).
* Uses new dnf package manager for fedora (sigh, we now have tree different commands for fed/suse/rehl).
* fixes or enhances some options for commandline tools.
* Force anew building of oiio package, due to insane dependencies of this one in recent distro.
Part of D1933.
Now CD_SHAPEKEY_INDEX customdata is stored in edit-mode when hooks and vertex parents are used.
This also fixes a bug where undo would loose key-index data.
Move to structs for BM_mesh_bm_to/from_me to avoid passing many argument, which mostly aren't used.
The issue was caused by missing indirect dependencies from other scenes in the
current scene depsgraph, which was causing some threading conflicts.
Not sure what would be ideal solution here, for now use stupid but rather robust
approach to solve that. Maybe there's something better to do here tho.
Currently a lot of the nodes in the new dependency graph are empty placeholders
for organizational purposes. These nodes would, however, still be assigned a task
which gets scheduled and takes up some time for worker threads to pop from the
queue and run. This can be avoided by skipping these nodes during depsgraph
scheduling, and scheduling their childrent right away. Gives a few percent speedup
in BlenRig.
Some of the tagging functions would be called for every operation, and then
in turn tag their ID nodes with all their operations again. With extensive rigs
we get ID nodes with a lot (10,000+) operation nodes, which leads to millions
of unnecessary tagging calls.
