SEQ_modifier_apply_stack is called from exactly one place, and it always
was throwing away the input image, and taking the newly produced image.
Which means, we can stop copying it. Just run the modifiers on the
input image.
In a test file that is HD (1080p) resolution, two EXR image sequences,
adjustment layer with Color Balance, and a text strip on top,
playback framerate (Ryzen 5950X, Win10/VS2022) goes 20.8 -> 22.1 fps
Pull Request: https://projects.blender.org/blender/blender/pulls/127346
When a strip with alpha-over blend mode (which is default) has an alpha
channel and is at the bottom of the whole stack, there's no point in
blending it with black color; the result will be identical.
So stop doing that. Also, whenever some other case happens at the bottom
of the stack (e.g. some other blend mode), create the fake "black input"
image at the needed color type (float or byte) and with the correct
color space already applied. Otherwise, especially for floats, VSE
spends much time converting this fake black input from byte to float,
and then converting it to sequencer color space.
Test case of two EXR files blended over each other, at 4K resolution,
on Ryzen 5950X (Win10/VS2022):
- whole sequencer_preview_region_draw 115ms -> 75ms
- seq_render_give_ibuf part: 64ms -> 24ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127310
IMB_buffer_byte_from_float for "predivide" case was doing two function
calls per pixel. Make it do the work with one function per pixel.
Do the same in IMB_buffer_byte_from_float_mask.
IMB_buffer_byte_from_float on one thread, running on 4K resolution
image, on Ryzen 5950X (Win10/VS2022): 27.4ms -> 24.4ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127308
cpuProcessorApply_predivide was doing, for each pixel:
- Un-premultiply pixel to straight alpha
- Call OCIO processor on that one pixel
- Premultiply pixel back
This is not great due to just function call overhead, and probably
prevents whatever "batch processing SIMD optimizations" that OCIO
migth have.
Instead, do this:
- Un-premultiply whole input image,
- Call OCIO on the whole image to do whatever it does,
- Premultiply whole image back.
Doing cpuProcessorApply_predivide on a 4K resolution, float4 image
on Ryzen 5950X (Win10/VS2022) on one thread: 128ms -> 69ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127307
In VSE, the default setting is that even float images are all in sRGB
(or rather, display) space. However code that was drawing the final
VSE float image on screen, was first converting it to linear space,
and then back to display space.
An optimization already existed that skipped "no-op" conversions for
byte images. This adds a similar case for float images.
Note: I found a previous fix to an old issue (#39953, commit fe29f92030)
in related code. Probably should be double checked whether it has not
regressed.
VSE at 4K resolution, with a single 4K resolution EXR image strip,
playback on Ryzen5950X (Win10/VS2022):
- Playback average FPS 11 -> 18
- Time for sequencer_preview_region_draw part: 92ms -> 58ms
- Time for sequencer_draw_display_buffer in there: 52ms -> 15ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127305
Prevent actual selection (keeping activation of the bone).
Since `buttons_context_path_bone` / `buttons_context_path_pose_bone` go
after `arm->act_bone` / `arm->act_edbone` to set the context "bone",
"pose_bone" or "edit_bone" -- and that is set no matter what in
`tree_element_bone_activate` / `tree_element_active_ebone__sel` -- we
can set the bone active, not actually select it and the Properties
Editor can still show the relevant info.
Pull Request: https://projects.blender.org/blender/blender/pulls/127235
The encoding of mat3 in std430 was incorrect leading to a drawing
artifact in the direction control of sunlight in sky textures.
The error was that every 3 floats requires an additional float
as each row of the mat3 is aligned to 16 bytes.
Pull Request: https://projects.blender.org/blender/blender/pulls/127246
The approach taken here is really simple: just check if the channel
either is or belongs to an action slot, and if so then reduce the
alpha of its text label if it's unselected and its slot has no users.
Pull Request: https://projects.blender.org/blender/blender/pulls/127257
These icons are extremely order dependent and set dynamically in a
four-way option at:
`rna_object_type_visibility_icon_get_common`
Problem introduced on: 60cc73afe6, when I sorted the non-toggle icons
alphabetically.
Bug reported by Pablo Vazquez in real life.
This PR implements the "Smooth" operator in Weight Paint mode for GPv3.
The Smooth operator smooths the weights in the active vertex group by
applying a gaussian blur to the vertex weights.
The operator has two properties:
- `factor` (0.0 - 1.0): The extent to which the smoothed weight is
applied to the original weight, where 0.0 is 'keep the original weight'
and 1.0 is 'replace fully with the smoothed weight'.
- `repeat`: The number of times the smoothing is executed. A higher
value means more smoothing.
The operator is added to the 'Weight' menu in Weight Paint mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/126429
`frame_at()` returns previous keyframe of which the drawing is visible
at current framec. When previous keyframe is selected, all the intermediate frames
till iteration reach the next keyframe are also exported.
To fix this, look inside `frames()` map instead of `frame_at()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/126779
Each time the face bounds are used after they're initially computed, we
recompute the center of the bounds. We only use the actual bounds to
calculate the bounds of each node to decide how it should be split.
This commit changes to store the bounds centers instead, and just use
the full bounds as a type for the parallel reduction.
In a test with a 16 million face grid on a Ryzen 7840U, I observed a
1.28x decrease in BVH build time, from 1072 to 836 ms.
I didn't apply a similar change to multires grids BVH building because
it's not clear the same bottleneck exists due to the lower ratio of
"primitives" (grids) to final subdivided vertices.
The "simplify" comment copied many times shows that these
aren't helpful-- they waste space and give the wrong impression
about the purpose of code comments.
When I first developed the attribute filters they were just a `FunctionRef`
and thus could be stored by value in this struct. Now that they are a
virtual type, that is not possible anymore.
This commit opts to align the behavior with `vert_neighbors_get_mesh`
which also clears the provided vector instead of leaving it up to the
caller to do so.
Pull Request: https://projects.blender.org/blender/blender/pulls/127273
Raycast and "nearest to ray" use the local vertex indices from triangles
to index original data, which needs to be sized with all the vertices, not
just unique vertices. Add a new function to access that data.
Mouse cursor changes when hovering at the top of popup blocks to
indicate that these can be dragged. On Mac this looks like a hand,
while for other platforms it is a drag cursor.
Pull Request: https://projects.blender.org/blender/blender/pulls/118358
Add multiple "hand" mouse cursors. These are mostly needed for Mac,
which needs open, close, and pointing hand cursors. This also adds
similar for Windows, but just for completeness and testing.
Pull Request: https://projects.blender.org/blender/blender/pulls/127164
Enable deferred parallel batch compilation for image renders.
This replaces the use of the `WM_job` system with a regular thread,
since `WM_job` requires access to the main context,
which is not accessible from the render thread.
It also simplifies the system so it creates a single thread at startup
and deletes it at exit.
Pull Request: https://projects.blender.org/blender/blender/pulls/125005
The code that decides the indentation for channel groups and fcurve channels
already accounted for the difference between the Action Editor and Dopesheet/
Graph Editor, since the level of nesting is different in the Action Editor vs
the other two. However, it didn't account for the difference between legacy and
layered actions, which have different nesting in the Action Editor.
Additionally, before layered actions were introduced it was impossible for
the Action Editor to display channels from e.g. materials, but those channels
can now be displayed in the Action Editor via the slot system. However, the
indentation code was structured such that material (etc.) channels were *always*
indented as if they were in the Dopesheet/Graph Editor, where they're always
nested under the IDs that use them.
This commit fixes the issue by having a separate code path for indenting in the
Action Editor that only indents channel groups and fcurve channels, and which
properly handles the difference between layered and legacy actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/127202
When converting a legacy Action to a layered Action,
also convert group memberships.
This is important for bones to retain their structure in
the Channel Box.
Pull Request: https://projects.blender.org/blender/blender/pulls/127188
This adds layered animation support to the following operators, allowing users to manage the grouping and arrangement of fcurves in the channel list:
- "Group Channels"
- "Ungroup Channels"
- "Move Channels"
Pull Request: https://projects.blender.org/blender/blender/pulls/127080
The cause was simple: I missed this operator in the initial layered-action
channel group implementation, so deletion was using the legacy action code
even for layered actions.
This implements the needed code in the deletion operator to handle layered
actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/127242
Renderdoc only export extensions it supports.
`VK_EXT_dynamic_rendering_unused_attachments` is not supported by
renderdoc and therefor no devices could be found to start the vulkan
backend.
In GHOST we already work around this issue by not checking this specific
extension. We should do the same in VKBackend.
Pull Request: https://projects.blender.org/blender/blender/pulls/127236
The `Action.groups` RNA functions now work with layered Actions as well.
They just expose / operate on the groups of the channelbag that belongs
to the first slot of the Action.
Pull Request: https://projects.blender.org/blender/blender/pulls/127241
Protect the backward-compatible API implementation with
`#ifdef WITH_ANIM_BAKLAVA` directives.
This also moves the `use_backward_compatible_api()` function further up
in the file, to the place where I'll need it when building the backward-
compatible API implementation for Action groups.
The backward-compatible API implementation makes the legacy Action API also
work on new layered Actions, exposing the data for the first slot.
Pull Request: https://projects.blender.org/blender/blender/pulls/127241
Add group name support to the backward-compatible implementation of
`Action.fcurves.new()`. This ensures that the legacy Action API creates
a new-style channel group in the appropriate channel bag.
Pull Request: https://projects.blender.org/blender/blender/pulls/127241
