Some modifiers expect the curves to be of type `POLY`.
For such modifiers we need to resample the curves to the
evaluated points so that the modifiers work as expected.
Resolves#129859.
Pull Request: https://projects.blender.org/blender/blender/pulls/129860
Build modifier should start building strokes at a key frame, not always
assume a starting frame of 0.
Frame restriction works the same way as GPv2, which uses absolute
frame number.
Pull Request: https://projects.blender.org/blender/blender/pulls/129774
Even though this is generally avoided, drivers don't prevent
invalid values being set. Further files from branches or files
written in the future may contain enum values not yet known.
Resolve by range checking enum values which are used to index arrays.
Line art uses `DEG_OBJECT_ITER_BEGIN` to load all objects that has a
geometry in the scene, which is kind of a hack since the beginning. This
left potential problem where the iterator could go through some objects
that line art didn't have a dependency on (e.g. other grease pencil
objects):
- Since those "other" objects often evaluates fast enough, so
line art always end up having valid data from everywhere after lengthy
mesh evaluation prior to itself, so this problem was not prominent.
- However, in rare cases, there are other objects that takes a lot of
time to evaluate, this causes line art to potentially iterate to objects
that are still invalid.
This fix will build a `Vector<Object *>` during `update_depsgraph`, and
use such list inside `DEGObjectIterSettings` to filter out objects that
the modifier isn't dependent on, thus remove the possibility of reading
objects that hasn't been evaluated.
Since Line art will not add grease pencil objects as potential geometry
inputs, all mesh/curve types of geometries generated by geometry nodes
modifier directly inside other grease pencil objects won't be loaded.
This can be mitigated by having a third mesh object that reads the
result from the grease pencil object that generates geometries, then
directly output them for line art to read.
This also fixes#128888.
Pull Request: https://projects.blender.org/blender/blender/pulls/128890
The build modifier crashes when getting lengths of cyclic curves because `evaluated_points_by_curve`
was previously always called with `cyclic` parameter set to `false`.
The `cyclic` parameter necessary for `curves::segments_num` to return correct number of segments.
Pull Request: https://projects.blender.org/blender/blender/pulls/128955
These attributes are not guaranteed to exist. So they should either be used
conditionally, or with a fallback value. The fallback value for the opacity is
obvious, but for the radius it's more tricky. There is not a consistent fallback
value across Blender unfortunately. The one I used here is used in a couple of
places.
Pull Request: https://projects.blender.org/blender/blender/pulls/128847
The layer/material/vertex group filter properties had already been added but they were
not exposed in the UI. Also the influence panel was missing. Now added in "rna_" function
of the modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/128973
Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
This adds an option `all_keyframes` to the `object.modifier_apply` operator.
With the option enabled, the operator will iterate through all the keyframes,
then apply the modifier and merge the result back into the original
object. This is only done for Grease Pencil objects.
This is how the default `Apply` operation worked in GPv2. This adds the
functionality back but also keeps the current `Apply` behavior for consistency
with other object types.
The UI is also changed to show both options in the dropdown menu.
Again, this is only shown for Grease Pencil objects.
With Geometry Nodes it's possible to add new layers to the geometry.
When applying, this will create a single keyframe on the first frame of
evaluation. Layers with duplicated names in evaluated geometry will
be deduplicated. It's also possible to have layers with empty names.
When applying these get renamed to `Layer` (and `Layer.001` etc.
when such a layer already exists in the original geometry).
Pull Request: https://projects.blender.org/blender/blender/pulls/128487
Caused by ba28469e45.
The `total_size()` function excludes the start offset now, which meant
that the `dst_curve_num` and `dst_point_num` were off.
The fix makes sure to include the src curves and points totals in the
destination if `keep_original` is true.
Pull Request: https://projects.blender.org/blender/blender/pulls/128523
This does the following changes:
* Show info "warnings" in modifier too. Previously those were skipped. The
different behavior of info/warning/error messages causes confusion.
* Add a new `Warnings` panel that only shows when there are warnings. In its
title, it shows how many warnings there are.
* In the panel, warnings are sorted by severity and alphabetically.
Pull Request: https://projects.blender.org/blender/blender/pulls/128395
Fixes incorrect usage of StringRef in new grease pencil code, where
`.data()` was passed as a null terminated C string. Removes the now
unnecessary `std::string` creation that attribute accessors used to
fix that problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/128298
Layer selectors in Line Art and all modifier's Influence panel was
using the Grease Pencil icon, instead of the Grease Pencil Layer icon.
At the moment they are similar so it's easy to miss. But soon there
will be a new icon for layers so better use the right one.
The Line Art modifier was using Grease Pencil icon for materials
selector.
This adds a new type of zone to Geometry Nodes that allows executing some nodes
for each element in a geometry.
## Features
* The `Selection` input allows iterating over a subset of elements on the set
domain.
* Fields passed into the input node are available as single values inside of the
zone.
* The input geometry can be split up into separate (completely independent)
geometries for each element (on all domains except face corner).
* New attributes can be created on the input geometry by outputting a single
value from each iteration.
* New geometries can be generated in each iteration.
* All of these geometries are joined to form the final output.
* Attributes from the input geometry are propagated to the output
geometries.
## Evaluation
The evaluation strategy is similar to the one used for repeat zones. Namely, it
dynamically builds a `lazy_function::Graph` once it knows how many iterations
are necessary. It contains a separate node for each iteration. The inputs for
each iteration are hardcoded into the graph. The outputs of each iteration a
passed to a separate lazy-function that reduces all the values down to the final
outputs. This final output can have a huge number of inputs and that is not
ideal for multi-threading yet, but that can still be improved in the future.
## Performance
There is a non-neglilible amount of overhead for each iteration. The overhead is
way larger than the per-element overhead when just doing field evaluation.
Therefore, normal field evaluation should be preferred when possible. That can
partially still be optimized if there is only some number crunching going on in
the zone but that optimization is not implemented yet.
However, processing many small geometries (e.g. each hair of a character
separately) will likely **always be slower** than working on fewer larger
geoemtries. The additional flexibility you get by processing each element
separately comes at the cost that Blender can't optimize the operation as well.
For node groups that need to handle lots of geometry elements, we recommend
trying to design the node setup so that iteration over tiny sub-geometries is
not required.
An opposite point is true as well though. It can be faster to process more
medium sized geometries in parallel than fewer very large geometries because of
more multi-threading opportunities. The exact threshold between tiny, medium and
large geometries depends on a lot of factors though.
Overall, this initial version of the new zone does not implement all
optimization opportunities yet, but the points mentioned above will still hold
true later.
Pull Request: https://projects.blender.org/blender/blender/pulls/127331
We already have the `description` property on panels but are currently not
displaying it when hovering over a panel header. With this patch, the
descriptions will be shown in group nodes as well as the geometry nodes
modifier.
I had to do two lower level changes for layout panels because it didn't work
with tooltips properly.
* Tooltips make the label in the panel header interactive, but clicking to
open/close the panel should still work.
* The tooltip should disappear when clicking on the header. This is consistent
with tooltips in other places.
Pull Request: https://projects.blender.org/blender/blender/pulls/127852
Previously, it was only possible to bake to disk with geometry nodes. This patch
adds support for storing the baked data directly in the .blend file.
By default, new bakes are stored in the .blend file now. Whether a new bake
should be packed or stored on disk can be configured in two places: in the
properties of the bake node and in the bake panel of the modifier. These
settings don't affect existing bakes, only the next bake.
To unpack or pack an individual bake, there is a new operator button next to the
bake button. The icon and the label below indicate where the bake is currently
stored. The label now also contains the size of the bake.
To unpack or pack all bakes, the `File > External Data > Pack Resources / Unpack
Resources` operators can be used. The unpack operator also has a new title that
mentions the number if individual files separate from the number of bakes. This
works better than just listing a number of files because a bake can consist of
many files.
Pull Request: https://projects.blender.org/blender/blender/pulls/124230
The build modifier did not walk the ID link of the object in the settings.
This meant that the pointer was just pointing to random memory after
loading a file that had this object set.
The fix makes sure this ID link is handled in `foreach_ID_link`.
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
