I've done this a few times and would have benefited from a utility
function for it, apparently it's done in a few more places too. The
utilities aren't multithreaded for now, it doesn't seem important
and often multithreading happens at a different level of the call
stack anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/127517
Grease Pencil armature deformation has to use the correct
`vertex_group_names` list from the `Curves` (i.e. drawings) rather than
the names from its parent `GreasePencil` data block.
The ancient armature deformation code used a `defbase` list (`ListBase`
of type `bDeformGroup`) from the object via `BKE_id_defgroup_list_get`.
This function does not have enough information to determine the correct
vertex groups for GPv3, and it's use inside supposedly generic code is
highly questionable.
This patch removes the `defbase` lookup inside
`armature_deform_coords_impl` and instead passes an explicit list of
vertex group names to be used for resolving indices. We already have
context in every place this is called to determine the correct vertex
groups, without having to make assumptions down the line based on just
the object type.
Pull Request: https://projects.blender.org/blender/blender/pulls/127509
As of 2a56403cb0, bevel weight data is stored as a generic
attribute. The bevel modifier is currently hard-coded to use the
`bevel_weight_edge` attribute as the data source for the weights.
This commit adds a string textbox where the user can specify alternate
attributes for the bevel's edge weights.
The string name field is added as a search button which provides a list
of all attributes in the original mesh. This is meant to work similarly
to geometry nodes, so mismatched attribute data types and domains are
automatically converted/interpolated as necessary. Attributes created
by previous modifiers can also be used, but they won't appear in the
search menu.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/117366
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Previously, all errors, warnings and info messages were propagated from the node
that generates it to the top level node group. This is a good default, but may
not always be desirable. For example, someone may build a node group asset that
generates some warning that is irrelevant to the user to the asset. Now, the
asset author can selectively disable propagating warnings from that node.
Each node has a new `Warning Propagation` setting. It controls if warnings from
this node should be propagated to the parent group node. By default, everything
is propagated. One can also choose to propagate nothing, only errors or only
errors and warnings.
Note, this does not affect whether the warning is shown in the node itself, only
if the warning is propagated one level up!
Pull Request: https://projects.blender.org/blender/blender/pulls/126786
Investigation into #126306 showed that the texture tab shown would actually be
for the active image paint brush, but people used it to set up a texture for
the fluid modifier settings anyway. Now properly register the texture user for
the UI, so the texture properties tab will always be displayed when there is a
fluid modifier with a "Flow" fluid type.
Main issue is that fluid modifiers weren't handled by the
`BKE_modifiers_foreach_tex_link()` iterator.
While this could be handled as another special case in
`buttons_texture_modifier_foreach()`, I updated the texture-link iterators to
support texture properties that are not directly stored in the modifier, but in
some nested data. Seems like this should be supported generally. It's enabled
here by passing a pointer-property pair, rather than just a property name.
Pull Request: https://projects.blender.org/blender/blender/pulls/126893
Part of #118145.
Remove some uses of the `SculptSession` array in favor of retrieving
positions as necessary. Because of implicit sharing, avoiding unnecessary
mutable references to data can avoid copies and increased memory usage.
There are still more places to change before sculpt mode recieves that
benefit though.
In 4.2, Alembic points are imported as PointCloud objects instead of as
mesh vertices.
The code inside Mesh Sequence Cache which converts geometry into a
bounding-box mesh when using Render Procedurals needed to be updated
to support PointCloud objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/125846
The crash was caused by attempting to write-back to the original data after it
has been removed (`add_data_block_items_writeback`).
This write-back is already disabled when applying a modifier, however the
corresponding flag was only set when applying modifiers on mesh objects. This
patch fixes this issue with two small changes:
* Rename `MOD_APPLY_TO_BASE_MESH` to `MOD_APPLY_TO_ORIGINAL` to make it more
generic.
* Pass this flag into modifier evaluation for other geometry types besides
meshes in `modifier_apply_obdata`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125761
This removes the legacy Grease Pencil modifiers from the code.
These should have already been inaccessible from the UI and hidden from
the user. The modifiers have been reimplemented for the new GPv3
data structure.
On top of the modifier code, some other related things have been
removed as well:
* Operators related to the legacy modifiers.
* Keymaps for the legacy modifier operators.
* Some bits of code that used modifier functions.
Some code has to be kept, because it is still used:
* The core line art code, which is used by the new line art modifier. It's
moved to `modifiers/lineart`.
* The DNA structs for the legacy modifiers. They are still needed for
conversion.
* A few kernel functions for the modifiers are kept (also for conversion).
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/125102
This reverts commit f3c32a36bc and the two followups.
The commit caused issues with both the operator and the modifier.
The operator could be fixed, for the modifier this needs deeper
investigation (see #124836 for a bit more info on this).
Until a better solution is found it is just better to go back to
previous behavior.
Reintroduces #103562 for now
Pull Request: https://projects.blender.org/blender/blender/pulls/125499
This patch implements all baking operators for LineArt for GPv3.
The old baking operators are renamed with `_legacy_` to
distinguishing both when calling the operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/125079
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
The fix contains two parts:
1. Grease Pencil v3 now stores stroke `init_time` as a float attribute,
it's not enough precisiton for unix timestamp. Now the time value is
truncated to allow better precision. It's still stored in seconds.
2. The previous logic for calculating stroke gap time of the build
modifier isn't correct, it used to only count two starting times as
gap time. Now it's fixed with correct delta time.
Pull Request: https://projects.blender.org/blender/blender/pulls/124350
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
The ocean modifier uses its Bake operator for both baking and freeing
the cache, based on the `free` operator property.
There are two bugs here:
1. The "Delete Bake" variant of the button was created using the
`WM_OP_EXEC_DEFAULT` operator context. This skips the `invoke`
callback which is crucial for setting the operator `modifier`
property. Without that the modifier will just exit early.
The "Bake" button is drawn using the `uiItemO` function which uses
the invoke context automatically, so it does not have this issue.
2. The `free` property is set for the "Delete Bake" variant, but was
never reset to its initial `false` value. The "Bake" variant has to
also set this property, otherwise it will always execute the "free"
code path.
Pull Request: https://projects.blender.org/blender/blender/pulls/123506
The time offset modifier inserts keys sequentially, overwriting earlier
frames with later ones, and only the last relevant frame remains used.
In chain mode this process is repeated for every chain segment and then
all segments are repeated to fill the entire timeline. However, because
all keyframes are inserted for every repetition, they can overwrite
keyframes from earlier repetitions as well.
Clamping the insert keyframe makes sure that no keys are inserted
outside of the target range for a give repetition.
Pull Request: https://projects.blender.org/blender/blender/pulls/123423
Extract
- Cycles denoiser enum.
- Extensions user preferences UI.
- Node operator poll message from new node function.
Improve
- Split "(Enabled|Disabled) on startup, overriding the preference."
into two messages.
Disambiguate
- "Add" when describing the action of adding something should use the
Operator context.
- "Dimensions", in noise textures.
- "Transform" as a noun, the matrix transform type of Geometry Nodes,
as opposed to the verb to move things in space.
- "Parent" as a noun or verb (the parent of an object, to parent an
object to another).
Some issues reported by Satoshi Yamasaki, deathblood, and Gabriel Gazzán.
Pull Request: https://projects.blender.org/blender/blender/pulls/122969
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
The goal is to simplify debugging the "current" simulation step. Previously, when a frame
was cached already, one would have to go back to the beginning to cache everything again.
Now, the last cached simulation step is discarded and simulated again if any property that
affects it is changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122736
During the conversion of GPv3 to GPv2, we computed the
time difference between the points. So we we're keeping track
of the time a point was created relative to the previous point.
There doesn't seem to be a good reason to do this.
It can also go very wrong in case the times of two points are
very close to one another (which can result in catastrophic
cancellation).
With this change, the time delta values are now the time
a point was created, relative to the first point.
Pull Request: https://projects.blender.org/blender/blender/pulls/122367
Unlike to `lookup_or_default` accessor methods of `Map` or attribute provider class,
`Span::get` is not so explicit and self described to be used with default value.
Other one issue was is that result is by value. But this is not the main reason to
delete this method. And although this can be fixed by reference, this is still not
such good to just have method to check index and return something.
Pull Request: https://projects.blender.org/blender/blender/pulls/122425
The "Maximum Gap" setting for the "Natural Drawing Speed"
mode was not working.
This was because the code used `math::max` to try and clamp the value
to a maximum when it should have used `math::min`.
This fixes this issue.
`BM_mesh_triangulate` is used in exporters (when the "Triangulate"
option is ON), the `Triangulate` modifier and currently also in the
`Triangulate` geometry node (even though there are plans to change this,
see !112264)
So in practice, exporters (Alembic/FBX/OBJ/Collada) were breaking
custom normals for game pipelines (unless everything was triangulated
beforehand).
This change builds upon 93c8955a72 (uses the use
`BM_custom_loop_normals_to_vector_layer` /
`BM_custom_loop_normals_from_vector_layer` pair of calls).
In the case of the `Triangulate` modifier, this had its own try at
preserving custom normals in 7d0fcaa69a -- doing very similar
things but as an option -- this is now removed (so it is always done,
which fits into "interpolate custom data if it's there" design that we have
nowadays).
NOTE: the "Triangulate Faces" operator already did the same
Pull Request: https://projects.blender.org/blender/blender/pulls/121871
