| Age | Commit message (Collapse) | Author |
|---|
|
Definitions could shadow local vars.
|
|
Previously two laplacian smooth or deform modifiers executing
simultaneously could crash.
|
|
|
|
- use ED_ prefix for api calls
- use ED_*_select_pick for mouse selection (was already done in parts)
|
|
|
|
|
|
|
|
|
|
|
|
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. ;)
|
|
poselibs
This commit makes some tweaks that make it at least possible to use lib-linked
actions as Pose Libraries. Specifically:
* The apply poses button is no longer greyed out
* It is possible to select different poses from the list of poses
* All pose library operators which edit the poses stored in the poselib
now have improved poll callbacks which perform extra checks for lib-linked
actions (which cannot be edited, as all those changes will be lost)
Caveats:
* Due to the way the UI list template works, it doesn't seem to be possible to
make it not grey out the items in the list. (While the double-click to rename
thing shouldn't be allowed, items should at least look like they can be clicked on)
* The difference between clickable vs not-clickable isn't too great, making it hard
to tell that that while the Add/Remove/Sanitise toggles are not usable,
the Apply Poses is actually functional. But, this is a more of a UI-toolbox
level issue
|
|
By default watertight intersections are used,
For callbacks where its not needed,
BLI_bvhtree_ray_cast_ex can be called without the BVH_RAYCAST_WATERTIGHT flag.
Fixes T45286
|
|
This was already the case for most users of ray-cast.
Doing this avoids 2x normalize calls per ray-cast in many places.
|
|
|
|
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
|
|
The issue was caused by the following construction:
def = env['SOMETHING']
defs.append('SOMETHING_MORE')
Since first assignment was actually referencing environment option it was totally
polluted hawing weird and wonderful side effects on all other areas of Blender.
|
|
|
|
Weights were calculated using tessellation data, giving slightly uneven weighting.
Now only use tessellation for ray-cast but weight the influences from the original polygons.
Also cache arrays from derived-mesh, they we're called each intersection.
|
|
|
|
|
|
D1418 by @scorpion81 with edits
|
|
|
|
Had assert creating cheat sheet
|
|
We already had that for global keymaps (used e.g. to generate shortcuts for menu entries),
but this wasn’t possible for modal keymaps yet (e.g. help message in header during
transforms and other modal operation).
This commit only adds needing background code, it does not change anything from user PoV.
Modal operators will be updated to use it in comming weeks.
Thanks to Campbell for revisions & suggestions. :)
Differential Revision: https://developer.blender.org/D780
|
|
|
|
Our 'hard limit' values was too often max_int/float here, mis-typing could
lead to crash (or infinite hanging) of Blender, see e.g.
http://blender.stackexchange.com/questions/32790/blender-forces-computer-to-reboot-after-mistyping-extreme-value-for-resolution-i
|
|
Noisy and annoying with new gcc5...
|
|
after the current frame
This behaviour was confusing, since "selected keyframes" suggests that it covers
all selected keyframes (instead of trying to do this based on frame ranges).
|
|
Works like mesh dissolve (access from delete or Ctrl+X)
|
|
|
|
|
|
As used already for mesh & curves.
Add confirmation menu for curve & armature,
since this isn't such a common operation and undoing leaves object data
(long term bug/todo to fix).
|
|
|
|
|
|
Currently this function only tags pose itself, totally matching previous
behavior. But this will be needed in the future once new dependency graph
is landed, because of it's granular nature which relies on the fact that
pose channels are all up to date when building the graph.
Should be no functional changes so far.
|
|
in its invoke func.
|
|
|
|
* The breakdowner tool will no longer operate directly on properties
of type "enum", as this doesn't make sense most of the time. This
is still not much use though when custom properties (ints) are used
to drive some underlying enum property though (as in blenrig)
* The breakdowner no longer tries to perform any blending if the
start and end values are the same, to avoid float precision issues.
|
|
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
|
|
|
|
And some general style cleanup as well (line length...).
|
|
|
|
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
|
|
From the various forum threads and the fact that a new addon has cropped up,
it appears that it is not that well known that this tool exists, and that it
can be used solve a very common problem that animators face. Namely:
When you've gone through blocking out your key poses and then realise
that you need to adjust parts of the rig which don't change much, this
tool solves the problem of needing to go through doing grunt-work to
fix all the other keyframes which now need to change as well.
So, this tool is now available in the following two places (in addition to
the existing Pose -> Propagate menu):
* Toolbar - The "Propagate" button will use the default mode (or the last
used mode for each subsequent invocation).
The arrow-button beside this will allow choosing between the different
modes. (NOTE: The UI team may have different thoughts on this, but,
let's give this a try for a while first, to see if this sort of thing works)
* Alt-P - In Pose Mode, this will now bring up a menu allowing you to choose
which mode is used. Since this sort of thing is something that does
get run several times in a row when you need it, having this hotkey
will make it a bit more convenient.
|
|
This commit adds a new mode for the Propagate Pose tool. With this new option,
the Propagate Pose will copy the current pose over to all selected keyframes
after the current frame.
For reference, some of the other/existing options are: to copy it to each subsequent
keyframe with the same value (WHILE_HELD - the default), to the next keyframe,
or to the last keyframe.
|
|
|
|
|
|
Avoids complicated casts accessing as int
|
|
|
