- BLF font flags were an untyped enum; change to actual enum and
update usages from int to that.
- Move all BLF API enums to their own header, so that if something
needs just the enums they don't have to include whole BLF_api.hh
Pull Request: https://projects.blender.org/blender/blender/pulls/143692
Use the form "Processing something..." (gerund, sentence case,
ellipsis) for running jobs progress label, according to Blender's
Human Interface Guidelines.
Pull Request: https://projects.blender.org/blender/blender/pulls/141573
Gaussian blur effect size is expressed in pixels (not ideal, but that is
what it is). It was not taking render output scale or preview proxy
size into account, resulting in much larger blur at lower render scales.
Pull Request: https://projects.blender.org/blender/blender/pulls/143627
- Some functions that took integer arguments for proxy size enums; make
them take said enums directly.
- Add get_render_scale_factor() that calculates effective render scale,
use that in places that did manual "use either scene render scale setting
or proxy size" calculation in 5 places.
- Replace previous double with float in proxy size scale factors; all
the factors are exactly representable as floats, and all the calling
places used them as floats too.
- In various VSE related DNA structs, indicate which enums they use
as comments,
- Add enum types for the enums that were untyped,
- Move Wipe effect enums to DNA header for clarity, since they are
serialized values,
- Reduce SeqRetimingKey size from 40 bytes to 32 bytes; there
was too much unnecessary padding.
- Rename some enums SEQUENCE_ -> STRIP_ where relevant.
- Rename wipe enums DO_MEOW_WIPE -> SEQ_WIPE_MEOW
Pull Request: https://projects.blender.org/blender/blender/pulls/143565
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
VSE final image cache invalidation for the newly added effect
strip was invoked before the strip time range values were set,
effectively not invalidating anything.
Pull Request: https://projects.blender.org/blender/blender/pulls/142854
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
Previously, newly added Gaussian Blur effect did not blurring at all,
since blur sizes were set to zero. Make them default to 9 pixel size
blur, which is similar to the amount of blur the Glow effect does by
default.
Pull Request: https://projects.blender.org/blender/blender/pulls/142851
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 PR switches out the internal scene context function
used from the sequencer. This is done in preparation for
#140271.
Using a separate context function allows us to keep the
existing `context.scene` to refer to the active scene
and use a separate context member to refer to the
sequencer scene in the workspace (which is added in #140271).
Previous attempts simply overrode the `context.scene`
to refer to a different scene than the active one in the window.
This has two issues:
1) Any operator that wants to use the active scene in the window
can't do it in the context of the sequencer. This is a problem for
example for poll functions of operators that don't have anything to
do with the sequencer.
2) For better or for worse, Blender expects the `context.scene` to
always exist. For the sequencer, we'd like to possibly have no
sequence selected.
Using a different context member for the sequencer has some
advantages:
1) Although we have to change quite a few places, it's limited to the
sequencer. We don't have to change other parts of Blender to make
things work.
2) It allows us to prepare for the future when we might want to
separate the VSE from the scene. This is a step in that direction.
Having a different context function makes it easy to find the places
that would need to be refactored.
Pull Request: https://projects.blender.org/blender/blender/pulls/141271
This initial commit properly clamps handles for video/audio strips, and
provides functionality to enable/disable the behavior for all strip types
(addresses #90280).
Toggling handle clamping is done with "C",
just like with the redesigned slip operator (#137072).
If a strip is not already clamped when you start moving its handles,
then clamping behavior is disabled starting out. This means no abrupt
clamp until you explicitly ask for it.
Transform logic was altered, fixing a few bugs:
- When initializing a transform, `createTransSeqData` would already
create some clamping data for channels. This patch replaces it with
`offset_clamp` (for unconditional clamping which cannot be disabled)
and `handle_xmin/xmax` (for hold offset clamping, which is optional).
- Collecting this data ahead of time is necessary for the double
handle tweak case -- `flushTransSeq` only works one strip at a
time, so we can't clamp post-hoc.
- In `applySeqSlideValue`, we apply `transform_convert_sequencer_clamp`
before values are printed to the header, but let the unclamped values
get flushed to the strips themselves. This is so that we can have the
data later at the individual strip level to recalculate clamps.
Otherwise, if transform values are clamped preemptively, then we have
no idea whether strips are clamped vs. merely resting at their
boundaries.
Note that currently, handle clamping is drawn identically to overlaps.
More information in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134319
As mentioned in comments on #43646, a negative channel value in preview
view settings can be used to climb the metastack. But the functionality
did not work as expected in most cases.
This combines a one-line fix by Sergey with an updated description for the
property which documents the feature.
In the future we may want to change its operation to be less obscure,
since it has some use-cases in aligning strips within a metastrip with
those outside of it.
Regression caused by 9e4c26574a.
Add strip stack as a key to the final cache.
Use the pointer to the list of sequences, as it is the easiest one to
obtain in all places where it is needed. This is slightly different
from the code prior to the 9e4c26574a where strips.last() was used,
but it allows to use the same logic in the prefetch job.
Pull Request: https://projects.blender.org/blender/blender/pulls/141778
Blender expects float buffers to be in scene linear space, which was
violated bu the 1012bit movie reading code. While such image buffers
can be displayed correctly, performing operations in various areas
of Blender might lead to unexpected results.
The non-linear colorspace for ImBuf is expected to be "internal-only"
to a specific area, like VSE.
This is only done for Image and MovieClip data-blocks, sequencer still
reads movie files in their original colorspace as it helps performance and
sequencer can not be referenced from places where linear colorspace
for float buffer is really important.
Pull Request: https://projects.blender.org/blender/blender/pulls/141603
Make display channel part of the key for the final cache.
The prefetch uses display channel of 0, which is the default. It might
need to be adjusted, but it is unclear whether it was behaving different
prior to the 9e4c26574a.
Pull Request: https://projects.blender.org/blender/blender/pulls/141670
New sequence strip modifiers get a name that is to be translated if
translation of data is enabled. This used the default translation
context, but "Sequence" must be used because this is the context used
to extract the modifier names (`modifiersTypes` array in modifier.cc).
Reported by Ye Gui in #43295.
If render settings resolution scale had lowered resolution, cached
images from render image/animation session could "stay around"
and be incorrectly used in the VSE preview area. Two cases I found are
fixed here:
- Intra-frame cache was not flushed upon actual final resolution
change,
- "Source images" for effect/scene strips were not removed when
requested resolution no longer matches their rendered resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/141297
I18n: Translate a few messages
- Translate add-on types in the user preferences.
- Translate a report which uses formatting.
- Do not translate scene names in `sequencer.scene_strip_add` operator
UI.
- Do translate the type of new scene in
`sequencer.scene_strip_add_new` operator.
- Translate Half and Float image format color depth enum items.
- Translate Mix node header with non-color data types.
- Translate sequencer modifiers' names if data translation is enabled.
Most issues reported by Ye Gui in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/141145
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
Text strip along with other effect strips draws into buffer, which is
defined by common render size. However this makes selection, snapping
and other features not work correctly from user perspective.
There are 2 ways to remedy this:
- Draw text into buffer which size is defined by text boundbox
- Just draw the correct size boundbox and make UI use it correctly
This PR implements second option, as there are multiple difficulties
asociated with first option. Main problem is, that one would need to
calculate boundboxes for all individual text effects(blur, shadow, ...),
but many of these effects need to know the size of buffer we are trying
to calculate.
Big question here was: What the boundox should look like?
For selection it is best, if it encapsulates the text itself along with its
effects like shadow, blur or box. However for snapping and pivot range
it seems, that encapsulating only the text without any effects applied is
the best solution. This was discussed with UI module and we agreed,
that encapsulating only the text would provide better usability.
The implementation:
Most of the features are on "preview side", where all dimensions are
related to scene render size. Temporary `TextVarsRuntime` is created to
calculate apparent text strip image size. This allows boundbox of
correct size to be drawn.
However to draw boundbox and do transformations correctly, it is
necessary to remap origin point to the subset of image defined by the
boundbox. Since recalculated origin is relative, this function is used
for image transformation during rendering as well.
Main drawback of this method is, that boundbox and origin point
calculation may be needed from multiple places, and `TextVarsRuntime`
may be recalculated about 10x on redraw. `text_effect_calc_runtime`
function can be executed from ~5us for single character to 0.5ms with
512 characters with default font(not sure if that matters).
Drawing origin only during transformation would help with general UI
responsiveness. During playback, these overlays are not drawn, so
there should be no change in performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/140420
`seq_need_scale_to_render_size` returned true, when scaling was not
needed. The code that used this function worked correctly, so the logic
was inverted in both places.
We wouldn't clear the cache we disabled leading to end users needing to
trigger cache refreshes to eventually clear out the cache that they
disabled.
This also fixes a minor issue where the prefetch would try to prefetch
even if there were no caches enabled.
Sometimes we could get into scenarios where the prefetch would stop and
restart endlessly. Now we only stop the prefetch job when we don't want
to continue to prefetch anymore. Before we would exit when there is
currently no more prefetch work to do.
