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
Before, trying to add multiple strips would always create an image
sequence. This patch allows images to be added in bulk, just like movie
& sound strips.
A new "Image Sequence Detection" property has been added which works
like the image editor. Toggling it off will always import individual
images and never create image sequences.
If it's on, you can also optionally "Use Placeholders" to fill in gaps,
which exhibits the same behavior as before (placeholders will show as
pink in the preview until you have the files on your system in the right
folders).
You can even add both image sequences and regular images at the same
time. Only caveat is that this doesn't work if the regular images are
interspersed within sequence frames in the file browser view when you
add them. I.e., all frames of a sequence should be listed without any
regular frames in between (but the sequence frame numbers don't have to
be in order). This can usually be ensured on all sort types (like date,
name).
NOTE: This patch also replaces the "end_frame" property on image /
effect strips with "length," to support behavior when multiple strips
are involved. This is a breaking change for the API, but is a fairly
small change and will be included in the release notes.
The "length" property allows one to adjust all image strips' lengths at
once. It does nothing for image sequences, however, since their lengths
are defined by their image count.
Pull Request: https://projects.blender.org/blender/blender/pulls/143974
- Deduplicate `scale_fit_methods` enum
- Reorder functions, polls, and code to locations that make sense
- Rename some functions to remove `seq` terminology in favor of `strip`
- Renames `len` in `LoadData` to `count` for images
- Add clarifying comments and improve descriptions
With the aim of removing `seqbasep` to remove the complicated logic for
repairing pointers within the `Strip` struct when loading files and undo
steps, this commit just moves access of the variable behind a function.
In the future the function will retrieve the list from a Strip pointer,
for now it just returns the existing pointer.
Overall motivation is that blend file pointer manipulation is incompatible
with the changes required for #127706.
Pull Request: https://projects.blender.org/blender/blender/pulls/144624
Not a common scenario, but if you had very few source images (e.g.
long image strips with one frame) and many final frames cached,
the full cache eviction policy was not handling that well, since it
was always removing at least one source image for each final frame.
Resulting in effectively the cache only being full of final frames.
Change that so:
1) evict_caches_if_full has a loop that tries to evict until the caches
are not full (i.e. not necessarily just one image), and
2) only evict source image per final frame, if there are more source
images cached.
Pull Request: https://projects.blender.org/blender/blender/pulls/144612
`render_give_ibuf_direct()` just called `seq_render_strip()`, which
tried to get image from intra frame cache. This always succeeded,
because the intra frame cache does not accept timeline frame argument.
Using intra frame cache here is incorrect. Source cache must be used.
If source cache lookup fails, intra frame cache must be invalidated
before calling `seq_render_strip()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/144396
Duplicating a strip that references an ID like the scene strip would not
duplicate the scene. This is wanted in some workflows.
To align with the rest of Blender, this changes the behavior for how
strips are duplicated:
* `Shift + D` ("duplicate"): Duplicate the strip and also duplicate the
IDs referenced by the strip. Currently this only affects `Scene`,
`MovieClip`, and `Mask` strips.
* `Alt + D` ("duplicate linked"): Duplicate the strip, but reference the
same IDs. This is the current behavior in `main`.
Part of #144063.
Pull Request: https://projects.blender.org/blender/blender/pulls/144138
Broken with new 4.5 cache implementation; the loop for building
image sequence proxies was not flushing the intra-frame cache
between frame changes. This affects image proxies since they go
through the whole VSE render stack; does not affect video proxies
since they just manually decode the file frames.
Pull Request: https://projects.blender.org/blender/blender/pulls/144269
This removes the `STRIP_DUPE_UNIQUE_NAME` and `STRIP_DUPE_ALL` macros
and replaces them with an `enum StripDuplicate`.
A flag with a value of 0 was implicitly used as "duplicate selected strips" so the
enum uses `Selected = 0` to document this behavior better.
Pull Request: https://projects.blender.org/blender/blender/pulls/144125
VSE cache processing was handling thumbnail generation requests in
parallel, however often that was resulting in CPU core over-subscription
that negatively affects user interface smoothness. Process requests
serially; some parts of image/video loading are internally multi-threaded
already. This makes thumbnails load somewhat slower, but while that
is happening the rest of blender feels much smoother, and the CPU
fans don't spin up as much.
Additionally, make the video thumbnail loading code use smallest
available proxy file, if present. This was overlooked in the original
new thumb cache implementation (!126405).
SpriteFright timeline edit v135 (mostly JPG images, some movies),
loading thumbnails for the whole timeline on Ryzen 5950X (Windows):
- 4.2.1: 35 seconds, CPU usage ~35%, UI smooth
- Main: 13 seconds, CPU usage ~90%, UI choppy
- This PR: 19 seconds, CPU usage ~35%, UI smooth
Manually made timeline with 10 video files:
- 4.2.1: 12 seconds, CPU usage ~50%, UI smooth
- Main: 6 seconds, CPU usage ~100%, UI choppy
- This PR: 9 seconds (no proxies) / 4 seconds (with proxies), CPU usage
~50%, UI smooth
Candidate for 4.5.x backport
Pull Request: https://projects.blender.org/blender/blender/pulls/144120
Replaces the `FPS` macro with `scene->frames_per_second()`.
The macro has two major issues:
* It hides that it depends on a `Scene *` variable named `scene`.
* It makes debugging harder.
This is now replaced with a member function on the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/144127
