This reverts commit 6cc5bdc99e.
Revent this for 2.70a, it changes behavior too much without allowing
keyframe handles to be scaled some alternative way.
Summary:
The title actually says it all, it's just possible to
have independent free handles for mask splines. Also
it's now possible to have aligned handles displayed
as independent handles.
Required changes in quite a few places, but they're
rather straightforward.
From user perspective there's one really visible change
which is removed Handle Type menu from the panel. With
asymmetric handles it's not clear which handle type to
display there. So now the only way to change handle type
is via V-key menu.
Rewrote normal evaluation function to make it deal
with new type of handles we support. Now it works in
the following way:
- Offset the original spline by maximal weight
- Calculate vector between corresponding U positions
on offset and original spline
- Normalize this vector.
Seems to be giving more adequate results and doesn't
tend to self-intersect as much as old behavior used to,
There're still some changes which needed to be done, but
which are planned for further patch:
- Support colors and handle size via themes.
- Make handles color-coded, just the same as done for
regular bezier splines in 3D viewport.
Additional changes to make roto workflow even better:
- Use circles to draw handles
- Support AA for handles
- Change click-create-drag to change curvature of the
spline instead of adjusting point position.
Reviewers: campbellbarton
CC: sebastian_k, hype, cronk
Differential Revision: http://developer.blender.org/D121
Transform operators for nodes were not taking parent nodes (frames) into
account. Now use the nodeToView/nodeFromView functions to apply
transforms in local node space.
There were 3 bugs with both data types
- using freed memory while sorting.
- sorting failed in some situations.
- scaling allowed multiple items to be on the same frame.
Replace this with a simple sort + de-duplicate, taking selection into account.
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,
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...
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.
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
The problem here was that the hack used to fix T24551 in r32863
would cause the camera to jump back to its pre-transform position
after motionpaths were recalculated. This made it seem like a keyframe
wasn't inserted by AutoKeying (even though it was).
