Whenever movie frame encoding needs to be in non-RGBA format (pretty much
always, e.g. H.264 uses YUV etc.), the ffmpeg code has been using
sws_scale() since 2007. But that one is completely single threaded.
It can be multi-threaded by passing "threads" option to SwsContext
(in a cumbersome way), combined with sws_scale_frame API. Which however
requires frame data buffers to be allocated via AVBuffer machinery.
Rendering a 300-frame part of Sprite Fright Edit (target H.264 Medium):
- Windows Ryzen 5950X: 16.1 -> 12.0 seconds (generate_video_frame part
4.7 -> 0.7 sec).
- Mac M1 Max: 13.1 -> 12.5 sec. Speedup is smaller, but comparatively,
entirely other part of movie rendering (audio resampling inside audaspace)
is way more expensive compared to the windows machine.
The asserts added in b840ba1f59 revealed the bug, which was passing the
wrong Scene pointer to `BKE_view_layer_synced_ensure` in affected code.
Issue likely introduced in 68589a31ebfb79, was probably never actually a
crash-case because the viewlayer would always be in sync already when
this was called from the Outliner (besides perhaps some extremely rare
edge cases).
To be backported to potential bugfix release of 4.0 together with
b840ba1f59 commit.
Add support for enum values in ID properties.
This is needed for the "Menu Switch" node implementation (#113445) which
relies on ID properties for the top-level modifier UI.
Enums items can optionally be added to the UI data of integer
properties. Each property stores a full set of the enum items to keep
things simple.
Enum items can be added to properties using the `id_properties_ui`
function in the python API. A detailed example can be found in the
`bl_pyapi_idprop.py` test.
There is currently no support yet for editing enum items through the UI.
This is because the "Edit Property" feature is implemented entirely
through a single operator (`WM_OT_properties_edit`) and its properties.
Buttons to add/remove/move items would be operators changing another
operator's properties. A refactor of the custom properties UI is likely
required to make this work.
Pull Request: https://projects.blender.org/blender/blender/pulls/114362
Remove abstract edge and face types. The design is to not abstract away
the code data structures like this and focus on sharing code more with the
rest of Blender rather than within sculpt mode.
Before this happened as two steps: first allocating the PBVH with a type,
then calculating the BVH and filling it with data. This just confused things,
so change to allocating the struct when building it. Also move the functions
to the C++ namespace, and fix some cases of requiring the PBVH to be set
when it wasn't yet.
This `update_vertex_data` only found nodes with the color update
tag and also added redraw tags. But whenever nodes are marked
for a color update, those redraw tags are already set anyway.
It appears this was meant to solve problems switching active
color attributes during undo and redo, but it doesn't make a
difference when this function is removed.
Fix error of wrong parameter for `compare_exchange_weak`. Second
one parameter is used for write new value, but a mistake occurred and
the wrong parameter (for read) was used. Default param is enough for
this, so just delete last one.
Pull Request: https://projects.blender.org/blender/blender/pulls/116010
The only user was the Python API. Convert that to use the C++ API.
That simplifies things a bit even, since the encoding of "arrays of arrays"
is a fair amount simpler with the C++ data structures. The motivation
is to simplify the changes from #111061.
Now that the code is in C++, quite some duplication between "byte" and
"float" effect code paths can be reduced (easier than it was in C times).
So I did that, removing about 400 lines of code.
In that process I accidentally made Gaussian Blur faster, since while
reducing the amount of code I noticed it was doing some things
sub-optimally (calculated kernel tables for each job, etc.). Applying
100x100 gaussian blur on 4K UHD resolution image strip on Ryzen 5950X
went 630ms -> 450ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/116089
Studio lights based on image resources are kept in memory, even when only
displayed as an icon. When having many studio lights configured
leads to allocating a lot of memory that are not used.
This patch free image resources when only icons are requested.
For studio lights that are used in a viewport the image resources are kept.
Pull Request: https://projects.blender.org/blender/blender/pulls/116191
`float4x4` requires 16 byte alignment. The compiler can add padding
within the struct, but the allocation needs to know about the alignment
too. Fix by using an allocation function that handles this properly.
IMB_transform is used by Sequencer (and other places) to do image
translation/rotation/scale on the CPU. This PR speeds up parts of it,
particularly when bilinear filtering is used. No behavior changes are
expected.
- Don't use virtual function calls inside inner loop. The code was using
class hierarchies with virtual calls just to do equivalent of "outside
of image? ignore" and "wrap UV coordinates or not?" decisions. Make those
use non-virtual function based code.
- Simplify pixel sampling functions to only do the work as needed by
anything within Blender codebase. For example, bilinear sampling of uchar
images always uses 4 RGBA channels and never does "UV wrap" logic.
- Bilinear interpolation uchar: completely branchless SIMD code now.
- Bilinear interpolation float: 2x floor() calls instead of 4x floor() +
2x ceil(), and final sample blending is done with SIMD.
Sequencer at 4K UHD resolution, with two image strips that need a transform,
playback framerate:
- Windows Ryzen 5950X: 18.7fps -> 26.2fps (IMB_transform time per frame goes
26.3ms -> 11.2ms)
- Mac M1 Max: 27.3fps -> 31.4fps
At that point the IMB_transform is not the slowest part of where playback
takes time (but rather sequencer effect application etc.).
Note: the amount of _actual code_ got a bit smaller. But I've added 100 lines
of unit tests in BLI_math_interp_test.cc, the bilinear interpolation
functions were only tested very indirectly by CPU compositor template
image tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/115653
Studio lights had gone over several iterations during 2.80. Some
unused options where still in the code, but not used.
This PR cleans up the studio lights to options that are still in use.
Removing:
- Spherical Harmonics: It was used by workbench, but was replaced
by regular OpenGL lights
- Irradiance textures: Was used by an old eevee world light evaluation
- Cached data files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116186
The channel_bake_remove_options were forgotten
to be removed. They were no longer in use after
addressing review comments.
This fixes the compiler warning.
This is a replacement for the workflow that uses
"Bake Curve" and "Unbake Curve" to quickly generate
dense key data.
Compared to the existing workflow it has the advantage
of allowing the user more control over the key types,
and distance between keys, as well as the frame range affected.
Operator options
* Range: the range that will be baked.
Defaults to the scene range or preview range.
* Step: Distance between keyframes.
Can be used to bake on 2s or even bake to subframes.
* Remove Existing Keys: Boolean option that
if enabled also removes keys outside the specified baking range
* Interpolation Type: Choose a interpolation mode used
for new keys e.g. Constant or Bezier
* Bake Modifiers: If enabled bakes the effect of the
modifier stack to keys and deletes the modifier stack.
If false, the code disables the modifiers before baking,
so the resulting keys will behave as if the modifiers didn't exist
The operator can be found in the Graph Editor under `Channel->Bake Channels`
Part of: #111050
Pull Request: https://projects.blender.org/blender/blender/pulls/111263
This was missed during #113504
While the versioning code set the flags correctly,
the defaults were not specified correctly.
This would leave new users to key only location.
Fix it by enabling Location, Rotation, Scale and
Custom Properties by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/116180
This was an attempt to fix a crash resizing windows #107797
(which I can't reproduce), however it didn't fix the issue and meant
that a window would sometimes not reach the desired size,
the maximized window for e.g. would sometimes remain the un-maximized
size.
Since the preferred fractional scale callback runs,
remove a workaround that guessed the fractional scale from the output.
While it could be kept, it added unnecessary complexity.
No functional changes.
Move the function ED_id_action_ensure to animrig,
and rename it to `id_action_ensure`.
This is in order to reduce references from animrig
to the editor code.
Pull Request: https://projects.blender.org/blender/blender/pulls/116101
The context menu for the channels is shared
between all animation editors.
Changed "Dope Sheet Channel" label to "Channel"
for consistent channel label in all animation editors.
Pull Request: https://projects.blender.org/blender/blender/pulls/115845
Prior to this PR, the autokeying system used keying sets
to insert keyframes where required.
With the functions introduced in #113504
the code can be simplified and made to not rely on keying sets,
allowing autokeying to also insert keys by rna path directly.
This also removes all the code related to "Insert Needed" from autokeying.
The insert key functions deal with that now, all that is needed is to pass
in the flag.
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/115522
Changing size of framebuffer attachments would
throw an assertion as framebuffer size was not
correctly reset to zero. Zero allows any size
to override the current if there are no set attachments.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/116162
Recent re-ordering change [0] on Wayland window initialization crashed
WLROOTS based compositors, resolve by keeping the updates and only
postponing the state change.
[0]: 39f378da37eedb918a69a31c68c34e5a9263754c
Starting blender with --window-maximized wouldn't always size the
windows properly, similar to the fix for LIBDECOR, move setting the
window state last.
With fractional scale under GNOME, the window frames didn't match
the window contents. This was caused by updates needed to call
libdecor_frame_get_xdg_toplevel initializing the LIBDECOR window
before the window scale, internal buffer - etc were set.
Resolve by accessing moving the window state assignment last.
When the final buffer scale is known, set the window scaling on startup.
This avoids scaling immediately after creating the window which
flickers. It also resolves an paper-cut with KDE where fractional
scaling caused the window to be placed on the screen center,
then the size increased pushing the window contents off the bottom right
hand portion of the screen.
