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
After 97f2b01ea9, the iterator's mask data is just read only,
so there's no point in storing it as a pointer. This simplifies the code
using the mask data, since the default only needs to be handled once.
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).
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).
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.
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
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
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
In preparation of https://projects.blender.org/blender/blender/pulls/112535, we need to make sure all layer tree manipulations are in functions on the `GreasePencil` struct so we can keep the `CustomData` for layers in sync with the layer tree.
This PR makes sure that all the functions that change the layer tree in any way are `protected` on the `LayerGroup` class. The `GreasePencil` struct is declared `friend` with `LayerGroup`.
We also cleanup and remove a lot of code duplication between layers and layer groups and try to write functions in a generic way for `TreeNode` (both layers and layer groups are tree nodes).
Pull Request: https://projects.blender.org/blender/blender/pulls/112837
- Use `StringRef` over `StringRefNull`, since it handles `nullptr` in
its constructor and gives more flexibility about the string's source.
- Change `const char *` to `StringRef` as well, for improved ergonomics
and efficiency.
- Move `add_interface_socket_from_node` to a .cc file. It's not small
or performance sensitive enough to be inlined.
- Avoid allocating empty strings for item descriptions.
- Allocate with `BLI_strdupn` to avoid unnecessary `strlen` calls.
- Move a bit more code into a proper namespace.
Pull Request: https://projects.blender.org/blender/blender/pulls/112721
See #103343.
We had attempted to move the file to C++ twice before but found failing
tests each time. To find the code with changed behavior between C and
C++, I temporarily added a header declaring all the functions and moved
them one by one. The problem ended up being one function's use of `exp`
which used floats instead of doubles in C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/112693
Instead of adding the default "Bones" bone collection to every Armature
data-block, only add it for Armatures that are added in the 3D View with
Shift+A > Armature.
This simplifies things like importers, which otherwise would have needed
to remove that default collection before creating the imported ones.
Additionally, this also ensures that the one bone you get by default is
actually assigned to the default bone collection.
Blender 4.0 requires OpenGL 4.3 which always support SSBO's.
Platforms that don't support enough SSBO bind points will be marked
as unsupported.
Users who start Blender on those platforms will be informed via a
dialog. This PR also updates the `--debug-gpu-force-workarounds`
to match our minimum requirements. Note that some bugs are still
there that should be solved in other PRs:
* Workbench only renders the object using a unit matrix this is because
there is a bug in the workaround for shader_draw_parameters
* Navigating with middle mouse button is not working. Unsure what the
cause is, but might be a missing feature check in the OpenGL backend.
Related to #112224
Pull Request: https://projects.blender.org/blender/blender/pulls/112572
Use magenta fallback color for sockets without a `draw_color_simple`
callback. This is not ideal, but without a context or node instance
the older `draw_color` callback can't be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/112658
The goal is to reduce redundancy by abstracting over the different types of node
tree zones. This makes it easier to add new zone types and makes the intend of
code more clear. For example, now it is more obvious what code deals with zones
in general and what does simulation specific things.
Pull Request: https://projects.blender.org/blender/blender/pulls/112531
It was possible to access a mutable drawing from a const GreasePencil
object. This sort of mistake is possible because DNA requires using raw
pointers.
This is a compatibility breaking change to rename all usages of the name
`asset_library_ref` with `asset_library_reference`. Brecht recently
suggested that such abbreviations should be avoided in public API names.
f6a6b27ac1 made the asset representation type available through context
wherever asset handle was previously. This moves us closer to replacing
the asset handle type.
Part of #102877 and #108806.
Makes the asset representation type available in RNA/BPY context
whenever the asset handle type is, so that it can be used instead. See
d04cd3f3e6. With this change we can now replace virtually all usages of
the asset handle type in Python with the asset representation. (Only for
the asset view template we require a collection property taking asset
handles still, for internal reasons.)
Idea is now to first get rid of all usages of asset handle in Python,
so that there's almost no need for further compatibility breaking
changes (unsure if the asset view template can be removed for 4.0
already though). Internal hacks related to it can be removed at any time
still.
Part of #102877 and #108806.
