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]: 39f378da37
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.
We shouldn't use parallelism internally for each node, but it snuck in
with recent changes to use `array_utils::gather`. That's a nice change,
but we need a better way to turn off parallelism for that sort of
function. Until that's decided on, add a quick fix to fix the deadlock.
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
Recently this was inlined [0] however the purpose of this define is to
allow for the method of setting the value to be changed.
It also means the hack doesn't have to be explained whenever it's used.
Move the BEZKEYTYPE to DNA, update it's doc-string and restore the
original comment.
[0]: fd3629b80a
In the context of meshes `totface` reads as if its the number of faces
in the mesh. This was infact the number of looptris however as this
is converted into a "bodyface" array, use that as the prefix.
The intent of `ghost_event_proc_timestamp_warning` is to give a console
warning when an event time is outside of an expected 5 second window
around the last time. However if an event happens within the first 5
seconds we get an overflow in a calculation and we get warnings for
normal times within the range.
Pull Request: https://projects.blender.org/blender/blender/pulls/116164
Add "Preserve Current Retiming" option to set speed operator. This
option is enabled by default. When changing speed of retiming segment,
the strip changes length instead of changing next segment speed.
Ref: #112343
This feature improves workflow, where it is necessary to select all
retiming keys after one that is selected in order to change speed of
only 1 segment.
The feature is reusing `sequencer.select` "linked time" feature and
mapped Ctrl key.
Ref: #112343
Caused by 133dde41bb, it is expected behavior now for linked ID in
general, see also #105786 and #106321.
However, Scenes are a special case here, since they are almost never
(and should not be) indirectly linked by other data, and have (almost)
never any real user, unless they are active in one of the open main
windows.
So this commit essentially reverts the new behavior implemented
in #106321, for linked scenes only.
Should be backported to a potential bugfix release of 4.0.
Link/append code sets the scene pointer to `null` when the active
scene is a linked one, to avoid attempt to instantiate linked data
(objects or collections) into a linked scene, which is forbidden.
However, code was still calling some functions expecting a valid scene
pointer, leading to crash.
It is unclear when exactly this issue was introduced code wise. From a
user perspective, it seems to have been revealed between 3.6 and 4.0
release (bisect points at 00a36cbf24, which does not seem to be
directly related...).
In any case, the fix is trivial and safe, so should we do another 4.0
bugfix release, this commit should be backported.
Due to lack of forward compatibility, tool_settings.snap_uv_element
could return empty if a 4.0 file is opened in 3.6.
This causes a Python error when trying to identify the element's icon.
Avoid this python error.
Usually we expect new DNA values do be zeroed when we add them. But the
conversion to the interface format for 4.0 didn't clear the memory, so
behavior was different when updating old files. Fix that by using
`calloc` instead of `malloc`.
