Resolve regression introduced in [0] intended to fix another regression
introduced in [1] to resolve an assert from [2] (a C++ cleanup).
Recent changes made the array modifier return early with the start-cap's
mesh however this meant the required custom-data layers wouldn't
necessarily exist on the returned mesh, causing selection to crash.
Besides this the same logic was missing from the end-cap.
Resolve by restoring the logic from before [1],
adding a check to prevent the assert.
[0]: 9ad6957574
[1]: 8b2556e8d8
[2]: cb62ab5b28
ID names of images that included slashes would attempt to write
save the image in a sub-directory based on those slashes.
Also add notes to clarify the intended use of "safe" path functions.
- Wrap the closing parenthesis onto it's own line
which makes assignments to the return value
read better.
- Reduce right-shift with multi-line function calls.
For xray_alpha and xray_alpha_wireframe replace the word "alpha" with
"opacity" in the tooltip description to better suit its use in the
interface, where 0 is transparent and 1 is fully opaque.
Pull Request: https://projects.blender.org/blender/blender/pulls/133025
Prevents creation of Bezier curve's `IndexMask` when it is not needed.
It was created on every request, even when `CurvesBatchCache` was valid.
Also prevents redundant initialization of `GeometryDeformation`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133017
Capitalize the default filename used for .blend files and other savable
and exportable file formats (like images, 3D formats, etc.) from
"untitled" to "Untitled".
Pull Request: https://projects.blender.org/blender/blender/pulls/132424
8ce5356522 removed the `View2D` and `Frames` keymaps from the
`keymapflag` for the preview in order to avoid having them trigger while
adding/editing text.
Although the `View2D` keymap items were restored by registering them
after the `SequencerPreview` keymap in
`sequencer_preview_region_init()`, the `Frames` keymap was neglected, so
fix by registering it too.
Pull Request: https://projects.blender.org/blender/blender/pulls/132972
When menus (that are not type-to-search) open we add underlines to
most items so they can be selected quickly. We currently don't do this
for items that are toggles. This PR adds accelerators to toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/132309
Just like legacy Actions get a slot "Legacy Slot" when they're
versioned, their layer is now also called "Legacy Layer" to be
consistent with that.
When upgrading a legacy Action to a slotted Action, it also gets a layer
and a keyframe strip on that layer. Those are not shown in the user
interface yet, but will in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/133009
Internationalize the default Action layer name. Instead of `"Layer"`,
use `DATA_("Layer")`. This is the same for other defaults in Blender.
When upgrading a legacy Action to a slotted Action, it also gets a layer
and a keyframe strip on that layer. Those are not shown in the user
interface yet, but will in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/133009
- At import => Create some multi-slot action if multiple node are impacted by the glTF animation
- At export =>
- Multi-slot actions are exported as a single glTF animation by default
- There is still an option to get back to previous feature, merging by track name instead of by action
KHR_animation_pointer is not part of this PR.
animation pointer data are still exported only when using full baking (NLA track or scene export mode).
Using animation pointer related slots for other mode will come in a second step, not planned yet (and will not be part of 4.4)
Some hooks definition changed, and some hook locations changed because of this new behavior.
Communication for hook devs still need to be done
PR: #132771
Pull Request: https://projects.blender.org/blender/blender/pulls/132771
Previously, the owner-id on localized node trees, like the one created in
`GPU_material_from_nodetree` would have `bNodeTree::owner_id` set, even though
they were independent. The leads to asserts when using `BKE_id_owner_get` on the
localized node tree.
The `node_tree_localize` already took a `ID *new_owner_id` parameter. However,
if it was `nullptr` it was ignored instead actually clearing the `owner_id`.
This patch changes the parameter to `std::optional<ID *> new_owner_id`. Now,
`std::nullopt` means that the value is ignored and when `nullptr` is passed in,
the `owner_id` will be cleared on the localized tree.
Since `node_tree_localize` indirectly uses other functions, the same function
signature change is done in `BKE_libblock_copy_in_lib` and `BKE_id_copy_in_lib`.
The callers have been updated to pass in `nullopt` instead of `nullptr`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133002
This patch adds a new `BKE_main_ensure_invariants` function. For now it only
ensures node-tree related invariants, but more may be added over time.
The already existing `ED_node_tree_propagate_change` now internally calls
`BKE_main_ensure_invariants`. We can probably remove this indirection at some
point and call the new function directly, but for now it is kept to keep this
patch small.
This is based on a recent discussion in the Core module meeting:
https://devtalk.blender.org/t/2024-12-12-core-meeting/38074
```cpp
/**
* Makes sure that invariants in original DNA data are maintained after changes.
*
* This function has to be idempotent, i.e. after calling it once, additional calls should not
* modify DNA data further. If it would, it would imply that this function does more than
* maintaining invariants.
*
* This has to be called after any kind of change to original DNA data that may be involved in some
* of the maintained invariants. It's possible to do multiple changes in a row and then fixing all
* invariants with a single call in the end. Obviously, the invariants are not maintained in the
* meantime then and functions relying on them might not work.
*
* If nothing is changed, this function does nothing and it should not be slower than checking a
* flag on every data-block in the given bmain.
*
* Sometimes, it is known that only a single or very few data-blocks have been changed (e.g. when a
* node has been inserted in a node tree). Passing in #modified_ids can speed up the function
* because it may avoid the need to iterate over all data-blocks to find modified data-blocks.
*
* Examples of maintained invariants:
* - Group nodes need to have the correct sockets based on the referenced node group.
* - The geometry nodes modifier needs to have the correct inputs based on the referenced group.
*/
void BKE_main_ensure_invariants(Main &bmain,
std::optional<blender::Span<ID *>> modified_ids = std::nullopt);
```
This also adds `windowmanager` as a dependency of `blenkernel` to be able to
send notifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/132023
This patch adds two new inputs to the Glare node, Highlights Smoothness
and Max Highlights. Smoothness allows the user to control how smooth the
highlights are after thresholding and Max allows the user to suppress
very high brightness pixels.
Those are essentially similar to the Knee and Clamp options in old EEVEE
bloom, though they work differently.
The issue with the Knee parameter in old EEVEE bloom, aside from being
named after a body part, is that it actually isn't smooth or continuous
around zero if the threshold is sufficiently close to zero relative to
the Knee parameter. That's because zero lies in the smoothing kernel
region in those cases, and since zero pixels becoming highlights is very
bad, EEVEE just returned zero as a special case for zero brightness, but
values like 0.0001 will be full blown highlights.
The new nicely named Smoothness input uses adaptive smoothing such that
the smoothing kernel size will be reduced as the threshold nears zero,
such that smoothed highlights will be continuous and smooth around zero.
The Max Highlights input is similar to clamped, it it suppresses very
bright highlights such that their brightness doesn't exceed the
specified max.
This is a partial implementation of #124176 to address #131325.
Pull Request: https://projects.blender.org/blender/blender/pulls/132864
Two messages were not translatable because they used a string stored
in a variable, or an if/else expression.
One was translated when it should not have, because it prints the name
of a material.
Pull Request: https://projects.blender.org/blender/blender/pulls/132737
The Warning geometry node uses its warning type as label. These enum
items were extracted using the default context, but translated using
"Nodetree". The items Warning, Info and Error, should be quite
unambiguous and translated using the default context instead.
In addition, a string "Unknown" was translated twice. Replace one of
those translations with a simple `N_()` extraction macro.
- "Strength" in the context of Grease Pencil, deals with opacity, and
adjusts the brush stroke alpha.
- "Strength" can mean measurable units like 'noise', 'light', etc.
- Anything else using physical strength in a generic concept.
Issue reported by Hoang Duy Tran.
- "Steps" can refer to staircase steps in the context of curve
profiles. Use already-extracted "Mesh" context.
- In the context of the Grease Pencil noise modifier, refers to a step
number between frames.
- In the general context, refers to a number of times to do an
operation.
Issue reported by Hoang Duy Tran.
- "Space" can be the spacebar key. This uses the UIEvents context
already. One instance is the event type enum item, where "Spacebar"
is the label and "Space" is the description. Since there is no way
to use contexts for descriptions since they are supposed to be more
verbose, the label was renamed to "Space Bar" (acceptable according
to Wikipedia), and the description to "Spacebar".
- In the context of the Grease Pencil, "Space" is a method of spacing
brush strokes.
Issue reported by Hoang Duy Tran.
"Smooth" can be many things, but mostly a verb or adjective depending
on context.
Already handled in the past, but some things were missed or introduced
since then.
"Sharp" can refer to a curve falloff, not a mesh edge's geometric
property.
For an existing enum property `Brush.curve_preset`, use the same
context ID_CURVE_LEGACY as other messages, instead of ID_CURVES.
Issue reported by Hoang Duy Tran.
- In the context of color balance, refers to a power function. Uses
ID_MOVIECLIP context, because the ID_NODE is already used for math
functions.
- In the context of the scale constraint, also a power function.
- In the context of physics and particle settings, refers to a
falloff.
- In the context of property subtypes and units, refers to a
quantity.
Issue reported by Hoang Duy Tran.
"Light" already has multiple contexts, but some were missing:
- In general, "Light" refers to a Blender Light object. In many cases,
this comes from an `id_type` enum, already using the ID context. Use
it also for properties that were missing that context.
- In the context of render passes, "Light" is the actual illumination
factor, not the light emitor. A new "Render Layer" translation
context is introduced for this purpose as no existing ones are both
specific and explicit enough.
Issue reported by Hoang Duy Tran.
