Just remove that rotation special case for now, at least fixes the glitch along Z axis when rotating around Y axis in report.
Anyway, there is no reason for such special handling, we do not have real rotation in editbone...
This commit hopefully fixes all glitches we had when bone was Z-aligned. Note that when you init a transform
with a Z-aligned bone and change it to be non-Z-aligned, you will still get some brutal roll change,
there is not much things we can do here afaik...
Basic idea is now to have the transformes bones keep "facing" the armature's Z axis, see comments in code for details.
That might not be ideal, but at least we now have humanly predictable and consistent results.
Disable transform and mask display when there's no active clip.
It's not a matter of returning fallback dimensions if there's no
slip, it's also matter of making it so stabilization and distortion
routines are aware of clip == NULL which is really crappy.
Also almost all the operators are disabled in clip editor without
active clip already anyway.
Also tweaked header UI a bit to not display mask stuff when there's
no active clip,
Use Z axis for the edge direction for edges and vertex pairs.
Issue raised in T38592, now edge select and vert-pairs share logic
for calculating orientation and the active vertex determines direction.
Issue was in fact in strip update code when transforming, in case we move both left and right
handles the strip is handled twice in the loop, but it was always updated at the end of the
first loop only...
Issue partially caused by own errors (glicth in new BKE_boundbox_ray_hit_check() code causing segfault in volume snapping,
and we have to treat ortho and persp differently in case of face snapping, because in persp our ray_start might very well
already be *inside* the boundbox of the checked object), and partly due to the fact that ED_view3d_win_to_vector()
was returning wrong vector (negated one) for ortho views (see previous commit).
Also allowed me to fine another potential issue, hit.dist was no more initialized correctly - and I had forgotten to take into account Brecht's remark about normalize_v3() also returning the vector's previous length.
Issue is caused by start point of ray used to detect faces under the mouse is set rather far away in ortho 3dviews.
The loss of precision on the ray location induced by this can lead to face snapping failures.
Solution is to do the raycasting with a temp start point, much closer to the object we check, and add back
to the found distance the diff to the real start point once detection is done (as we need all hit distances
from all tested objects to be relative to a common point!).
Note this commit only addresses the "face snapping on mesh" case, other kind of snapping do not seem to suffer
from this issue.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D268
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
During drag the H key can be used to toggle the hide flag of the selected nodes.
This makes it easier to 'attach' nodes to available links in narrow places.
Because of the issue of how simplification works, there could
be more flags in on->recalc bitfield which are ignored by object
anyway.
Would save some update calls after simplificating the scene.
It was actually rather simple to make sure depsgraph is up to date
before calling BKE_object_handle_update() in the transform code by
just moving DAG_scene_relations_update() to the beginning of the
function.
Wouldn't expect any side effects for other cases since DAG is not
used bu the code between new location of the call and old one.
This is a regression since threaded dependency graph landed to master.
Root of the issue goes to the loads of graph preparation being done
even if there's nothing to be updated.
The idea of this change is to use ID type recalc bits to determine
whether there're objects to be updated. Generally speaking, we now
check object and object data datablocks with DAG_id_type_tagged()
and if there's no such IDs tagged we skip the whole task pool creation
and so,
The only difficult aspect was that in some circumstances it was possible
that there are tagged objects but nothing in ID recalc bit fields.
There were several different circumstances when it was possible:
* When one assigns object->recalc flag directly DAG flush didn't
set corresponding bits to ID recalc bits. Partially it is fixed
by making it so flush will set bitfield, but also for object
types there's no reason to assign recalc flag directly. Using
generic DAG_id_type_tag works almost the same fast as direct
assignment, ensures all the bitflags are set properly and for the
long run it seems it's what we would actually want to.
* DAG_on_visible_update() didn't set recalc bits at all.
* Some areas were checking for object->recalc != 0, however it is was
possible that object recalc flag contains PSYS_RECALC_CHILD which
was never cleaned from there.
No idea why would we need to assign such a flag when enabling
scene simplification, this is to be investigated separately.
* It is possible that scene_update_post and frame_update_post handlers
will modify objects. The issue is that DAG_ids_clear_recalc is called
just after callbacks, which leaves objects with recalc flags but no
corresponding bit in ID recalc bitfield. This leads to some kind of
regression when using ID type tag fields to check whether there objects
to be updated internally comparing threaded DAG with legacy one.
For now let's have a workaround which will preserve tag for ID_OB
if there're objects with OB_RECALC_ALL bits. This keeps behavior
unchanged comparing with 2.69 release.
When trying to scale bones in EditMode and the bones were drawn using envelope display mode,
this resulted in the joint radii (i.e. the inner part of envelopes) being adjusted instead.
It turns out that this was due to an old hack that was put in place back in 2.4x (see the
tracker logs for full details of the problem here).
This commit introduces the following fixes:
1) Removed the old hack. Scaling (S) works normally now.
2) Ctrl-Alt-S (i.e. "Scale Envelopes/BBones") is as-is.
That is, it is used to adjust the size falloff-region around a bone
(i.e. the "dist" property)
3) Added Alt-S hotkey in EditMode for armatures for adjusting the radii of bones.
This change just means that the "TFM_BONE_ENVELOPE" mode is now able to be
accessed from the UI as a tool on its own right (instead of being accessible
via the old undocumented hack). This tool adjusts the radii of the bone joints,
which define the actual full-influence region of the envelopes.
