BLI code for enums that are meant to be used as "bit flags" defined
an ENUM_OPERATORS macro in BLI_utildefines.h. This cleans up things
related to said macro:
- Move it out into a separate BLI_enum_flags.hh header, instead of
"random bag of things" that is the current place,
- Update it to no longer need manual indication of highest individual
bit value. This originally was added in a31a87f89 (2020 Oct), in
order to silence some UBSan warnings that were coming
from GPU related structures (looking at current GPU code, I don't
think this is happening anymore). However, that caused actual
user-visible bugs due to incorrectly specified max. enum bit value,
and today 14% of all usages have incorrect highest individual
bit value spelled out.
- I have reviewed all usages of operator ~ and none of them are
used for directly producing a DNA-serialized value; all the
usages are for masking out other bits for which the new ~
behavior that just flips all bits is fine.
- Make the macro define flag_is_set() function to ease check of bits
that are set in C++ enum class cases; update existing cases to use
that instead of three other ways that were used.
Pull Request: https://projects.blender.org/blender/blender/pulls/148230
PRs #147511 and #147595 ensured that any check for scene strip renders
in the prefetch thread would also recurse into "sequencer-type" scene
strips, but this introduced the potential for an infinite recursion.
Fix by using `SeqRenderState` to detect such a recursion.
Also remove unused `seqbasep` context member in `PrefetchJob`, and
add a check for non-nullptr `Editing`, fixing a crash where the scene was
present without an `Editing` counterpart.
Pull Request: https://projects.blender.org/blender/blender/pulls/147949
It was requested to allow strips inside of meta strips to be used as
masks for modifiers. There is need for mask is to be shared between
multiple strips in multiple meta strips. More discussion is in #146970.
Pull Request: https://projects.blender.org/blender/blender/pulls/148097
Currently, the scene strip preview uses the existing dependency
graph built for that scene. This was not a big issue before
the sequencer scene was introduced, because the user would have
to create two main Blender windows to run into problems.
Now with the sequencer scene, it's possible to look at the scene
of a scene strip within the same window.
When the user is editing the scene (e.g. moving an animated object)
any open sequencer preview will cause the edits to be flushed.
This can e.g. result in visual jumping of animated objects, and more.
This PR attempts to fix the issue in a straightforward way: Use
a separate dependency graph for rendering the sequencer preview.
While this fixes the immediate issues, there are some consequences:
* The memory usage of the scene dependency graph _can_ roughly
double (since there are now likely two instances of the same
dependency graph). Because of implicit sharing, unmodified data
will not be copied. But for example modifiers on meshes would
currently create two copies of the evaluated data in the two
dependency graphs.
* Creating the dependency graph can be costly, which will cause the
first frame that the scene has to render to be slower.
Note: The current code changes some properties of the original scene
like the frame, subframe etc. before rendering and then restores
the original state. In theory, this part of the code can be removed,
but may be a bit too risky for just a fix. This should be improved
at a later stage.
Also resolves#146769, #139501.
Pull Request: https://projects.blender.org/blender/blender/pulls/147457
The final image produced by the compositor can have domain translation
on it (e.g. caused by a Translate or Transform node). Similar to how
the regular compositor viewer node remembers the output domain
translation, do the same in the compositor modifier.
Bubble back that translation up to VSE rendering code, where it is
then added to regular strip transform.
In order to make this "bubble up" part easier, refactored modifiers
so that instead of soup of parameters they all get a struct
ModifierApplyContext with all the relevant data.
Added a new VSE render test that covers various compositor
transformation nodes (translate, rotate, transform, corner pin).
Pull Request: https://projects.blender.org/blender/blender/pulls/147695
These types of buttons do not automatically extract and translate the
label when specified specifically. This commit adds the missing
translation macros.
Some issues reported by Alexandr Fatih.
Fix done in 7805a4bfe1 introduced another crash - null dereference when
accessing `strip->scene`.
Also the mentioned fix was not quite correct, because it used incorrect
scene and timeline frame to get rendered strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/147595
Check if 3D render would be done by recursing also into sequencer
timeline used by scene strips.
This PR removes check if the scene strip is cached. This was used to
allow rendering from disk cache, but it was removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/147511
Currently when a strip has a transform that does not fill the whole
render area, first the image of the strip is transformed, and then
any modifiers are applied on that. This is mostly in the new
Compositor modifier, where procedural textures, gradients, image
coordinates "stick to the screen" instead of following the transformed
strip.
This changes the behavior so that first the modifiers are applied
to the strip image, and then the strip is transformed. This is
potentially a visually breaking change:
- This can alter visual look of existing strip, especially if they are
scaled. Previous behavior was first scale filtering, then modifier;
now it is first modifier, then scale filtering.
- Most obvious change is Compositor modifier (which is new in 5.0).
- Compositor modifier can actually expand the input image (e.g. Blur
node with "expand bounds" option set), and that works.
- Note that Masks continue to be applied in global/screen space. There
can be small look differences with rotated/scaled strips that use
masks, due to Mask application now needing to do filtered mask image
lookups.
- If anyone needs previous behavior (modifier is applied on the
"whole screen"), they can put transformed strip into a meta strip,
and apply the modifier on the meta strip itself.
Compositor modifier examples with images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146181
If a VSE compositor modifier is used to do keying or introduce an alpha
somehow to the image, the alpha is not used when blending. This is
because the VSE evaluator assumes all modifiers except Mask could not
introduce an alpha channel. So we need to extend the check to also make
an exception for the compositor modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/147456
Using a strip mask in a compositor strip modifier causes other strips to
change in color. This is because the code converted the mask image
buffer in place, which affected its other uses. To fix this, convert the
mask out of the place.
Pull Request: https://projects.blender.org/blender/blender/pulls/147446
The function name `for_each_callback` is ambigous (what are we iterating?)
and also doesn't align with the naming of other "for each" functions in Blender
which usually are named `foreach_<thing>` like `IndexMask::foreach_index`
or `animrig::foreach_fcurve_in_action` etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/147440
Any keyframes for properties inside the compositor node
trees that were used by strips did not show up in the dopesheet.
This was because the compositor tree is its own ID and needs to
be manually added by the dopesheet code.
This fix adds the node trees to the filtering code in
`animdata_filter_dopesheet_scene`.
Note that the dopesheet still uses the active scene as its context.
So this means that if the sequencer scene differes from the active
scene, the animation data from the sequencer scene will not
be shown. This is currently expected behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/147301
Goal of this PR is mainly to improve flexibility and of VSE layout and
screen space efficiency.
Previously, strip properties were displayed in timeline sidebar. This
was limiting, because if you want to display as much properties as
possible, the timeline area had to be taller, but this was at the
expense of space available for preview. However there is plenty of
space in properties editor, which is mostly unused in VSE. Therefore
strip properties were moved to the properties editor.
ID pinning and path displayed in top section aren't drawn, since strip
is not an ID and can not be pinned. Since there is more space for
properties, various panels are changed to be open by default.
Mainly transform and time panels, since they are used often.
There is one minor change: The waveform display property
of sound strip was previously hidden, if timeline area had per strip
waveform display overlay set. This is no longer possible to do and the
property is always visible.
Pull Request: https://projects.blender.org/blender/blender/pulls/140395
Add sound pitch correction functionality, so that retimed sound strips
can preserve their original pitch.
This has been implemented as a GSoC 2025 project. Actual pitch
correction is done with Rubberband library, which has been already
included into Blender 5.0 library builds; and then most of the other
code has been in Audaspace, which was already updated within Blender
tree earlier.
So this PR just flips on Rubberband build option, and adds the
checkbox to VSE sound strips for pitch correction (on by default for
newly created sound strips). Pitch correction works with both
simple whole-strip retiming, as well as more complex retiming setups
where different parts of the strip use different speeds.
Co-authored-by: Aras Pranckevicius <aras@nesnausk.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/143347
Functionality has been replaced by strip transform properties. Transform
strips in existing files will be replaced with gaussian blur with radius
of 0 to preserve modifiers and overall strip stack.
Pull Request: https://projects.blender.org/blender/blender/pulls/147003
Currently, attempting to split connected strips that are not both
selected means that only one of the strips are affected. This violates
the "connected" principle, so this PR makes the split operator propagate
the split to connected strips by default. Holding alt returns old
behavior (ignores connections), similar to selection logic.
Pull Request: https://projects.blender.org/blender/blender/pulls/146380
When a strip modifier uses an adjustment layer that is above it
as the mask input, this leads to recursive rendering. Similar to the
fix in !146624, pass SeqRenderState to modifiers as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/147029
This patch makes a distinction between passes accessed through nodes
like the Render Layers node, and inputs accessed through nodes like the
Group Input node. Previously, the Group Input node returned the passes
of the active scene and view layer accordingly to the name, while now,
it only returns the Image (Combined) pass and the result will be zeros.
Pull Request: https://projects.blender.org/blender/blender/pulls/146831
To support setting the custom `CurveMapping` to a well defined preset,
there exist a number of operators that are hardcoded to apply a
particular preset to a particular curve.
This commit begins to replace this functionality and make it part of the
template itself, allowing the preset to be applied to any curve. For
now, it only supports either positive or negative slopes, primarily for
the brush usecases.
The `brush.curve_preset` and `brush.sculpt_curves_falloff_preset`
operators are unneeded after this change and have been removed.
Notably, these preset controls have not been added elsewhere, they can
be added on a case by case basis in future commits by interested
modules.
Pull Request: https://projects.blender.org/blender/blender/pulls/146847
Caused by 866fcd0a09
To search for strips, we do so on an `Editing` object or a `MetaStrip`
object.
Code from 866fcd0a09 got the `MetaStack` but then tried to use this
directly as a `MetaStrip`.
We should be getting its `parent_strip` though it seems.
For reference, this is what was done prior to 866fcd0a09
`sequences_object = ed.meta_stack[-1]`
Pull Request: https://projects.blender.org/blender/blender/pulls/146967
This patch adds a new Compositor modifier that applies a compositing
node group on a sequencer strip. This patch also introduces the concept
of a compositor node tree space subtype, where we now have a Scene and a
Sequencer subtypes. Practically, this just means that node like the
Render Layers node will not be available in the node editor in the
Sequencer subtype.
Future improvements includes:
- The compositor context is recreated on every modifier application,
while it should ideally be persistent somehow to make use of the
compositor static cache. This might require work from the compositor
side by moving the static cache outside of the context and make it
thread safe if needed. See `Render.compositor` for an example on
persistent context.
- GPU execution is not supported. This just needs a GPU context to be
bound before execution, but the tricky part is getting a GPU context.
See `render::Compositor::execute` for an example on bounding a GPU
context and why it is less straight forward.
- Node inputs are not exposed on the sequencer modifier interface. An
approach similar to Geometry Nodes modifier could be used, look at
`update_input_properties_from_node_tree` for reference, but notice
that Geometry Nodes naturally exempt the main Geometry socket because
Geometry inputs can't be exposed, but for the compositor, we will have
to exempt the main Color and Mask sockets manually. !145971
Co-authored-by: Aras Pranckevicius <aras@nesnausk.org>
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/139634
When effect of adjustment layer strip is moved below the adjustment
layer, this causes infinite loop in strip rendering. Same happens when
you use multicam strip and set source channel to one of its effects.
This is fixed by passing `SeqRenderState` to the effects. If any strip
renders "seqbase" pointer of strip is stored in set in the render state
struct. If the pointer exists in this set, function returns without
rendering anything. In other words, The strip must never render itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/146624
error: ‘INT_MAX’ was not declared in this scope
compiler hints to include missing header `#include <climits>`
but replaced with `std::numeric_limits<int>::max()` / min
**ONLY** in cases where the errors were thrown
Pull Request: https://projects.blender.org/blender/blender/pulls/146212
This happened because it was attempted to access or set the
non- existent pixelspace offset of these audio strips. It is fixed by
applying the "paste at mouse" behavior only for strips that would be
rendered, which excludes sound strips implicitly. This has also
benefit, that strips with effects would only change position of the
effect thus avoiding double transformation.
Pull Request: https://projects.blender.org/blender/blender/pulls/145819
This was happening because the strip modifier types register
their panels when the editor is created, but the poll functions
of these panels did not check for the view type.
To fix this, add a condition to the `modifier_ui_poll`
that checks if the view type is not `SEQ_VIEW_PREVIEW`
when the panel is added to a sequencer space.
Pull Request: https://projects.blender.org/blender/blender/pulls/145964
- "Is this strip type an effect?" has been done by reserving 3rd bit
of the effect enum values to indicate that. That is a very strange
decision, so make that be done by strip_is_effect() function. The
enum values have to stay the same for backwards compat however.
- Both "strip type" and "strip blend mode" were sourced from the
same STRIP_TYPE_ enum, with only parts of the values meant for "type",
and other parts of values meant for "blend mode". That again is highly
confusing; split that off into two enums. Yes there's a handful of
values in them that overlap, but not the majority.
Pull Request: https://projects.blender.org/blender/blender/pulls/145746
Functions for convert between the color types and ostream support are
now outside the classes.
Many files were changed to fix cases where direct includes for headers
were missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/145756
This replaces the hardcoded function with modifier type callbacks
to make it easier to customize the reading/writing
for custom modifier data.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/145737
This PR updates the VSE strip modifiers interface.
It now uses the same design as the object modifiers.
Changes:
* Except for the "Mask Input" subpanel, the modifier UIs are unchanged.
* Modifiers can now be rearranged using drag & drop.
* Additionally, there is now an active strip modifier. This is exposed
though python via `strip.modifiers.active`.
This is in part for !139634 which needs the concept of an active modifier.
Notes:
* The `modifier.cc` file included all the implementation of all modifiers.
With the addition of a another new callback in this PR, this file was
getting quite big so I split everything out into individual files for all
modifiers. The modifiers are getting registered at launch.
* The modifier panels are getting added using a UI template
(`template_strip_modifiers`) very similar to the object modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/145367
Currently, sequencer structs contain several pointers to data within
other structs. These pointers need to be remapped as the structs are
reallocated when reading from blend files. That has worked so far
because the pointers are exactly the values from the Blender session
that saved the file. With the implementation of #127706, the pointers
in the file aren't "real" anymore, and we can't offset them to get the
struct that contained the data. I'm working on the pointer stability
solution now to address a memfile undo performance regression
in 5.0 due to the `AttributeStorage` read/write design.
This commit replaces these 4 mid-struct pointers to point to the
containing strips instead, and uses some trivial logic to access the
fallback root sequence channels and strips. This makes the pointer
remapping on file load possible again.
This change is backward compatible but not forward compatible.
Second try after #144626
Pull Request: https://projects.blender.org/blender/blender/pulls/144878
Faster and better looking VSE scopes & "show overexposed". Waveform &
RGB Parade now can also show HDR color intensities. (Note: this is
only about VSE scopes; Image Space scopes are to be improved separately)
- Waveform, RGB Parade, Vectorscope scopes are done on the GPU now, by
drawing points for each input pixel, and placing them according to
scope logic. The point drawing is implemented in a compute shader,
with a fragment shader resolve pass; this is because drawing lots of
points in the same location is very slow on some GPUs (e.g. Apple).
The compute shader rasterizer is several times faster on regular
desktop GPU as well.
- If a non-default color management is needed (e.g. VSE colorspace is
not the same as display colorspace, or a custom look transform is used
etc. etc.), then transform the VSE preview texture into display space
RGBA 16F texture using OCIO GPU machinery, and calculate scopes
from that.
- The "show overexposed" (zebra) preview option is also done on the
GPU now.
- Waveform/Parade scopes unlock zoom X/Y aspect for viewing HDR scope,
similar to how it was done for HDR histograms recently.
- Added SEQ_preview_cache.hh that holds GPU textures of VSE preview,
this is so that when you have a preview and several scopes, each of
them does not have to create/upload their own GPU texture (that would
both waste memory, and be slow).
Screenshots and performance details in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/144867
Most of these crashes happen because it is assumed that the scene will
always be present even if we have an uninitialized `Editing`, which is
no longer the case with #140271.
- Fix crash when clicking and dragging in the scrub area by checking for
valid `sequencer_scene` in `change_frame_poll`
- Fix crashes when selecting menu items by disabling them in the UI
until a `sequencer_scene` is present
- Fix crashes running operators from the F3 menu by changing to more
restrictive polls that check for `sequencer_scene`
- For good measure, check before dereferencing in
`channels_displayed_get`, `active_seqbase_get`, and `editing_get`
Pull Request: https://projects.blender.org/blender/blender/pulls/145145
Implements the proposed design (with some modifications) in #135058.
## Sequencer Scene
This adds a new property called `sequencer_scene` to workspaces. This scene is used
by the video sequence editors in the current workspace for their context.
This is a first step towards "detaching" the VSE from the active scene in the window.
Each sequencer timeline editor shows the sequencer scene that is being used.
By default, when no sequencer scene is selected, the timeline and preview are empty.
Pressing the "new" button will add a new scene and assign it to the sequencer
scene for the current workspace.
## Contextual Playback
Pressing `Space` (by default) for starting the animation playback is now contextual:
depending on the context (where your mouse cursor is), the scene that is played back
might be different. E.g. with a 3D Viewport and a Sequencer open, pressing "play"
in the 3D Viewport will play the _active scene_ of the window, while pressing "play"
in the sequencer will play the _sequencer scene_.
## Time & Scene Synchronization
Additionally, this adds a toggle called "Sync Active Scene".
With the property turned on, the active scene & scene time in the window will be
synced with the time & scene of the current scene strip in the sequencer.
Note that this is _not_ bi-directional. The sequencer can change the active scene
and map time, but it's not possible the other way around since it one can have
multiple strips using the same scene (+camera, and even time!).
Currently this setting is exposed in the footer of the sequencer timeline as well
as in the workspace settings.
This allows for one of the core concepts that the story tools projects aims at: Working
in a scene (e.g. in the 3D viewport) while also working with the edit
(in the sequencer timeline).
## Some technical notes
* Undoing while playback is running will now cancel playback. This is to avoid the timer,
that points to the scene and viewlayer that are playing, to get de-synced after loading
the memfile undo step.
* When the sequencer scene is not the same as the active scene, we ensure it has
a depsgraph.
* Normally, when a `NC_SCENE` notifier points to a specific scene, the notifier is dropped
if that scene doesn't match the active one in the window. We now also check that it
doesn't match the sequencer scene in the active workspace.
* When loading older files, we need to make sure that the active workspace in a window
uses the active scene as the sequencer scene. This is to make sure that the file opens with
the same sequences open.
* Tool settings are stored per scene. To make sure the sequencer uses the tool settings for
the sequencer scene, the "context.tool_settings" and `CTX_data_tool_settings` members
are overridden in the sequence editors.
Pull Request: https://projects.blender.org/blender/blender/pulls/140271
Caused by casting float value to int in source cache eviction logic. The cache
key was changed from int to float for timeline frame, but this was not changed
in `source_image_cache_evict()`. Compiler did not catch this unfortunately.
Pull Request: https://projects.blender.org/blender/blender/pulls/145019
* PROP_COLOR_GAMMA is sRGB, not display space
* Hex colors are always sRGB
* Image byte buffers are in byte_buffer.colorspace
Fixes for sequencer text, image painting, render stamp and tooltips.
The default display space is sRGB, so this change will not be noticed
in most files.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
Currently, sequencer structs contain several pointers to data within
other structs. These pointers need to be remapped as the structs are
reallocated when reading from blend files. That has worked so far
because the pointers are exactly the values from the Blender session
that saved the file. WIth the implementation of #127706, the pointers
in the file aren't "real" anymore, and we can't offset them to get the
struct that contained the data.
This commit replaces these 4 mid-struct pointers to point to the
containing strips instead, and uses some trivial logic to access the
fallback root sequence channels and strips. This makes the pointer
remapping on file load possible again.
The downside is that this isn't strictly backward or forward compatible,
but only on a UI-level. The active meta-strip information will be lost,
and the sequencer will reset to displaying the root sequence.
Depends on #144624
Pull Request: https://projects.blender.org/blender/blender/pulls/144626
