Freeze frames can be added now using retiming tool with no need to hold
splitting strips or using hold offsets. To use this feature, add
retiming handle where you want to freeze the frame, hold ctrl key and
drag the handle. It is not possible to freeze frame of transition handle
and it is not possible to add transition to or from freeze frame.
Retiming system would handle these cases, but they are not useful in
practice.
When freeze frame is created, start handle of frozen segment is flagged
as `FREEZE_FRAME`. Most handling is similar to `SPEED_TRANSITION`
type handle. For evaluation, there is no special case for this type, as
it's just 2 handles with same `retiming_factor` value. It is possible to
recreate this behavior without using freeze frame feature by adding
handle between 2 consecutive content frames, but this would not be
recognized by UI or treated as freeze frame segment/handle.
Eventually this feature should replace hold offsets, leaving `Sequence`
struct with single offset type, see PR 105620 for reference.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Own regression caused by [0] made to ensure the string was initialized,
without accounting for it being static & reused between calls.
Replace static variables with a struct that's passed to the function,
this explicitly shares state between calls as this static variable use
depended on BKE_scene_multiview_view_prefix_get always clearing prefix
variables with a zero view_id so future calls would also be cleared.
While this non-obvious behavior could be documented,
use more straightforward logic.
[0]: bdad2c0595
Allows to share buffer data between the render result and image buffers.
The storage of the passes and buffers in the render result have been
wrapped into utility structures, with functions to operate on them.
Currently only image buffers which are sharing buffers with the render
results are using the implicit sharing. This allows proper decoupling of
the image buffers from the lifetime of the underlying render result.
Fixes#107248: Compositor ACCESS VIOLATION when updating datablocks from handlers
Additionally, this lowers the memory usage of multi-layer EXR sequences
by avoiding having two copies of render passes in memory.
It is possible to use implicit sharing in more places, but needs
some API to ensure the render result is the only owner of data before
writing to its pixels.
Pull Request: https://projects.blender.org/blender/blender/pulls/108045
The goal is to make it more explicit and centralized operation to
assign and steal buffer data, with proper ownership tracking.
The buffers and ownership flags are wrapped into their dedicated
structures now.
There should be no functional changes currently, it is a preparation
for allowing implicit sharing of the ImBuf buffers. Additionally, in
the future it is possible to more buffer-specific information (such
as color space) next to the buffer data itself. It is also possible
to clean up the allocation flags (IB_rect, ...) to give them more
clear naming and not have stored in the ImBuf->flags as they are only
needed for allocation.
The most dangerous part of this change is the change of byte buffer
data from `int*` to `uint8_t*`. In a lot of cases the byte buffer was
cast to `uchar*`, so those casts are now gone. But some code is
operating on `int*` so now there are casts in there. In practice this
should be fine, since we only support 64bit platforms, so allocations
are aligned. The real things to watch out for here is the fact that
allocation and offsetting from the byte buffer now need an explicit 4
channel multiplier.
Once everything is C++ it will be possible to simplify public
functions even further.
Pull Request: https://projects.blender.org/blender/blender/pulls/107609
The usage of the lib pointer was cryptic to say the least, it was
essentialy used to allow or not local IDs results in the mapping
old_id_pointer -> new_id_pointer lookup result.
Now:
- Explicitely pass a boolean to allow or not local ID as result in
lower-level code.
- Pass the 'self ID' pointer instead of its library to the whole
liblinking code (that was already the case in a few places).
Note that naming of the 'self id' pointer is currently very inconsistent
throughout the readfile liblink code, this will have to be cleaned up in
a separate step later. For now, `self_id` has been chosen for new code
as it matches the terminology in lib_query code.
The later change can also allow finer handling of lookup on undo, based
on how it was re-read (or not), should the need for this arise.
This feature implements smooth transition between 2 retimed segments.
A transition can be added by dragging retiming handle while holding
shift key. When any handle defining transition is removed, the
transition segment is removed and 2 linear segments are restored to
state before transition was created.
These transitions work with video and sound and changes are reflected
in waveforms with correct seeking, therefore it replaces usage of
`speed_factor` or earlier sound `pitch` property.
Smooth transition is achieved by evaluating Y value of circular arc,
that is tangent to lines of linear retimed segments. Because of this,
when transition length is changed both handles are moved symetrically.
This way it is possible to make transition without affecting content in
linear segments.
When linear segment after transition is further retimed, this shifts
content inside of a transition segment.
To support sound, `SEQ_retiming_sound_animation_data_set` and related
data structures has been updated to build speed table for each smooth
transition segment. Layering of retiming data via meta strips is still
fully supported.
Pull Request: https://projects.blender.org/blender/blender/pulls/107197
The file path was 256 bytes, passing in a buffer size of 1792
for string join & making the path absolute could also overflow
as it assumes a size of 1024.
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
Rename BLI_make_existing_file to BLI_file_ensure_parent_dir_exists.
The previous name read as if it would make (touch) the file,
where as it ensures the directory component of the path exists.
Move from BLI_path to BLI_fileops as path utilities should only
manipulate paths and not deal with file IO creation
(this has more in common with BLI_file_touch for e.g.).
This patch contains changes needed for retiming sound strips.
`BKE_sound_set_scene_sound_pitch()` is replaced by
`BKE_sound_set_scene_sound_pitch_constant_range()` which uses new
Audaspace interface to set pitch in bulk.
This is done in `SEQ_retiming_sound_animation_data_set()` where retimed
sections are created for each strip. When strip is inside of meta
strip(s), the retimed sections of meta and actual strip are split where
they intersect and pitch is multiplied where they overlap. Each section
will have pitch value that is provided to audaspace.
Waveform overlay now represents retimed audio accurately.
Ref: #100337
Pull Request: https://projects.blender.org/blender/blender/pulls/105072
Rename *Bright/Contrast* to *Brightness/Contrast* in order to avoid the use of shortened names and improve consistency within Blender and with industry conventions.
Reasoning:
The modified color characteristic is called *brightness*, not *bright*. You don't modify the *bright* of an image.
This also interferes with search in case someone searches for brightness, producing no results.
*Note: This patch should only touch UI names which do not need versioning. It leaves the actual property name in nodes for a future breaking release.*
Pull Request: https://projects.blender.org/blender/blender/pulls/104998
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
When subsampling was introduced in VSE it was disabled during
editing. Only when rendering it was enabled. This lead to
cache being different between editing and rendering. Leading
to confusion.
This PR will enabled the subsampling when editing. This way
it is more consistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/105612
Previously `SEQ_transform_single_image_check` function was used to check
if image or effect strip has only one frame of content. Now these strips
are flagged with `SEQ_SINGLE_FRAME_CONTENT`.
While previously this was implicit property of strip, benefit of having
explicit flag is that this property can be decoupled from strip length.
Caused by b4100ed377. Image strips with only 1 frame of content do
expect any timeline frame to be translated into frame index of 0.
Check this case and return 0 explicitly.
Fix error in b4100ed377
`seq_retiming_evaluate()` returns range from 0 to 1, to which framerate
correction was applied. this is incorrect, and correction should be
applied to function input.
When movie framerate does not match scene, content length was clamped to strip
length in scen framerate. This also caused issues with retiming which behaved in
similar way. Retiming was modified to use frame index of strip content, so even
when scene framerate is changed, retiming data is preserved in correct
proportions. This means, that handles are mapped to time in seconds rather than
to frames.
This tools allows to change strip playback speed by manipulating
retiming handles. More handles can be added to single strip to create
variable playback speed.
This tool replaces Speed Factor property in time panel, with exception
of sound strips. Support for sound strips is still in review.
Pull Request #104523
