If a curve was not using U parameter range of 0..1, the importer
did not properly detect whether the "U endpoint" flag should
be set on it. Fixed that, along with test coverage for the case.
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.
Copy modules before filtering `addon_modules` to avoid
change of dictionnary size during iterations. Otherwise errors
can be triggerd when running `python -m pytest test.py` since
it may modify the module dict.
Co-authored-by: Alexis-19 <alexis-19@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/121100
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.
This PR contains optimisations and a general tidy-up of the MetalRT backend.
- Currently `scene_intersect` is used for both normal and (opaque) shadow rays, however the usage patterns are different enough to warrant specialisation. Shadow intersection tests (flagged with `PATH_RAY_SHADOW_OPAQUE`) only need a bool result, but need a larger "self" payload in order to exclude hits against target lights. By specialising we can minimise the payload size in each case (which is helps performance) and avoid some dynamic branching. This PR introduces a new `scene_intersect_shadow` function which is specialised in Metal, and currently redirects to `scene_intersect` in the other backends.
- Currently `scene_intersect_local` is implemented for worst-case payload requirements as demanded by `subsurface_disk` (where `max_hits` is 4). The random_walk case only demands 1 hit result which we can retrieve directly from the intersector object (rather than stashing it in the payload). By specialising, we significantly reduce the payload size for random_walk queries, which has a big impact on performance. Additionally, we only need to use a custom intersection function for the first ray test in a random walk (for self-primitive filtering), so this PR forces faster `opaque` intersection testing for all but the first random walk test.
- Currently `scene_intersect_volume` has a lot of redundant code to handle non-triangle primitives despite volumes only being enclosed by trimeshes. This PR removes this code.
Additionally, this PR tidies up the convoluted intersection function linking code, removes some redundant intersection handlers, and uses more consistent naming of intersection functions.
On a M3 MacBook Pro, these changes give 2-3% performance increase on typical scenes with opaque trimesh materials (e.g. barbershop, classroom junkshop), but can give over 15% performance increase for certain scenes using random walk SSS (e.g. monster).
Pull Request: https://projects.blender.org/blender/blender/pulls/121397
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.
