As decided in D910, we use a new icon for incremental grid snapping and use its old one for absolute grid snapping.
This also touches the library_data_broken icon .dat files, seems some changes on its .svg entry landed in upstream without updating the other icon files (already noticed this when committing icon for auto-offset, but removed it from commit - leaving it in now to avoid further confusion)
Icon by @plyczkowski (made a tiny edit as it looked a bit blurry in 16x16). Thx!
Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes)
This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
When a modifier was animated by a NLA strip, this animation was not working when using
the old depsgraph. This was because the code which checks if a NLA strip affects any
modifiers was missing - specifically, it was originally left out as it was thought
that it was unlikely that many users would need this, but adding in those checks
would have a (slight) negative effect files where there are heaps of NLA strips
but modifiers animated this way were absent.
The new depsgraph however doesn't suffer from this problem, as these sorts of checks
need ot be built into the graph-building stage for everything to work, so these links
had already been added.
This was simply broken for vertex case (indexing loop normals with vert indices...).
Turns out to be rather verbose to replace on-the-fly zero normals by default ones correctly,
and do not want to make a full copy of the given custom normals array, so now this one is
editied in place (replacing zero vectors by correct default normals). Don't think this
could be a serious issue anyway.
That one was hairy... To summarize:
* We were setting Bone.head/tail (aka **local** rest location of bone) from EditBone data, using **EditBone's parent computed armature space**.
* We use those local head/tail to define Bone's restpose (in `BKE_armature_where_is_bone()`), using **Bone's parent armature space** (aka parent's arm_mat).
* Because of bone's roll nightmare, the two above parent's matrices will often not be the same.
In an ideal world, this should not affect locations (head/tail), but in real world of float it does - noticeably, in some extreme cases.
So! This commit cleans up things a bit (`fix_bonelist_roll()` was already doing much more than just fixing roll mess, has been renamed
to `armature_finalize_restpose()`), and ensures we do use (final!) parent's arm_mat local space to compute children's local head/tail as well.
This allows us to avoid too much imprecision here.
Checked the patch also with a complete Victor's rig from Gooseberry, seems to have no nasty side effects - fingers crossed!
`fix_bonelist_roll()` is already recursive, and was calling recursive `BKE_armature_where_is_bone()` twice!
Changed `BKE_armature_where_is_bone()` to controll whether we recurse over children or not.
With full Victor's rig, we gain 16% in `ED_armature_from_edit()` (from 31ms to 26ms).
With a dummy test-case 100 bones chain, we gain 80% in `ED_armature_from_edit()` (from 1.25ms to 0.25ms).
Not crucial, but still worth it. ;)
This causes no change in behavior, since code was alreadying doing
a no-op in bmesh_edge_separate if the edge is a boundary.
But it tripped an assert, annoying in debug builds.
We want to leave assert in bmesh_edge_separate in case callers
expect there to be separate loops after this always.
So putting test in caller.
(Same worry about bmesh_urmv_loop? I checked callers and they
appear OK to me - they deal with the no-op return.)
The detection of needed sharp edges (based on given loop normals) would not fully work
on first run in case we started with a complete smooth cyclic loop fan (edge between
first and last loop of the fan would not get checked).
get_keyframe_extents() would add an extra frame in case of mono-key fcurves in selected set...
Now do the 'not same start/end frames' check later, and also use floor/ceil instead of round
(we want to start at frame 3 if first key is at frame 3.8, reversed-same goes for end frame).
Since data transfer when called from this tool has reversed behavior (it transfers **towards**
active object, as previous tool), we have to also reverse source/destination layers selection options.
Also fix 'reverse' option being saved, otherwise calling regular operator after 'transfer weights'
would stay in reverse mode, ugly!
Raw int pixels can be nice in some cases (much less memory used), but converting to/from float values
(as e.g. expected by/from Image) is not simple in py, error prone and rather slow.
triangles.
This made the normal-related artifacts of projection painting much more
apparent. Now we do culling based on
whole polygons. Pure backface culling still uses individual
triangles.
