A regression since d579ac2b3f.
Cycles delays allocation of the render buffers, which makes it impossible
to access effective render resolution during rendering. This was making the
drawing code to fall-back to the full scene resolution with only percentage
and crop accounted for.
This change makes it so an empty ImBuf is used to communicate the render
result resolution. It does not have any pixel buffer associated with it,
which actually matches the behaivor prior to the offending commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113282
The Grease Pencil 3.0 layers and groups were not properly translated:
- The layers and groups' names were translated during display in the
layer list. Since they are data, they should be left untranslated at
this time.
- On object creation, the names "GP_Layer", "Color", "Lines", and
"Fills" were not translated at all.
This adds DATA_() macros around to translate them if the user has
enabled translation of new data names.
- The functions returning unique names for layers and groups
unique_layer_group_name() and unique_layer_name() would return
"GP_Layer" and "GP_Group" by default.
These defaults are now translated.
- When adding new layers and groups, the name was always hardcoded to
"GP_Layer" and "GP_Group" because the operators' properties for the
names defaulted to that, and prop defaults cannot be translated.
Instead, make them default to a null string, but choose an
appropriate name when executing the op. This name is chosen by
unique_layer_name() and unique_layer_group_name(), whose defaults
are now translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/112930
This preserves the light linking state when collection is copied manually
via the copy-paste or duplicate functionality, but also should fix the
problem of lost light linking state when adding a collection override.
Pull Request: https://projects.blender.org/blender/blender/pulls/113243
Caused by d579ac2b3f
This change restores the behavior of the flag to how it was prior to
the refactor which used ImBuf for storage in the RenderResult.
This flag still has issues with configurations when there are multiple
scenes in the .blend file, and that it is only "valid" when the image
is actually displayed. However, these limitations and quirks already
existed prior to the refactor commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113199
The position validation when manipulating node group items now includes
outputs..inputs order in addition to sockets..panels order. The method
for finding a valid position has been simplified, it's just a single
iteration of insertion sort.
Versioning has been added to ensure files from 4.0 alpha with
potentially unsorted sockets get re-sorted. This uses `std::stable_sort`
so that sockets keep their relative order apart from the input/output
grouping.
Pull Request: https://projects.blender.org/blender/blender/pulls/113060
This case probably hasn't been triggered before because we rarely move individual
const-components around between geometry sets. This happened in #113083 in the
optimization when all elements are in the same group.
Pull Request: https://projects.blender.org/blender/blender/pulls/113160
Sometimes .blend files have compatibility issues between Blender versions,
because .blend files depended on the specific order of geometry elements
generated by some nodes/modifiers (#112746, #113018). While we make
guarantees about the order in some places, that is relatively rare, because it
makes future improvements much harder. The functionality in this patch
makes it easier for users to notice when they depend on things that are not
expected to be stable between Blender builds.
This is achieved by adding a new global flag which indicates whether some
algorithms should randomize their output. The functionality can be toggled
on or off by searching for `Set Geometry Randomization`. If there are no
differences (or acceptable minor ones) when the flag is on or off, one can
be reasonably sure that one does not on unspecified behavior (can't be 100%
sure though, because randomization might be missing in some places). If
there are big differences, one should consider fixing the file before it comes
to an actual breakage in the next Blender version.
Currently, the setting is only available when `Developer Extras` is turned on,
because the setting is in no menu.
With this patch, if we get bug reports with compatibility issues caused by
depending on indices, one of the following three cases should always apply:
* We actually accidentally broke something, which requires a fix commit.
* Turning on geometry randomization shows that the .blend file depends on
things it shouldn't depend on. In this case the user has to fix the file.
* We are missing geometry randomization somewhere, which requires a fix
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113030
Separate user configuration of subpixel antialiasing from the hinting
options. For example, this allows turning this on while hinting is
"None", or off when hinting is "Full".
Pull Request: https://projects.blender.org/blender/blender/pulls/113027
The grid was pointer was moved to the next element at every loop, which
made `vi.grid` and `vi.mask` disagree. Instead, iterate the grid before
accessing data, so the pointers agree. To avoid unrolling the first loop
iteration or adding a branch for the first iteration, start the grid at
a -1 offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/113015
For text objects, the CharInfo mat_nr material index used to start at 1
(not at zero like for meshes or nurbs).
Code was mostly considering this (but not in all places, so material
index handling (removing/moving) could still go wrong.
As an alternative to !109746 (where it was made sure all places would
make the right assumption about mat_nr starting at 1), this PR now
changes the mat_nr to be zero-based.
This is more in line with other places handling material indices.
Versioning code is in place to properly convert old files.
Fixes#109491
Pull Request: https://projects.blender.org/blender/blender/pulls/112954
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
For Blender 4.0 we decided to support individual icons for different
snap elements.
This was originally contributed by Erik Abrahamsson as !107054 with
some contributions by myself (Germano).
This set of icons being simple geometric symbols, that should be
familiar to CAD artists.
Note that Face and Volume share the same icon (circle). This is
deliberate since they communicate a similar functionality - are not
aimed at precision snapping the same way the vertex or perpendicular
are.
Also note that later we should also try to change the icons shown in
the snap menu to match the symbols that the artists see in the preview
window.
———
On the decision process:
The version currently in main (and rolled back here) was an initial
attempt of aggregating more information to the icons (e.g., by aligning
the icons to the target edges) while making them more suitable to
Blender. After presenting both options to (parts of the) community,
there was nothing fundamentally broken found with either option, though
options diverged over personal preference.
With that in mind, in the latest UI module meeting it was agreed to use
the original proposal then.
This final call was proposed by Dalai Felinto on his role of
commissioner (stakeholder) for the snap polishing tasks (#73993) and
designer for the related Snap Base design #66484.
———
This commit reverts commit 9c2e768f5b.
The reverted icons (referred originally as minimalistic icons) may be
proposed later as a separate theme option.
Caused by a subtle logic change in 17d161f565 and follow ups.
Because they used to be stored in a singly-linked list, the old storage
for `corners_by_space` was backwards compared to the order each corner
was discovered in `split_loop_nor_fan_do`. I don't fully understand how
yet, but the logic when setting edges sharp based on divergence between
neighboring corner normals in a space relied on the iteration direction,
so as a fix, just iterate backwards over the corners in each space.
Reroute node consists only of a socket, it has no body.
Don't allow hiding sockets of reroutes anymore, since it could make the
node invisible or prevent links from being connected to it.
The versioning ensures that the sockets on reroute nodes are not hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/112965
Only the pose library enables the asset shelf by default, but Blender
doesn't come with pose assets, they have to be created by the user. So
when entering pose mode with factory settings, the asset shelf will
currently be just a big empty bar. Plus, pose mode is used for posing
without pose assets quite a lot. So hide the asset shelf by default. The
pose library already shows a toggle to hide/unhide it where the previous
pose library UI was for discoverability.
This is necessary to let popovers redraw when asynchronously loading
data. For example to display assets or asset catalogs as they get
loaded. Needed for the asset shelf catalog selector popover. Menus
already do the same to allow populating the menu with assets as they get
loaded.
Previously, it was only possible to inspect the data from the first iteration. That
applied to both, the viewer node as well as socket inspection. Now, there is a
new `Inspection Index` setting in the zone properties. It specifies which iteration
should be used by the inspection features.
In theory we could support features like counting the index from the end, but
that can be done separately as well, as it likely requires more UI.
Pull Request: https://projects.blender.org/blender/blender/pulls/112818
This PR adds vertex groups to `CurvesGeometry` as well as an attribute read/write accessor.
This is also in preparation for GPv3. Since the goal is to have full compatibility with the current grease pencil features, vertex groups need to be supported.
Grease Pencil allows filtering by vertex group for modifiers.To support this, it also makes sense to have read/write access for vertex groups in the attributes API.
In the future, vertex groups should be just another custom attribute on meshes/curves/grease pencil. There are some more issues to be solved before that can happen. This step gets us a bit closer since the vertex weight data is stored in `CustomData`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106944
Currently retiming is quite awkward, when you need to retime multiple
strips strips in sync. It is possible to use meta strips, but this is
still not great. This is resolved by implementing selection.
General changes:
Gizmos are removed, since they are designed to operate only on active
strip and don't support selection.
Transform operator code is implemented for retiming data, which allows
more sophisticated manipulation.
Instead of drawing marker-like symbols, keyframes are drawn to
represent retiming data. Retiming handles are now called keys. To have
consistent names, DNA structures have been renamed.
Retiming data is drawn on strip as overlay.
UI changes:
Retiming tool is removed. To edit retiming data, press Ctrl + R, select
a key and move it. When retiming is edited, retiming menu and
context menu shows more relevant features, like making transitions.
Strip and retiming key selection can not be combined. It is possible to
use box select operator to select keys, if any key is selected.
Otherwise strips are selected.
Adding retiming keys is possible with I shortcut or from menu.
Retiming keys are always drawn at strip left and right boundary. These
keys do not really exist until they are selected. This is to simplify
retiming of strips that are resized. These keys are called "fake keys"
in code.
API changes:
Functions, properties and types related to retiming handles are renamed
to retiming keys:
retiming_handle_add() -> retiming_key_add()
retiming_handle_move() -> retiming_key_move()
retiming_handle_remove() -> retiming_key_remove()
retiming_handles -> retiming_keys
RetimingHandle -> RetimingKey
Retiming editing "mode" is activated by setting `Sequence.show_retiming_keys`.
Pull Request: https://projects.blender.org/blender/blender/pulls/109044
Previously, it was only possible to bake all simulations at once. This is great
for simple use-cases that, but in more complex setups one can have independent
simulations that should also be baked independently. This patch allows baking
individual simulation zones.
Furthermore, each simulation zone can now also have its own bake path and
simulation frame range. By default the simulation frame range is the scene frame
range, but it can also be customized on the scene or simulation zone level. The
bake path is generated based on the modifier bake path by default, but can be
set to another absolute or relative (to the .blend file) path.
The timeline drawing has been modified as well to be able to show more information
in the case when some simulations are baked and others are not. Instead of showing
a line for every simulation, it shows a condensed view of the important information
using at most two lines:
Is something baked? Is something valid or invalid? Also see #112232.
Pull Request: https://projects.blender.org/blender/blender/pulls/112723
This changes the `action.frame_range` Python API to return an accurate
frame range for actions. Specifically, it was previously special-cased
to return a range with length 1 whenever the length was actually 0. This
led to a bizarre situation where a real frame range of `[0.0, 0.2]` would
return that range as-is, but a real frame range of `[0.0, 0.0]` would
instead return a range of `[0.0, 1.0]`.
The new behavior simply always returns the real frame range.
The reason for the previous behavior was obscure: the relevant code was
also used internally in Blender's NLA system, and returning a zero-length
range could result in NLA strips getting infinite scale. The code is now
separated out appropriately so that the NLA system still gets the
non-zero-length range, while the Python API for actions returns the real
range.
Pull Request: https://projects.blender.org/blender/blender/pulls/112709
Draw anim channel colors as a little rectangle in the channel list,
instead of taking over the entire channel name background. This keeps
the channel names readable, regardless of the channel colors.
Channel colors are typically set via the bone colors, and since those
are chosen for visual contrast in the 3D Viewport, they aren't
guaranteed to also be a suitable background color for the channel list.
Because of this, it's no longer used as such.
The channel 'data' background (i.e. the keyframe area) is now drawn with
a consistent color, and much more subtle.
This also enables the 'Channel Group Colors' setting in the preferences
by default, as it is now way less obnoxious and invasive.
Design task: https://projects.blender.org/blender/blender/issues/69059
Reviewed-On: https://projects.blender.org/blender/blender/pulls/112861
Use of node group assets relies on a few properties written to asset
meta-data for proper filtering of assets in menus (add modifier menu,
node add menu, 3D view menus for tools). Currently these meta-data
properties are written when updating their source properties and when
saving the file. That means they *aren't* written when marking a group
as an asset, which is necessary because the meta-data doesn't exist
before when the group isn't an asset. Currently users have to save the
file to update menus in this case, which isn't intuitive.
As a fix, call the function to write the meta-data when marking a
data-block as an asset.
Pull Request: https://projects.blender.org/blender/blender/pulls/112743
This was discussed in #112022 and on devtalk:
https://devtalk.blender.org/t/vertex-groups-generic-attributes-and-name-clashing/31073
While vertex groups with the same name as attributes should be avoided, since
it can cause ambiguities when using attributes, it's something we can handle
gracefully for now. Enforcing unique names for vertex groups resulted in breaking
other functionality under some circumstances.
This effectively reverts 12ef20990b, except for
the bug fix in `BKE_id_attribute_new`.
#112891 adds a warning to avoid make users aware of duplicate names so that they
can be avoided in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/112889
Currently the iteration over a PBVH node's vertices retrieves mutable
access to the mask custom data layer. This isn't threadsafe, but it is
done in the multithreaded loops over all nodes.
In general, we need to be more careful and conservative about storage
of non-const pointers to mesh data. Ideally we would only have one
mutable reference to a resource at a time. And we should avoid doing
work like looking up custom data layers more than we need to.
To that end, make the pointer to the custom data layer used everywhere
const, and retrieve mutable access before parallel node iteration with
a specific function, and write to the mask data with that in mind.
This pushes us in the direction of sharing less code per PBVH type.
In my opinion that's a good thing, because we can actually optimize for
each type. For example, `write_mask_data` gives a picture of
how each of these hot loops could become much simpler.
Pull Request: https://projects.blender.org/blender/blender/pulls/112690
Currently vertices are mapped to B-Bone segments without taking the
rest pose curve into account. This is very simple and fast, but causes
poor deformations in some cases where the rest curvature is significant,
e.g. mouth corners in the new Rigify face rig.
This patch implements a new mapping mode that addresses this problem.
The general idea is to do an orthogonal projection on the curve. However,
since there is no analytical solution for bezier curves, it uses the
segment approximation:
* First, boundaries between segments are used for a binary space
partitioning search to narrow down the mapping to one segment.
* Then, a position on the segment is chosen via linear
interpolation between the BSP planes.
* Finally, to remove the sharp discontinuity at the evolute surface
a smoothing pass is applied to the chosen position by blending to
reduce the slope around the planes previously used in the BSP search.
In order to make per-vertex processing faster, a new array with the
necessary vectors converted to the pose space, as well as some
precomputed coefficients, is built.
The new mode is implemented as a per-bone option in order to ensure
backward compatibility, and also because the new mode may not be
optimal for all cases due to the difference in performance, and
complications like the smoothed but still present mapping
discontinuities around the evolute surface.
Wiki: https://wiki.blender.org/wiki/Source/Animation/B-Bone_Vertex_Mapping
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
Pull Request: https://projects.blender.org/blender/blender/pulls/110758
The order of collections in the light linking collection is important
as it is used for tie-breaking when the same object is reachable from
multiple linked collections with different light linking state.
This commit utilizes the generic tree view reordering operations to
allow insertion of elements to a specific location and to re-order
existing objects and collections in the light linking collection.
It is possible to re-order both collections and objects, even tough
re-ordering objects does not really make a difference for the light
linking behavior. It is not possible to place an object before
collections.
Pull Request: https://projects.blender.org/blender/blender/pulls/112849
The color returned by `ANIM_bonecolor_posebone_get()` is not supposed
to be edited, so just return it as `const` and take a `const bPoseChannel`
as argument.
This makes the function usable in a wider range of situations, for example
the drawing code (which shouldn't alter any of these colors).
Enable visual keying of bones that are influenced by an IK constraint.
This wasn't possible before, as the visual keying system only checked
constraints on the bone itself, and not whether the bone was part of an
IK chain.
This commit introduces a new `bPoseChannel::constflag` value
`PCHAN_INFLUENCED_BY_IK` that is set whenever the pose bone is part of
an IK chain.
The `pchan->constflag` field is computed during depsgraph evaluation. If
the depsgraph is active, it is now also written back to the original
pchan, so that it can be used in the "should visual keying be used"
function.
Fixes: #76791 "Different results when keyframing visual transforms and
applying transforms manually on IK constraint". Note that visually
keying does *not* copy the visual pose to the current pose. Furthermore,
when visually keying only part of the IK chain, the result of
re-evaluating the IK constraint (for example by moving the scene forward
and then backward by one frame) may still produce a different result, as
the IK chain now has a different start orientation.
Note that commit explicitly does not cover Spline IK constraints. They
can introduce heavy shear, especially with the default settings, which
cannot be represented by keys on loc/rot/scale.
For historical reference: 876cfc837e
introduces the 'use visual keying' preference option, where Blender
automatically chooses whether or not to use visual keying. This is why
there is a function at all that determines whether to use visual keying
or not.
Rename the `bPoseChannel::flag` `PCHAN_HAS_TARGET` to `PCHAN_HAS_NO_TARGET`
as that is actually the meaning of the flag (in the majority of the code).
Since the flag was so confusingly named, there were some mixups in the
armature overlay drawing code as well, which have been fixed now too.
Change the definition of the `PCHAN_HAS_CONST` pose channel flag. It used
to mean "has a constraint that is not IK or Spline IK", and now it just
means "has a constraint".
This has no direct effect yet, as the flag is only used in drawing code
when there is no (spline) IK constraint. However, I feel that the flag
name should match its expected behaviour, and IMO, in this case, making
that behaviour simpler is better than documenting more.
Refactor `BKE_pose_channel_copy_data()` so that it iterates over the entire
armature only once (instead of twice), and to use a `switch` instead of
a chain of `if`/`else if`/`else` clauses.
No functional changes.
Add a checkbox to node group inputs to force inputs to be single values
and not accept varying fields. While this could also be done more
automatically, and it could be argued that requiring the flexibility is
helpful for users who want to use attributes, there are cases where the
field inferencing doesn't work, or the "use attribute" option is just
unhelpful. People use workarounds with primitive nodes to get the same
behavior anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/112745
When texture painting on a Non-color byte texture with Texture limit active
(or the texture didn't fit on the GPU) the data for partial updating of a GPU
texture was incorrect.
`gpu_texture_update_scaled` expects an input buffer clipped to
the bounds of the input area that needs to be updated. In case for Byte
textures with Non Color colorspace it received the unmodified input
buffer, resulting in incorrect data to be uploaded to the GPU texture.
This PR fixes this by selecting the non-optimized branch when the
texture is a Byte buffer with Data color space and scaling should
happen.
Pull Request: https://projects.blender.org/blender/blender/pulls/112834
