This improve the API in multiple aspects:
* No need for an additional `lookup` call to get the current attribute. This
would internally iterate over all attributes again. This leads to O(n^2)
behavior. Note that there are still other reasons for O(n^2) behavior when
processing attributes (where n is the number of attributes).
* Remove the need to return a value from the iteration code to indicate that the
iteration should continue. This is now the default behavior. The iteration can
still be stopped by calling `iter.stop()`.
* Easier access to `is_builtin` property.
* Iterator callback only has a single parameter instead of two (of which one is
sometimes unused).
Pull Request: https://projects.blender.org/blender/blender/pulls/128128
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, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
Previously, it was fairly easy to create built-in attributes which have invalid
values, because attributes were generally zero-initialized. This was especially
problematic for attributes that had certain invariants that Blender relies on
and that should never be zero. For example, the curve resolution should always
be at least 1.
To reproduce the issue, add the `resolution` attribute from the attributes panel
to curves. They had a value of 0 by default. I found this while investigating
#124416.
Pull Request: https://projects.blender.org/blender/blender/pulls/124534
This removes `BKE_attributes_supported`.
Instead, a static method `from_id`
is added to the `AttributeAccessor` class that constructs
the accessor from the given ID. If this fails, `std::nullopt`
is returned.
Pull Request: https://projects.blender.org/blender/blender/pulls/124245
Moving a constant variable results in a copy occurring instead. This
looks to have been an accidental change as part of ea937b304d.
A few tools will warn about this:
`Warning C26478 Don't use std::move on constant variables. (es.56)`
`Warning cpp:S5415 "std::move" should not be called on a const object.`
Pull Request: https://projects.blender.org/blender/blender/pulls/121063
This was necessary when attributes were stored embedded in legacy
structs like `MPoly`. Nowadays that isn't the case anymore, and there
doesn't seem to be a reason to restrict the creation of attributes.
update_on_change_ shouldn't be called when creating an attribute but
not setting the array values. In that case it is UB to not set the values
elsewhere anyway, and that will cause its own update tag.
All builtin attributes are now stored as named attributes, so the old
code path from where they were stored with non-generic types can be
removed. The stored type and attribute type don't have to be tracked
separately anymore either.
The change to use generic "capture field on geometry" utilities for this
node and other nodes like it means `AttributeWriter` with its update
tagging isn't being used anymore, the attribute is just being created
with the new values (for some cases anyway). To fix this, call the
attribute provider's update function when creating the attribute too.
This was noted as useful in 130701763b too.
The initialization of curve and point cloud runtime structs is moved
because they now have to be allocated before any attributes are added.
String attributes are not handled correctly (or at all) by geometry nodes
currently because their storage is very inefficient and will likely have to
change in the future anyway. Elsewhere processing string attributes was
explicitly disabled. That was missing in these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/118802
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
This means the array can be shared between geometries when unchanged,
reducing memory usage and increasing performance. It also means that
handling the data can be done more generically using the attribute
system. In the future the transforms can become attributes too.
Two other changes are related here:
- The "almost unique ids" are cached with a shared cache so they
are shared too.
- The reference indices are baked as an attribute now, making the process
more generic and potentially easier to optimize in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/117951
- "can not" -> "cannot" in many places (ambiguous, also see
Writing Style guide).
- "Bezier" -> "Bézier": proper spelling of the eponym.
- Tool keymaps: make "Uv" all caps.
- "FFMPEG" -> "FFmpeg" (official spelling)
- Use MULTIPLICATION SIGN U+00D7 instead of MULTIPLICATION X U+2715.
- "LClick" -> "LMB", "RClick" -> "RMB": this convention is used
everywhere else.
- "Save rendered the image..." -> "Save the rendered image...": typo.
- "Preserve Current retiming": title case for property.
- Bend status message: punctuation.
- "... class used to define the panel" -> "header": copy-paste error.
- "... class used to define the menu" -> "asset": copy-paste error.
- "Lights user to display objects..." -> "Lights used...": typo.
- "-setaudio require one argument" -> "requires": typo.
Some issues reported by Joan Pujolar and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/117856
Some common headers were including this. Separating the includes
will ideally lead to better conceptual separation between CustomData
and the attribute API too. Mostly the change is adding the file to
places where it was included indirectly before. But some code is
shuffled around to hopefully better places as well.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
Make the naming consistent with the recent change from "loop" to
"corner". Avoid the need for a special type for these triangles by
conveying the semantics in the naming instead.
- `looptris` -> `corner_tris`
- `lt` -> `tri` (or `corner_tri` when there is less context)
- `looptri_index` -> `tri_index` (or `corner_tri_index`)
- `lt->tri[0]` -> `tri[0]`
- `Span<MLoopTri>` -> `Span<int3>`
- `looptri_faces` -> `tri_faces` (or `corner_tri_faces`)
If we followed the naming pattern of "corner_verts" and "edge_verts"
exactly, we'd probably use "tri_corners" instead. But that sounds much
worse and less intuitive to me.
I've found that by using standard vector types for this sort of data,
the commonalities with other areas become much clearer, and code ends
up being naturally more data oriented. Besides that, the consistency
is nice, and we get to mostly remove use of `DNA_meshdata_types.h`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116238
Add a utility to set attribute values to their default, use it in a few
places that have already done this samething. Also:
- Don't create resolution or cyclic attributes unnecessarily
- Use API function to set new curve's type
- Always create the new selection on the curve domain
- Remove selection before resize to avoid unnecessary work
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Add a function that copies selected values to groups of values in the
result array. Add a runtime-typed version and a version for affecting
all attributes. Also make the "gather_group_to_group" follow the
same pattern.
We had a short discussion on this change. "Grease Pencil Layer" is
just a bit too long, especially in the UI. Even though "Layer" might be
ambiguous, it shouldn't be in the context of geometry nodes. There are
currently no other "Layers" and if there were, using the same domain
name could be fine (just like we reuse the point domain for e.g. vertices
in meshes and control points in curves).
This also renames the internal enum to `ATTR_DOMAIN_LAYER`
Pull Request: https://projects.blender.org/blender/blender/pulls/113589
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
Use the typical combination of an "array utils" function used by an
attribute interpolation function. This helps moves us towards having
a more centralized implementaiton of attribute propagation that can
be changed and optimized more easily.
When the final curve point indices are in the same order as the input
points, and there are many curves, avoid copying point domain
attributes, by generalizing the existing check from the mesh
to curve conversion node.
Pull Request: https://projects.blender.org/blender/blender/pulls/111662
New node to converts groups of points to curves. Groups
of points defined as `Curve Group ID` attribute. `Weight` in curve
is used for sort points in each group. Points of result curves
propagate attributes from original points. Implicit conversion
of other geometry types is not supported currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/109610
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Add a quaternion attribute type that will be used in combination with
rotation sockets for geometry nodes to give a more intuitive experience
and better performance when using rotations.
The most interesting part is probably the interpolation, the rest is
the same as the last attribute type addition, 988f23cec3.
We need to interpolate multiple values with different weights.
Based on Sybren's suggestion, this uses the `expmap` methods from
4805a54525 for that.
This also refactors `SimpleMixerWithAccumulationType` to use a
function rather than a cast to convert to the accumulation type.
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/108678
Replace the implementation of the separate and delete geometry nodes
for meshes. The new code makes more use of the `IndexMask` class, which
was recently optimized. The main goal is to make more of the work scale
with the size of the result mesh rather than the input. For example,
instead of keeping a map from input to output elements, the maps used
to copy attributes go from output to input elements.
The new implementation is generally 2-4x faster, depending on the mode
and the number of elements selected. The new code is also able to skip
more work when nothing is removed.
This also allows using more existing attribute interpolation code,
allowing the overall removal of over 300 lines. Some of the attribute
utilities from a similar change for curves (f63cfd8e28) are
reused directly.
The indices of the result changes, so the test file needs to be updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/108435
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
- Avoid using geometry sets from a different abstraction level
- Deduplicate basic attribute copying propagation code
- Allow more use of implicit sharing when data arrays are unchanged
- Optimize for when a point cloud delete selection is empty
- Handle face corners generically for "only face" case
Using the new index mask implementation, things can be a bit simpler.
It's also simpler to use `complement` instead of `to_ranges_invert`,
which just made everything less standard. Also create the new curve
offsets in place instead of copying, and use implicit sharing to share
attributes when no curves were deleted.
With a version of `IndexMask::complement()` optmized locally, I observed
the following speedups with a 1.2 million point curve system:
- Delete points: 29 FPS -> 45 FPS
- Delete curves: 48 FPS -> 49 FPS
- Delete tip points: 25 FPS -> 32 FPS
Also add a method to apply the "gather" function to all attributes,
mostly as a continued experiment of consolidating attribute propagation.
This can be used more elsewhere in the future.
