Find free slot first for sound strips then for movie strips.
This patch also fixes issue where all strips were added to channel 2 by default.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8339
The weight must be added only to the real points, not to the autogenerated points by modifiers. This affects, not only to subdivide, but to any modifier that generate points.
The root of the issue comes to the fact that sub-data pointers were
used to match strips before/after copy-on-write. The undo system might
re-use sub-data pointers after re-allocating them, making it so that,
for example, pointer used by sound strip is later re-used by video
strip.
This fix takes an advantage of recently introduced per-sequence UUID
and uses it to match sequences before/after copy-on-write.
Will trigger code paths which makes sure UUIDs are generated and
are unique.
Enabled with --debug-depsgraph-uuid (which is also implied by
--debug-depsgraph).
This is the first step for having sequences covered with session UUID
with the goal to remove code which uses original sequence pointer to
match sequences.
Currently this UUID is maintained on file load, allocation and leaf
duplication function.There are more cases to cover and ensure UUID
is re-generated or re-used when needed. It will be done as follow-up
development.
Allows to use pre-defined structure for session UUIDs in all data
structures which needs it: pose channels, sequencer strips, modifiers.
The goal of all this is to have a reliable way of matching original
and copy-on-written versions of data, so that it's possible to
preserve runtime caches.
button
This was reported for the FCurve modifier restrict ranges, but might fail
elsewhere, too. Reason is that the post_but has its range (hardmin/
hardmax etc) set before the updates to the active button take place, so
changes here dont end up on the post_but (even though the RNA range
function is properly called for a new defined button - new one is not the
same as the post_but though).
Now update the ranges on the post_but when that gets active.
Fixes T78763
Maniphest Tasks: T78763
Differential Revision: https://developer.blender.org/D8265
These were added in rB146473f08335e8cb774ccaf1baad82a1d308fbe1 however
there were a few errors with the labels:
1. Underscore in label
2. Abbreviation when not needed
Collection instance datablocks were not filtered out when only showing
the selected object. They were treated as a collection (which should
show when filtering objects). Adds a case to check if the parent is an
object.
Caused by {rBa1a333a1e92e}
`BKE_sequencer_prefetch_get_original_sequence` cant get a sequence in
`BKE_sequencer_cache_put`.
rBa1a333a1e92e moved multiple NULL checks (including the one checking
seq) above BKE_sequencer_prefetch_get_original_sequence (this should
never return NULL really, but this is for another fix).
So solution suggested by @ISS is to just stop prefetching all together
before changing content of seqbase.
Maniphest Tasks: T79357
Differential Revision: https://developer.blender.org/D8421
This is part of T79273 where separating a stroke would result in
multiuser gpencil data for the original object.
Real underlying issue seems to be that gpencil multiuser objects (also
the ones created by Alt+D duplicating) have a problem evaluating
modifiers correctly [this will need further investigation].
Not sure if this is a limitation of D5470?
This patch only corrects the usercount on separating [which already fixes
the scenario reported because singleuser gpencil modifiers work
correctly].
Note: we could have also called `ED_object_add_duplicate` with the
`USER_DUP_GPENCIL` dupflag -- that would have taken care of the usercount
--, but then the whole following logic in `gpencil_stroke_separate_exec`
would need to change from **adding** layers/frames/strokes to
**removing** these.
Part of T79273
Maniphest Tasks: T79273
Differential Revision: https://developer.blender.org/D8419
This uses mesh's runtime mutex for both `BKE_mesh_runtime_looptri_ensure`
(was using its own global RW mutex before), and `BKE_mesh_wrapper_ensure_mdata`
(was not protected at all before).
This is more like a band-aid than a proper fix, as mentioned in the report
proper fix would be for the modifier to request those data (the relevant
BVHTree, which would implicitely also call the tow others) through flags,
just like it does for regular CDData layers. But this is a much bigger
refactor to be done outside of bugfix scope.
Reviewed By: sergey
Maniphest Tasks: T78285
Differential Revision: https://developer.blender.org/D8415
Previously, gravity was only applied in the real brush radius, not in
the whole simulation radius. For most deformation modes, applying
gravity to the entire simulation instead of just to the brush radius and
scaled by the radius (like a regular sculpt brush) makes more sense.
After this fix and with the cloth collisions patch applied, it is possible
to do things like this with the cloth grab brush.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8406
As the comment says, anchored stroke can't rely on the first stroke
iteration for creating the simulation data. Probably lost in a cleanup.
I also made that anchored stroke doesn't restore the mesh state in the
cloth brush, so it can create the simulation effect.
Reviewed By: sergey
Maniphest Tasks: T79054
Differential Revision: https://developer.blender.org/D8348
The final render will use scene resolution in this case.
For example, when Color Input is plugger to preview and composite output
nodes, final render will flood-fill the final image which is a size of
scene resolution with this color. Before this fix the node preview was
empty. After this fix the node preview will be flood-filled with the
color.
Fixes T78586
Differential Revision: https://developer.blender.org/D8263
Were two issues:
- Divider was calculated in integer domain, causing rounding issues in
general case, and causing singularity in a corner case when input is
smaller than the preview size.
- The resolution was scaled down by 1 pixel for no obvious reason.
This was fine in those cases with current code, but that kind of
assumption is always risky, and an open door to hard-to-track bugs when
code changes in the future...
Build a temp matarray storing materials from obdata and source object
(depending on slots 'allocation' of source object), and assign those to
targets.
Also remove limitation of 'using same obdata is forbidden', just never
edit obdata materials in that case...
Certainly not perfect, but already much better than existing code.
