Creating a new window then a new scene would crash on undo
because the undo step loaded would not contain the new windows scene.
Regression introduced since 3.6.
When retrieving a color attribute to paint it, the layer data needs to
be unshared so that it doesn't modify data from separate meshes.
In the past I think we've unknowingly avoided this problem by porting
code to the new attribute API. I've been refactoring `PBVH` and
`SculptSession` to make that possible (removing the long-lived
layer pointers in the two structs). But that wouldn't fit as a bug fix.
In the meantime, make sure the color attribute data is un-shared
and separate "for read" and "for write" versions of the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114119
A curve with only two points shouldn't be considered cyclic. Otherwise
a duplicate edge is added between the points. This fixes the utility
that calculates the segment count to account for this and adjusts
other code to account for that as necessary. Curves now evaluate
correctly to a single evaluated segment in this case (in the case of
Bezier and NURBS curves, it depends on the resolution though).
Co-authored-by: Dalai Felinto <dalai@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114095
The PBVH is given the evaluated positions from the end of the modifier
stack, but then updates normals from the original mesh based on those
positions. This causes a feedback loop, even when in vertex paint mode.
As mentioned in a comment, calculating these normals and duplicating
the arrays is quite wasteful. But it's necessary since the PBVH always
assumes we are interested in modifying the positions, and also always
retrieves the normals from the original mesh too. Those things would
be good to untangle at some point too, but for now this change is small
and helps to clarify the situation as well.
Caused by: b339e3937d
Pull Request: https://projects.blender.org/blender/blender/pulls/114118
The issue was that a node was supposed to propagate an anonymous
attribute that is only created further to the right in the tree. This does not
during inferencing, where uses of fields can only come to the right of its
creation. Note, all fields coming out of the repeat input/output node are
new field sources during inferencing.
Now, only field sources that are passed from the outside into the repeat zone
can be propagated from the repeat output to the repeat input node.
Solving this also showed another issue where anonymous attributes are
not properly propagated through a repeat zone where there is no link between
the repeat input and output node. In such cases, data is still propagated between
those two nodes when the number of iterations is zero.
Translation markers `N_()` were added to IDs' plural names in !113912.
I also renamed some of those because I thought there were only display
names.
This commit reverts the renaming, leaving only the addition of the
markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/114030
The repeat zone needs some special treatment during anonymous attribute
inferencing, because it propagates those attributes directly from the repeat
input to the repeat output node and vice versa.
Now the algorithm uses multiple passes if necessary to reach a stable
inferencing result.
Pull Request: https://projects.blender.org/blender/blender/pulls/113970
Caused by 425b871607.
The root issue was that these two states of the hash table were
mixed up in 425b871607: (1) the hash table exists and (2) the hash
table is empty.
The use of `std::optional` restores these two different states again.
Extract:
- Sculpt filter types from the Sculpt menu. Some of these types use a
custom label, different from those defined in the operator RNA,
which was never extracted.
- "Today" and "Yesterday" from the file browser modification date.
- All name_plural from IDs, as these are used in the UI to list which
data block is to be removed, when calling outliner.orphans_purge.
Disambiguate:
- "Area", meaning the measurement of a surface as opposed to a place.
Some messages reported by Satoshi Yamasaki in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/113912
In 3.6 the names of node group sockets were using char arrays, but now
use allocated strings. The RNA system assigns nullptr to such strings
when assigning an empty string through python (UI assignment appears to
always generate a valid string). This creates issues with many STL
functions, in particular assigning nullptr to `std::string` will crash.
We have to check for valid pointers before using them in places that
don't handle nullptrs.
Pull Request: https://projects.blender.org/blender/blender/pulls/113924
Previously the first group of deform modifiers didn't need to access
original coordinates explicitly because the deformation wasn't included
in the mesh positions. After d20f992322 the mesh is deformed
directly though, so the original coordinates need to be added first.
In the case of this report, the particle system (which is a "deform"
modifier for reasons) didn't have original coordinates to work with, so
it created the child particles at the deformed positions from the shape
keys every time. Though for some reason it only did that for renders.
Pull Request: https://projects.blender.org/blender/blender/pulls/113679
See #105317
In 46cf093270, face maps were just converted to an integer
attribute. While the internal data remains the same that way, we lose
the names and some convenient methods of interaction. This commit
additionally converts each face map to a separate boolean attribute
using the old name. This does require that no attributes were using that
name already.
Each boolean attribute can be thought of as a selection, accessible in
geometry nodes and properly interpolated by mesh processing
algorithms. The selections no longer have to be unique, meaning
one face can be part of multiple selections.
Pull Request: https://projects.blender.org/blender/blender/pulls/113769
Before bd00324c26, strip lengths were changed in
`rna_NlaStrip_frame_start_ui_set` and `rna_NlaStrip_frame_end_ui_set`
so as not to be shorter than NLASTRIP_MIN_LEN_THRESH.
This prevented `BKE_nlameta_flush_transforms` from working with
zero-length strips.
But now, in some cases, strip can be zero length.
Therefore, consider this case and avoid division by zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/110121
In !112591, nodes got the ability to group sockets into panels. The
labels for these sockets are automatically shortened if they begin
with the same text as their parent labels. For instance, "Transmission
Weight" will be shortened to just "Weight" because it is under the
"Transmission" panel.
While this is a good heuristic for English, it breaks down in
languages which do not have the same word order.
This commit adds a `.short_label()` callback to socket declarations so
that a shortened label can be explicitly declared.
It also adds two regexps to the translation script so that these new
fields can be extracted to the .po translation files. One extracts the
label with a translation context, the other without. Only the one
without context is currently in use.
The current automatic shortening logic is kept and will be used only
if a shortened label is not manually provided.
Fixes#112970: Node socket labels under panels are not shortened when
translated.
Pull Request: https://projects.blender.org/blender/blender/pulls/113070
The issue was that custom data layers were modified without checking
that the data was not shared. Now the data is unshared first.
I also added an assert to catches this kind of issue more directly.
Making some liboverride local will break/corrupt liboverride hierarchies
in many cases. So that function (or its caller, in some cases) need to
call #BKE_lib_override_library_main_hierarchy_root_ensure to re-validate
(and re-generate if needed) the liboverride hierarchy roots.
The code ensuring a valid liboverride hierarchy root ID pointer for all
liboverrides in a given Main would fail in some cases, and crash on
asserts (in Debug builds) or due to corrupted data later in code
(release builds).
The main issue fixed here is re-entry in case of dependency loops (a
same ID being checked more than once within the same chain of recursive
calls to ensure its hierarchy root is valid). Solved the usual way now,
using the intermediate 'PROCESSING' flag instead of setting immediately
the 'PROCESSED' one, when recursively processing the chain of
dependencies.
A second issue fixed in that code was that in some cases, it could leave
the invalid existing hierarchy root pointer unchanged, because it could
not find a 'valid enough' alternative.
NOTE: This data corruption is presumably caused by 'make local'
operations on liboverride hierarchy root IDs. This will be addressed as
a second commit.
For reference, issue is reproducible when opening
`/promo/splash/040_0010.lighting.splash.blend` from Pets SVN repo r3106.
Accessing the file size returns -1 on error, for file packing this
was passed directly to an allocation which would wrap around to
SIZE_T_MAX and fail to allocate. In other cases zero was treated
as an error value but -1 wasn't.
Add checks for the error return value, also warn that packing files over
2gb isn't supported.
A copy has to compare equal to itself and have the same hash
when it is supposed to be used as a reference in a hash table
like `VectorSet`.
Just making the hash not change during a copy by hashing the
geometry component pointers instead of the geometry-set pointer
does not work because of `geometry_set_from_reference` which
assumed that changing the geometry set does not change the
hash of the reference.
For now the solution is to just not use a hash table as this
makes it easier to get corretness right. Instead, just use a
regular `Vector` to store all the references which avoids
the need for a hash function.
This can now lead to some O(n^2) behavior when adding many
references. Fortunately, this is not too common yet, as usually
one has few references but many instances that use those.
It's still something that has to be solved at some point. It's
not clear yet what approach would work best:
* Reintroduce `VectorSet` for the references and properly update
the reference positions in the hash table after the references
have changed.
* Add a separate `Map<Object*/Collection*, int>` for the
deduplication.
* Do deduplication on the call-site of `add_reference` by building
a temporary map there.
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
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).
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
