The change was kind of intentional on {rB21e72496a629}.
That commit made mouse movement to "select" the contraint in Auto
Constraint a requirement.
This deduplicated the code a bit, but this requirement is not
comfortable for the first "selection" of the contraint.
So the constraint "selection" is now done in two ways:
- If there is no contraint, the "selection" is done immediately;
- If there is already a constraint, the "selection" is delayed by 1 event to simulate a constraint cancellation if there is no mouse movement.
In rare cases the mesh has not been evaluated when snapping, this fix
just prevents the crash as is done elsewhere in Blender when the
evaluated mesh isn't available, there is a separate report (T96536)
about evaluation not working properly.
This was reported explicitly for originally being in face selectmode,
but could also crash when in vertex selectmode (when doing multiple
cuts).
The reason here is that `MESH_OT_loopcut` switches to edge select mode
(needed for `TRANSFORM_OT_edge_slide`, done in `ringsel_finish`), but was
only doing this on the active object's editmesh, all other participating
meshes would keep their selectmode which would now be out of sync with
both the active object's editmesh and scene settings for these.
This causes problems later in 'Select Linked'. Here, a mixture of
objects are used. First the viewcontext is set up with the active
object, then all participating objects are iterated (changing the
viewcontext to another object), then `unified_findnearest` would use that
changed viewcontext which would now contain the last object iterated. To
repeat: this could now have a different selectmode than the active
object which is later **again** used to get the nearest `BMElem` from in
`EDBM_elem_from_selectmode`. So in the failing case, we could get an
edge (but no face because of edge selectmode) from `unified_findnearest`,
`EDBM_elem_from_selectmode` would return NULL though (edge provided, but
in face selectmode), leading to the crash.
To solve this I assume it is best to change selectmode on all
participating meshes in multi-object editmode loopcut if necessary so
these are always in sync for following operations.
Alternatively, `Select Linked` (and probably lots more operators) would
have to be tweaked to pay closer attention which object is really used
to get selectmode from.
Note the selectmode is actually set back from edge selectmode in certain
cases (see `USE_LOOPSLIDE_HACK`), this patch changes that as well to act
on all participating meshes.
Maniphest Tasks: T95752
Differential Revision: https://developer.blender.org/D14791
Recent cleanups 9a8669ac81 and 1c790555a0
incorrectly interpereted the bitfield width syntax as a default
value. Also resolve two other compilation warnings.
When height is limited, it is defined by space occupied by strips,
but at least channels 1 to 7 will be always visible. This allows it to
easily overview timeline content by zooming out to maximum extent in Y
axis and panning in X axis.
More channels can be "created" on demand by moving strip to higher
channel. When strip is removed and highest channel becomes empty, view
will stay as is until it is moved down. Then new highest point is
remembered and it is not possible to pan upwards until strip is moved to
higher channel.
Limiting takes into account height of scrubbing and markers area as
well as scrollers. This means that when zoomed out to maximum extent,
no strips are obstructed by fixed UI element.
Fixes T57976
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14263
This patch adds the drag and drop strip previews in the VSE.
It also adds two new functions to the drag and drop API.
1. "draw_in_view" for callbacks that wants to draw elements in local viewport coordinates
2. "on_drag_start" that can be used for prefetching data only once at the start of the drag.
Reviewed By: Julian, Campbell
Differential Revision: http://developer.blender.org/D14560
Changes:
- Remove `BLI_memarena` (Use `MEM_cnew` and `MEM_delete` to allocate cached data)
- Implement `snap_object_data_mesh_free_ensure` and `snap_object_data_editmesh_free_ensure` and skip need to get original key Object for editmesh data
- Use `BMEditMesh` as key for editmesh `Ghash`
- Make a better distinction between `SnapObjectData`s. (`SnapData_Mesh` and `SnapData_EditMesh`)
The editing data of a `SURF`s is similar to that of Curves and should be supported for snapping.
But unlike Curve objects, for snapping, only support the nurb points if the object is in edit mode.
This matches the solution for Meshes and avoids having to create a kind
of "boundbox" for the SURF nurb points.
The problem is old.
rB52be06301257 (fixed by rB4b35d6950d4f) just masked it.
`Object->data`, on evaluated objects, is not a safe pointer to get
objects with the same `BMEditData`.
Use `Object->runtime.data_orig` instead.
Since effect strips can't be transformed directly, their selection had
to be forced in order to process them. This often failed in more
complicated scenarios, because there was no attempt to parse hierarchy
completely. In worst case only one effect in chain would be selected.
This code was marked by `XXX_DURIAN_ANIM_TX_HACK`.
Instead solution described above, a collection of strips that depend
on non effect strip position is built by function
`query_time_dependent_strips_strips` and it is stored in `TransSeq`.
In `flushTransSeq` this collection is iterated and transformation offset
is applied to effect strip animation. Strips in collection should be
consistent with true state of dependency and should be complete.
Functional changes:
- When 2-input effect strip changes position, animation is offset even
if only handles are moved. This only applies to 2-input effect however.
- Selection is not extended to include effect strips anymore. If effects
are to be moved, they must be selected manually. This is because
previously it was very hard to reorganize effects in chain, since moving
first strip in chain would always select anywhere from 1 to n effects.
So creating or filling gap in channel would almos always result in
collision especially if their order in timeline doesn't perfectly
represent their order in chain.
The `BVHCacheType bvh_cache_type` parameter defines specific
`BVHTrees` that cannot be customized.
So it doesn't make sense to pass this value to any
`*bvhtree_from_[...]_ex` function as the `BVHTrees` created in these
cases are custom and cannot be saved in the cache.
This also resulted in a nice cleanup in the code.
Differential Revision: https://developer.blender.org/D14479
Add edge panning feature to transform operator. It works in same way as
in node editor, but Y axis is limited by usable range up to 128
channels.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14310
This patch adds channel region to VSE timeline area for drawing channel
headers. It is synchronizedwith timeline region. 3 basic features are
implemented - channel visibility, locking and name.
Channel data is stored in `SeqTimelineChannel` which can be top-level
owned by `Editing`, or it is owned by meta strip to support nesting.
Strip properties are completely independent and channel properties are
applied on top of particular strip property, thus overriding it.
Implementation is separate from channel regions in other editors. This
is mainly because style and topology is quite different in VSE. But
also code seems to be much more readable this way.
Currently channels use functions similar to VSE timeline to draw
background to provide illusion of transparency, but only for background
and sfra/efra regions.
Great portion of this patch is change from using strip visibility and
lock status to include channel state - this is facilitated by functions
`SEQ_transform_is_locked` and `SEQ_render_is_muted`
Originally this included changes in D14263, but patch was split for
easier review.
Reviewed By: fsiddi, Severin
Differential Revision: https://developer.blender.org/D13836
Replace 5 arguments with a single struct as the same arguments
are used in many places.
This didn't read well and was confusing with both arguments named
`val` & `value` in the case of WM_modalkeymap_add_item.
Also solves two warnings from the previous similar commit,
f688e3cc31. The change to the grease pencil
modifier is quite suspicious, but doesn't change the behavior,
which was already broken.
Add new `BKE_id_is_editable` helper in `BKE_lib_id.h`, that supercedes
previous check (simple `ID_IS_LINKED()` macro) for many editing cases.
This allows to also take into account 'system override' (aka
non-editable override) case.
Ref: {T95707}.
Regression in [0] error iterating over pose bones which only used the
active-object, also follow the same logic as edit-mode for using the
local-matrix.
[0]: d052169e7e
This is meant to allow using C++ data structures in this file
as a performance improvement. Particularly `Vector` instead
of `ListBase` for `duplilist`.
Differential Revision: https://developer.blender.org/D14475
If the `Automatic Constraint` modifier was activated while an axis
constraint was already set, the orientation used would be the default
orientation of the mode and not that of the scene.
This was because the `initSelectConstraint` function was not called in
this case and the `Automatic Constraint` mode was enabled by other
indirect means.
So the solution is to call `initSelectConstraint` in either case and
remove these "indirect means" of enabling `Automatic Constraint`.
Contrary to the initial intention (in rB9916e0193c36), `TREDRAW_SOFT`
flag, when isolated, is not cleared in `transformApply` and therefore is
used in the `drawTransformApply` callback which basically recalculates
the `transformation` which finally clears the flag.
So remove the `drawTransformApply` callback so `transformApply` is not
called when unnecessary.
Differential Revision: https://developer.blender.org/D14430
The solution supposedly listed all cases that `absolute grid snapping`
was supported. But it ignored some occasions like: Editing Surface
objects, Texture Space.
List now only the cases where this feature should not be supported.
This was a mistake in the conditional structure introduced in 4b35d6950d
This commit also adds a new type of snap exclusion: `SNAP_NOT_EDITED`.
Thanks to @Ethan1080 for pointing out the error.
