| Age | Commit message (Collapse) | Author |
|---|
|
Also reminder to update docs w/ the API.
|
|
Also use simpler method to calculate the depth.
|
|
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.
|
|
|
|
depsgraph only)
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.
|
|
Unmeasurable speedup for plane intersection.
|
|
Unlike the 3 plane method, the 2 planes squared cross-product _is_ the determinant.
|
|
vectors
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!
|
|
anyway), than just return with un-initialized mat...
|
|
tris with ~1e-05 edge lengths would fail
|
|
|
|
|
|
Passing zero epsilon allowed divide by zero.
|
|
`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. ;)
|
|
These warnings are false-positives
|
|
We had too many warnings lately... was awaiting that someone would kill them - didn't happen -> goes to my commit ratio! :P
|
|
Support using custom pose-bone transform and object when calculating view bounds.
|
|
Logic was ok, but would run into precision issues.
|
|
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.)
|
|
normals_split_custom_set()
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).
|
|
In fact, any user of IMB_scalefastImBuf() is now robust against working
with really hires images.
|
|
Previously only polynomial model worked correct. now changing it to divisions
will work nicely as well.
|
|
Same issue as recent fix in ChannelMatte
|
|
Also modify a copy of argv
|
|
Issues re-initializing audaspace
|
|
|
|
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!
|
|
|
|
Caused subsurf to crash w/o OSD
|
|
|
|
|
|
Reported in T45978
Was checking mesh selection state.
|
|
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.
|
|
taken care of in draw functions.
Those iterate the whole PBVH tree so better avoid doing them, twice or
thrice.
|
|
|
|
Was an issue with individual-origins + snap
|
|
|
|
|
|
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.
|
|
|
|
Layers returned from items() and values() could have an invalid index.
|
|
Reported by Campbell on IRC, partial patch by him as well.
|
|
A non repeatable operator would disable editing options for all operators after it.
|
|
|
|
|
