There is an implementation flaw in the render graph where local pointers
cannot be updated, but the data it refers to can be reallocated to
another location.
The cause of this is that the nodes use an union, which can only contain
simple constructed structs (eg memcpy). this union is stored in a vector
and can relocate the union. Any local pointers can (and will) become
invalid.
This PR is a quick fix by updating the pointers just before sending
them to the command buffer. In future a better fox needs to be done
as part of #121649.
Pull Request: https://projects.blender.org/blender/blender/pulls/121723
The render graph tests initialized a command buffer wrapper that
requires a working device. The wrapper was not used, but when
destructing it would try to deallocate the command buffer, which
cannot be done as that requires a working device as well.
This PR removes the unneeded command buffer wrappers in the test
cases.
By adding NSURLBookmarkResolutionWithoutMounting to options to keep MacOS from attempting to mount shortcuts.
This addresses that blender hangs and crashes if there's a shortcut to a network drive that cannot be mounted at that time.
Pull Request: https://projects.blender.org/blender/blender/pulls/121673
Overlay texts were previously drawn with two sets of shadows:
- 3px blur,
- 5px blur, slightly offset
But since the shadow color was always set to black, it was still
causing legibility issues when the text itself was dark (set
via theme for example).
This PR adds a new "outline" BLF text decoration, and uses that
for the overlays. And it picks text/outline color depending
on the "background" color of the view.
Details:
- Instead of "shadow level" integer where the only valid options
are 0, 3 or 5, have a FontShadowType enum.
- Add a new FontShadowType::Outline enum entry, that does a 1px
outline by doing a 3x3 dilation in the font shader.
- BLF_draw_default_shadowed is changed to do outline, instead of
drawing the shadow twice.
- In the font shader, instead of encoding shadow type in signs of
the glyph_size, pass that as a "flags" vertex attribute. Put
font texture channel count into the same flags, so that the
vertex size stays the same.
- Well actually, vertex size becomes smaller by 4 bytes, since turns
out glyph_mode vertex attribute was not used for anything at all.
Images in the PR.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121383
Result isn't consistent on Windows platform due to copying structs with arrays.
This is a quick fix and will be looked at next week. The code isn't used at this moment.
Pull Request: https://projects.blender.org/blender/blender/pulls/121670
Caused by using timeline frame instead of frame index as argument for
`seq_retiming_evaluate()` in `claculate_speed_table_from_seq()`.
This bug only affected speed transitions in sound strips.
`RetimingRangeData` also incorrectly interpreted segment type after
transition end, which would not cause issues, but was incorrect.
This PR ensures the ClosureLightStack is only accessed
with constant indices. This reduces compiler spill and allows
furhter constant folding, improving the deferred lighting
evaluation performance by 30%.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/121124
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
This implements removing of groups and adds an operator
`GREASE_PENCIL_OT_layer_group_remove`.
Groups can be removed in two ways:
* Remove the group and keep the children.
* Remove the group together with all its children.
Based on an earlier attempt by @PratikPB2123 here: !121611
Pull Request: https://projects.blender.org/blender/blender/pulls/121663
New drag type `WM_DRAG_GREASE_PENCIL_GROUP` introduced for layer group nodes.
Replaced layer struct with `GreasePencilLayerTreeNode` in `wmDragGreasePencilLayer`
so group node can be stored while dragging in `wmdrag->poin`.
Using `can_drop()`, drop operation of layer group node returns `false`
if the target node is its child.
Part of #121390.
Pull Request: https://projects.blender.org/blender/blender/pulls/121654
This allows to expose these settings in the Performance panel in the
render buttons. Also moves compositor-specific options away from the
generic node tree structure.
For the backwards-compatibility the options are still present in the
DNA for the bNodeTree. This is to minimize the impact on the Studio
which has used the GPU compositor for a while now. They can be
removed in a future release.
There is no functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/121583
This adds the functions `has_active_group` and `get_active_group`,
similar to the `has_active_layer` and `get_active_layer` ones.
Also refactors some of the code to use these new functions instead.
PR #121478 added options for blurred shadows and text outline for text strips.
However since text strips produce an image that is size of the "whole screen",
applying large blurs or wide outline on that is quite costly.
Make both blur and outline calculations only be performed on the text bounds
(offset and expanded as needed to take into account blur/outline width).
On Windows/VS2022/Ryzen5950X machine, with 4K VSE resolution, and text strip
that takes about 900x400 pixels on screen, applying blur 0.4 and outline 0.25,
time to render the text strip goes from 470ms down to 35ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/121644
Make the preview window translate/grab too round the resulting strip positions
to integer pixels. Resulting strip will more often end up using faster
interpolation (without bilinear), and avoids "text edges are too dark"
artifacts with light text strips on light backgrounds.
The latter happens because bilinear filtering does not do full alpha
premultiplication, so a text strip pixel that is just outside the glyph ends up
being (0,0,0,0) which under bilinear filtering sneaks in a dark color into the
glyph edge.
Example images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/121652
This moves the responsibility for handling the "Only Insert Needed"
flag from `insert_keyframe_value()` to the lower-level function
`insert_vert_fcurve()`.
We're doing this because `insert_vert_fcurve()` is the common entry
point between the new animation system's and old animation system's
keyframing code. This therefore ensures that both systems will
behave the same way with respect to the "Only Insert Needed" flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/121525
When keying custom properties that are defined by an addon,
you can't use square brackets. The GUI buttons already reflect that.
The baking code and the keyframe insertion code didn't respect
that and so were able to key properties that are defined as non-keyable.
## Solutions
I've solved the issue on the C++ side by resolving
the path twice, once without and in case that didn't work the
second time with brackets. While that does solve the issue
this feels really dirty and I feel like I am misusing the system here.
**However it is absolutely needed**.
When resolving a path with brackets to a property defined
by an addon, you get an `IDProperty` disguised as a `PropertyRNA`
which will not have the correct flags set.
By checking if a property `is_animatable` in python, all that do not have that can be skipped.
Also making sure the path is passed without brackets in the correct cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/121520
Both `autokeyframe_object()` and `autokeyframe_pose_channel()` had an
odd structure where they would call completely different keying
functions depending on whether "Only Insert Available" was toggled on
or not. This not only overcomplicated the code, but also introduced
the possibility for divergent keyframing behavior depending on whether
that flag was set or not, beyond the intended effect of the flag.
This commit changes both functions to call the same keyframing function
(which already handles that flag correctly on its own) regardless of
whether that flag is set or not, unifying the keyframing behavior and
simplifying the code.
As a happy side effect, auto-keyframing failures are now reported even
when "Only Insert Available" is disabled, which wasn't the case before.
(An example of the aforementioned unintentional divergent behavior.)
Pull Request: https://projects.blender.org/blender/blender/pulls/121476
The flag for "Only Key Available" was weirdly omitted from the flags
returned by `get_autokey_flags()`, always being set to false. This
happens to be okay at the places the function is currently used, but
it is unexpected and a likely footgun for future changes to the code
that uses it.
While `do_versions_after_setup` does more than what was previously done
by link/append code (essentially also handles pre-2.50 IPO and sound
proxy conversions), there is no real fundamental reasons to not use it
in linking code.
The IPO and sound proxy conversion codes are likely fully broken for
linked data - but they should then be removed or fixed, since they will
be applied on linked data in blendfile reading case anyway.
And in general, versioning should 'just work' the same when loading a
whole blendfile, or linking some data from a library. Keeping things
separate only makes it harder to work with, and easier to hide issues
with linked data.
While `BKE_blendfile_link` is used in both cases, there is a small
subset of its code only executed in linking case. It now lives into its
own util function, for clarity.
There should be absolutely no functional change in this commit.
Handling of the blendfile handle freeing when linking data from a
blendfile requiring endianness conversion was totally broken, leading
to double-freeing attempts.
Guess that the fact that this was never reported shows how rare
'big-endian' blendfiles are nowadays... But we still have a few in our
test repo.
Adds support for clear attachments to the render graph.
Clearing attachments require that the command buffer is
being set for rendering (vkCmdBeginRendering).
**What works**
- Clear attachments are working with dynamic rendering and the render graph
- `GPUVulkanTest.framebuffer_clear_color_single_attachment`
- `GPUVulkanTest.framebuffer_clear_color_multiple_attachments`
- `GPUVulkanTest.framebuffer_clear_multiple_color_multiple_attachments`
- `GPUVulkanTest.framebuffer_scissor_test`
- `GPUVulkanTest.framebuffer_clear_depth`
**What still needs to be addressed**
When a command buffer is rendering it cannot do any pipeline
barriers. For clearing attachments this isn't needed, but when
we address drawing we might need to register drawing resource
dependencies to the dependency list of the begin rendering node.
This will be solved when drawing will be implemented. [#121648]
The begin rendering node is large as it has to store data for
framebuffers with 8 color attachments as well. This might
become an overhead and we could solve this by splicing the
data of larger nodes into 2 lists. This will be addressed
after we are able to draw a screen so we can collect data
on this topic. [#121649]
Pull Request: https://projects.blender.org/blender/blender/pulls/121073
Sets missing context menu region in popovers that is required to handle drag collapse
event.
Also fix layout panel header but events handling.
| Main | Fix |
| -------- | -------- |
| <video src="/attachments/03409a9f-751d-4b4c-b464-d62a65b9b477" title="2024-05-08 12-21-14.mp4" controls></video> | <video src="/attachments/a50be151-8d5e-485d-bc47-3e2c7292c063" title="2024-05-08 12-18-08.mp4" controls></video> |
Pull Request: https://projects.blender.org/blender/blender/pulls/121594
This function returned the duration in frames for a keyframe, but
for keyframes that are implicitly held until the next keyframe,
it makes more sense to return 0.
For `insert_frame` a duration of 0 also creates an implicit hold
so this is more consistent with this API and removes a few checks
elsewhere.
