The test for wire edges when reattaching was wrong, because
some newly made edges are wire at the point of the test.
This made some duplicate edges.
Need to track the original wire edges a different way.
This option (alongside the Ease In/Out/InOut options already available) aims to make it
easier to get an initial curve that looks closer to the one you were expecting, by
automatically picking whether Ease In or Ease Out should be used based on the type of
interpolation being used for the curve segment in question.
Notes:
* The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in)
* This does break compatability with files saved in previous dev builds, but only
if you were using Bounce/Elastic/Back with "Ease In"
This operator is used to make sure that if/when you have multiple strips
using the same action, if you select these and run this operator, each
strip will be given its own copy of the action. This is useful if you
decide later that you want to start using an existing action as a base.
NOTE: This does not recursively go inside meta's, so care is still advised
in that case.
This commit changes the default strip duplication behaviour (Shift-D) so that it will
create a copy of whatever action it uses. Previously, it was very hard, if not impossible
in some cases to create a new copy of an action to start working on in the NLA.
If you want the old behaviour, you'll need to use ALt-D (Linked Duplicates).
(Note: Although the new Shift-D may not be so optimal in all cases, I've decided to go
with this version since it aligns better with the way this works for objects. Doing the
opposite for NLA would just have added to the confusion)
Now code explicity excludes wire edges from beveling
and reattaches the wire edges to one of the newly
created vertices after beveling.
Also fixes a bug where vertex-beveling a wire-edge-only
vertex would not reattach the wire edges.
So that users opening a .blend saved in 2.70.5 and above in an older version
get warning the file might not be 100% compatible (should have been done
already for 2.70, actually).
Edit existing animsys_refactor module to make able to execute more complex conversions
('to' can now be a callback, instead of a simple prop name), and add a new
Update Animated Transform Constraints operator that uses it to handle complex
conversion for this constraint (drived or animated properties).
Note this operator has to be called manually (from 'space' menu), will make this clear
in release notes.
Also, similar changes made in 2.70 are *not* addressed by this script (would rather wrote
new operators as/if need arise, but Transform constraint looks much more sensible that the others).
This op should not remain in more than two or three releases anyway, imho.
Editing the y-coordinate of the right handle of a keyframe via the Active Keyframe
panel in the Graph Editor, while both handles are selected and are both of type "aligned"
resulted in weird behaviours such as the x-coordinate of the right handle changing
(and rapidly starting to overshoot) but nothing else. However, this problem
doesn't occur when only a single handle is selected.
It turns out that the "order of computation" logic in calchandleNurb_intern() gets
confused in the case of both handles being selected, and results in a sub-optimal
handling of the right handle being the one that's been changed. We hack around this
here by temporarily making it so that just the right handle is selected when doing
the updates here.
With the right handle selected, the movement of the left handle appears constrained
to the frame it is currently on, leading to unpredictable and wild overshoots of the
bezier curve. There appears to be little benefit in doing so.
The effect of this patch is that makes it so that instead of trying (initially) to
maintain the same distance between the two handles and then overshooting randomly
later, the handles now try to keep the same distance from each other (i.e. similar
doing a rotation around the keyframe) at all times. While this means that it isn't
possible to set up assymetric handles (i.e. where ease in to the key is less than the
ease out for example) using aligned handles (it's still possible using free; it's just
a lot more work to keep them aligned), the benefits of removing of the random blips and jumps
when things jump outweight the losses.
Patch by Brecht
This patch adds icons for each of the keyframe interpolation types (including
the easing equations), as well as icons for the easing type options.
Icons made by: Paulo José Oliveira Amaro (pauloup)
Reviewed by: Joshua Leung, Thomas Beck
This adds some view ratios in the video sequencer menu, based (copied) on the UV/Image Editor. It also fixes the inverted ratio issue reported in the same task.
Reviewers: #video_sequencer, #user_interface, schlaile
Reviewed By: schlaile
CC: jta, dingto, sergey, schlaile
Differential Revision: https://developer.blender.org/D447
Task: https://developer.blender.org/T37960
Thanks a lot :)
Those only cover the current set of brushes, soc-paint brushes will be
commited on that branch
* Buffer icons are usually in straight space (since we load from pngs)
so use src_alpha in OpenGL for blending.
* Allow blending for preview icons. This will be useful for the next
commit...
Make RNAPointer props un-editable here, we simply cannot handle this.
Also correct previous commit, asking for autonaming for all items was a bit extreme,
this is only needed for enums!
Broken enums widgets was a sequel of rBe5e0888a8f02 (when we want auto-naming,
we have to pass NULL, not and empty string!).
Now remains the RNApointers issue...
Text field part. Issue with enums dropdowns remains a mystery currently.
As for pointer fields, afaict they have never worked here, though it should
not crash.
UI_EMBOSS are values, not bitflags (own fault, most likely)...
Note we should probably get rid of UI_EMBOSST, it is used nowhere in UI code (set
in one place only, used nowhere).
This change makes lighting in GLSL preview more accurate, though it still
doesn't support material's "Exclusive" option.
Technical note: Changes in view3d_draw.c are not essential, these avoid
preparing unused shadow buffers.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D457
