- "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
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
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
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
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
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
Quite a few flags in `Strip.flag` were used only at runtime; they were
temporarily set and then cleared thereafter. Move them to
`StripRuntime.flag` instead.
Most of the moves are trivial renames, with some old versioning code for
`SEQ_FLAG_DELETE` deleted. That code fixed a very uncommon edge-case bug
in 2.x which doesn't seem worthwhile to keep deprecated code around for.
Pull Request: https://projects.blender.org/blender/blender/pulls/142776
Ultimately, the issue was caused by updating sound sequence handle in
`AUD_SequenceEntry_setSound` on each new frame regardless if the
modifier data has changed.
This commit fixes the issue by implementing a means for modifiers to
check, if their parameters or inputs are changed.
This is done by storing these parameters in `StripModifierDataRuntime`
struct, that is shared between all modifier types. This is not ideal,
but it significantly simplifies dependency graph runtime store/restore
code.
Function `strip_update_sound_modifiers` passes boolean `needs_update`
to strip stack update functions. If any needs to be updated, it sets
value of `needs_update` to true allowing following update functions to
skip parameter checking to speed up the process.
Original code updated sound sequence handle twice. Once by function
`BKE_sound_update_scene_sound` then by `strip_update_sound_modifiers`.
If sound modifier is used, only `strip_update_sound_modifiers` needs to
be called, so there is condition to decide which one of these functions
is called.
Also fixes#139605
Pull Request: https://projects.blender.org/blender/blender/pulls/141595
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
Text strip had a fixed size buffer of 512 bytes to hold the displayed
text (this can be much fewer actual characters with non-English
languages). Switch to dynamically allocated buffer instead, which can
hold longer text.
In order to support forward/backward compatibility, TextVars continues
to hold the 512 byte buffer in memory. When writing out the .blend file,
dynamic text buffer is copied into the fixed one. If it is longer, the
text is truncated, so opening the .blend file in an older version
will contain the first 512 bytes of the longer text. When reading
existing files without the dynamic text buffer, it is created from the
static buffer. Conceptually this approach is similar to constraints
name length increase PR !137310.
The text strip editing code was switched to operate on the dynamic
buffer, resizing it as needed. seq::CharInfo internal struct was
switched to be more independent of the actual buffer address; now
each char entry just stores an index into the buffer instead of direct
pointer (side effect: makes the struct smaller as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/140733
This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
- Previously, effects could be changed into types that take different
amount of inputs, e.g. from "add" to "glow", which led to undefined
and glitchy behavior (unreported bug). Fix by requiring same input count
for new effect.
- Previously, strip names were not updated when changing effect type,
which tended to be confusing. Now, if the default name was not changed,
update to the new effect type name.
- Remove "effect strip" menu from color and text strips. Although they
are effects internally, to a user, this is not clear, and providing the
option to modify effect inputs in these cases doesn't really make sense.
Pull Request: https://projects.blender.org/blender/blender/pulls/139514
This should make VSE code more readable and easier to understand from an
outside perspective.
The name was chosen to be `channel` rather than `channel_index` to keep
things short and concise -- it should be clear based on the context
whether we are talking about the strip's channel index (singular case,
`Strip::channel` or `SeqTimelineChannel::index`) vs. the channel list
(plural case, e.g. `Editing::channels`).
Pull Request: https://projects.blender.org/blender/blender/pulls/138919
This patch renames `seq1` and `seq2` to `input1` and `input2` in `Strip`
and `StripSelection` structs to consist with recent refactors in
#132179. It also renames other instances of `seq1` and `seq2` (e.g.
local variables) to `strip1` and `strip2` instead.
There is only one small breaking change to the Python API with
`strips.new_effect()` taking in the new names now. There should be
no other functional changes involved.
Pull Request: https://projects.blender.org/blender/blender/pulls/138296
Rework internals of how VSE caching is done. Primarily to make all the
caching logic more understandable from development point of view, but
also has several user visible implications (more details in the PR):
- Simpler and fewer caching UI options,
- Disk cache is gone (primary reason: proxies are kinda the same thing),
- VSE cache size set in preferences is actual size used for VSE caches
now (previously caching stopped as soon as whole Blender used that
much memory, even if some memory usage was not about VSE at all),
- Certain scenarios of cache invalidation are faster now.
Pull Request: https://projects.blender.org/blender/blender/pulls/137926
Ref: #132179
Renames:
- `Editing.act_seq` -> `Editing.act_strip`
- `SequenceModifierData` -> `StripModifierData`
- Its member `mask_sequence` is now `mask_strip`.
- `MetaStack.parseq` -> `MetaStack.parent_strip`
- Remaining function names/parameters that were not dealt with in #132748
- Various references to `seq` or `sequence` throughout code and docs when
referring to a strip
Also moves `_get` to the end of the renamed function names where
applicable for standardization (unless "by" or "from" are used).
There should be no changes to current behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/138077
Crashes were caused by setting `Strip::machine` above `MAX_CHANNELS`
value.
Instead of clamping this value at multiple places, setter function
`seq::strip_channel_set` was added that implements clamping.
This also allows for better handling of clamping if it was ever needed.
Function `strip_transform_handle_expand_to_fit` still sets machine value
directly and above `MAX_CHANNELS` as a hack. This could be avoided, but
it would require some refactoring.
Pull Request: https://projects.blender.org/blender/blender/pulls/136163
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135747
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
Instead of passing the `scene`, pass a pointer to the `Editing` struct.
This is the struct that owns the `StripLookup` in its `runtime`
so there isn't a good reason to use the `scene` pointer here
anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/134743
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
This renames the `Strip` struct to `StripData` and also renames
the `Sequence::strip` member to `Sequence::data`.
This is a first step towards naming the `Sequence` struct to `Strip`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132165
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
This commit implements most features needed for simple text editing.
Active text strip can be edited in preview by pressing tab key, which
enabled text editing mode. With this mode active, outline matches text
boundary box and cursor is drawn.
Cursor can be moved with usual keys. Pressing shift starts selection.
Selection and navigation works when text is scaled or rotated. Mirrored
text is not supported in this PR. it can be done, but the text is
unreadable that way, so I kept it simple.
Multi line text is supported. Pressing return key starts new line.
Copy/paste operator uses OS copy paste buffer, so text from other apps
can be pasted.
Text is still limited to 512 characters. Text string property still
exists in side panel and is limited to single line. Individual
characters can not be styled in different way like in 3D viewport, but
the code is mostly ready for such feature.
Ref: #126547
Pull Request: https://projects.blender.org/blender/blender/pulls/127239
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
Caused by removing scene sound from "main scene" when other strip using
the same scene is not rendering sequencer strips.
Only remove sound when all strips using particular scene are not
rendering sequencer strips.
Pull Request: https://projects.blender.org/blender/blender/pulls/129768
Tmp field was still used in strip duplication. This was a source of bugs
previously. Now it uses `Map` of new to old strips to fix strip
relations. The field is removed from DNA struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/128402
