The recent change to the 'Add Modifier' created at least two issues:
* A complete duplicate of UI info for each modifier (its name and icon),
now existing in both the RNA enum definition of modifiers types, and
in the pyhton UI code.
* An implicit duplication of these UI names in two different translation
contexts, since the ones from the enum use the default one, while
explicit labels passed to the `layout.operator` UI API get assigned a
default 'operator' context. See PR !112246 for details about this.
Both issues can be easily solved by making the new python code for these
menus a bit smarter. Adding a helper function that adds the `add_modifier`
operator with the right parameters, just based on the operator type.
Both names (labels) and icons can be found in the enum property
`bl_rna` definition itself then.
This change:
* Avoids duplicating UI info.
* Fixes translation context mismatch, by forcing the usage of the
default one also from the python code.
* Makes code less verbose and overall more readable.
NOTE: An attempt has been made to use the `get_name` callback of
operator types to automatically return the right name based on the
defined type, but this is currently utterly failing with regular
layout-based UI code. This will be reported and handled separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/112252
Regression in [0] which removed empty regions that were used to
ensure pie menu items match the location of regions.
The header for e.g. in time-line / graph editor for e.g. showed
on the opposite side.
[0]: 48b8c8f78f
During the recent operator renames, the menu
entry for "Sound to Samples" was missed and
left as "graph.sound_bake"
This fixes it to be the correct "graph.sound_to_samples"
After Renaming "Bake Curve" to "Samples to Keys" in #111049,
the name of the `ACTION_OT_sample` operator needed renaming.
That is because the word "sample" is now used to describe FCurve
data in an uneditable state.
Rename to `ACTION_OT_bake_keys` since baking is the
term used in animation to describe the action of creating dense key data.
Pull Request: https://projects.blender.org/blender/blender/pulls/112151
After Renaming "Bake Curve" to "Samples to Keys" in #111049,
the name of the `GRAPH_OT_sample` operator needed renaming.
That is because the word "sample" is now used to describe FCurve
data in an uneditable state.
Rename to `GRAPH_OT_bake_keys` since baking is the term
used in animation to describe the action of creating dense key data.
Pull Request: https://projects.blender.org/blender/blender/pulls/112148
The `VIEWLAYER_PT_eevee_next_layer_passes_data` class name was
re-used by mistake for Workbench Next in ba982119cd,
and the actual EEVEE Next class was then removed in 678dc456e3.
This adds back the UI as it was, and the missing passes (Vector and
Position) it referenced.
Pull Request: https://projects.blender.org/blender/blender/pulls/112162
Now that specific menus can be searched directly (see 7f9d51853c),
there is no need to maintain separate search functionality for adding
nodes. This PR removes the add node search. In a way this brings us
closer to the `NodeItem` situation before, but the setup is more
flexible since the menus are more standard and easier to customize.
In the few ways we customized the node search items before, this gives
us the same results as before. Overall the searching is less flexible,
but I think that is just a tradeoff we have to accept for the simplicity
of searching menus. In the future menus could be made more dynamic,
with each builtin node's menu path stored on the node type, similar to
assets. That might be a nice compromise. In the meantime this code
is just dead weight.
Pull Request: https://projects.blender.org/blender/blender/pulls/112056
This operator is a combination of the previous delete operator `frame` mode
and the `active_frames_delete_all` operator.
This also add the delete menu and key binds.
While it isn't "wrong" to have the name listed below too, In Blender
the name of an item is usually edited by double clicking inside
of list/tree views, and it's better to be consistent.
Use the asset icon for the "Mark Asset" operator in menus.
Using icons is not only good for accessibility, but also to create
a connection with the Asset Browser and the icon shown in the
data-block template once marked as asset.
Pull Request: https://projects.blender.org/blender/blender/pulls/112111
Reasons to keep calling it Geometry Nodes:
* People can search for Geometry or Nodes and find it.
* It makes a connection with the editor called Geometry Nodes.
Interesting enough these were similar reasons to the original discussion
we had when Geometry Nodes first got added to Blender. Basically the
reasoning is still valid.
Counter-arguments:
* Over-time more and more modifiers will be geometry-nodes based, it
could be seem as strange to single out one of them.
* Once we have different node-base systems that may also work as
modifiers (e.g., collection modifiers?) we will need a more unified
name.
The response to the latter is that once we get to this we will also
rename the editor. Until then we keep what is working.
Breaking change since the operator name changes.
Users have been confused about this for a long time.
The term "bake" in the context of animation usually means
to add keys at a given interval without changing the shape of the curve.
The fact that the curve isn't editable after baking was the main issue.
In order to stop the confusion the operator is renamed to "Keys to Samples"
to indicate that there is a conversion happening and that there are no keys afterwards.
The Un-Bake operator has also been changed to "Samples to Keys"
The operator description has been updated to mention that after the conversion
the data is no longer editable.
The "Bake Sound to F-Curves" has been renamed to "Create Samples from Sound"
Pull Request: https://projects.blender.org/blender/blender/pulls/111049
This patch has been originally authored by Ares Deveaux #106526
Scale the selected key segments to their average
Unlike just scaling using the transform tools, this scales to the average of each individual F-Curve segment.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/111744
There are no more bone groups, and the colors have been moved to the
bones themselves (042c5347f4). Now the
armature property that controls whether they're shown or not also refers
to 'bone colors' instead of 'group colors'.
This was needed while testing #96544, now all curve picking selects
bezier knots without handles - the option can be removed.
This is a functional change for the 2.7x keymap, however selecting
bezier points with handles isn't a useful difference to keep.
Add a 'Custom Properties' sub-panel to the Bone Collections panel.
Custom properties for bone collections were introduced in 9eee076a29,
this just adds the GUI.
Ref: #108941
The basic idea is very simple. Whenever a supported menu is open, one can just
start typing and this opens a search that contains all the (nested) menu entries.
The main downside is that this collides with accelerator keys. Those are the
underlined characters in each menu. For now, we just enable this new searching
behavior in a few selected menus: Node Add Menu, View3D Add Menu and
Modifier Add Menu.
This new functionality can be enabled for a menu by setting
`bl_options = {'SEARCH_ON_KEY_PRESS'}` to true in the menu type.
The status bar shows `Type to search...` when a menu is opened that supports search.
Pull Request: https://projects.blender.org/blender/blender/pulls/110855
Change the existing "Is Shade Smooth" node to be named "Is Face Smooth"
and add a new "Is Edge Smooth" node. Also give the "Set Shade Smooth"
node the ability to set face or edge smoothness.
The fact that the nodes process "smooth" data reversed from the builtin
"sharp" attributes can be reversed with versioning in a separate commit.
While it's tempting to abstract the sharpness status into a single node,
face and edge smoothness are accessed separately in edit mode, and the
subtlety of interacting with data on different domains would make that
confusing. Instead, a separate "Is Shade Smooth" node group asset will
give all the sharp elements taking into account both builtin attributes.
The fact that sharpness is stored separately on two domains makes the
best design for simple operations non-obvious. For example, you should be
able to remove all sharpness or make everything flat with a single node.
The behavior depends on whether the two attributes exist and the
combination of values between the domains.
---
Pull Request: https://projects.blender.org/blender/blender/pulls/112029
In paint modes, show a selector for the active canvas, similar
to how other editors (UV/Image, Nodes, Action) do it.
Available canvas in each mode:
* Weight Paint: Vertex Groups
* Vertex Paint: Color Attributes
* Texture Paint: Canvas (material, image)
* Sculpt Paint: Color Attributes, canvas in experimental sculpt paint)
Pull Request: https://projects.blender.org/blender/blender/pulls/111756
Add the features missing from #107176
* Irradiance integration.
* Self-shadows.
* Receive shadows from shadow maps.
Shadow tagging works by iterating all the froxels in a
compute shader and tagging the exact same position
that will be sampled by the volume scatter shader.
Froxels that are fully transmissive, have no scattering,
or are behind opaque geometry, are skipped.
It also adds a LoD bias parameter for shadow tagging,
driven by the volumetric tile size.
This works for punctual shadows, but directional lights
would need a way to support re-direction between levels
at sampling time, which is out of the scope of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/110809
An error in the key-map could cause the default keymap to be removed
leaving Blender without a default keymap.
Prevent the crash, even though Blender wont be usable in this state.
