Recently on the bf-funboard list, there have been some requests for clearer
indications for animators that autokeying has been enabled when transforming so
that corrective action can be taken sooner if this wasn't expected. This is
especially important in distributed+collaborative environments where multiple
artists may work on a single shot file: someone working on a shot from
another animator may not be aware that autokeying was enabled, thus accidentally
setting a whole bunch of extra keyframes.
In this current incarnation, we display using red (not hardcoded, but using an
existing theme color) a solid 1px border around the 3D view while transforming
with autokeying enabled. In addition to the border, a blinking indicator (record
icon + "Auto Keying On" text) appear in the top right corner, as inspired by the
traditional recording indicator icons on camcorders.
- make view3d project names more consistent.
- remove apply_project_float() its not needed.
- update comments referencing an old function name.
- move doxygen docs into the C file, prefer they are kept here to avoid getting out of sync with code.
Fix deadlock in drawArc caused by precision error. Helper widget could
look wrong, that's because of not enough precision of floats used by
Blender.
This is known issue of Blender and wouldn't consider a bug.
Only visible edges are used to create the "sliding vector". The test used to detect whether edges were visible or not was working for solid shading, but useless in wire draw mode (as all edges are visible in this mode!)...
This commit adds "shift" and numtype to both Bevel and Inset mesh operators.
It also gets rid of the magicnumber used in NumInput to str operation (currently, 20 chars per element, now defined as NUM_STR_REP_LEN in ED_numinput.h).
Issue was caused by the code which checked whether snapping should be enabled
on transform init taking into account keymap and special keys state. It was
used for Ctrl-Click on manipulator only.
Check for Ctrl state gave wring result with skin modifier. It was solved
by additional check for which mode transformation is initializing for --
currently manipulator is available for translation/roation/resize only
which doesn't give any keymap issues.
The transform operators in nodes will now use the unselected nodes to generate snapping points. Unlike object snapping, node snapping works for the x/y axes separately and snaps node borders to same borders of unselected nodes. The sensitive area for node borders extends over the whole view2D range, to enable simple alignment of nodes in both x and y direction.
For snap points in the node editor an additional enum value is stored to indicate the type of node border (left/right/top/bottom). This works as a constraint on possible node alignments: only same border types align with each other.
Snapping actually was working already, but grid spacing was set to 1.0, which is basically pixel size in the node editor. Increased this to 1x grid step for fine snapping and 5x grid step for rough snapping.
Grid drawing in node editor now draws 2 levels in slightly different shades to indicate the different snapping modes better.
Node editor also supports the general use_snap tool setting to enable automatic snapping during transform. For now only the incremental snapping is supported, in future could be extended to enable alignment between nodes in a number of ways.
Issue is that all loops of a face adjacent to the sliding verts were
getting project-corrected. Introduced a test to only project the
affected loops.
The projection code introduces a small offset to the boundaries so that
any boundary tests can work as expected, but this leads to shrinking of
the barycentric coordinates of the projection, causing a shrink of the
uvs in turn. This even affects the uvs that -should- be affected though
the unfixed behavior works strangely in a correctish way (my guess is
because the projection uses the same face as the opposite sliding loop).
I fixed the behaviour by taking the mean value of the uvs. This won't
support seams but current code doesn't either. Also, all CustomData to
exhibit this unfixed behaviour. I only fixed the uv case, other data
(Vcolors, etc) will have discontinuities when edge sliding. I expect
that the CorrectUV code I am working on may address some of these
issues.
Also, added NULL checks for utility function (was intended for this bug
but wasn't needed after all)
- Remove clip/mask specific size/aspect getters, they shall just
use the same size/aspect ratio.
- Made size getter (and some other public functions) accept context
instead of SpaceClip. Currently only SpaceClip is being get from
this context, but later it'll be helpful when adding support of
editing mask without opening clip in clip editor (in this case
using render resolution for mask would be ideal, but this
requires knowing scene in size getter).
- Rearrange some functions in clip_editor.c for easier navigation
in the file.
