The type conversions do not depend on other files in the nodes
module. Furthermore we want to use the conversions in the
geometry module without creating a dependency to the
nodes module there.
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
Most of our field inputs are currently specific to geometry. This patch introduces
a new `GeometryFieldInput` that reduces the overhead of adding new geometry
field input.
Differential Revision: https://developer.blender.org/D13489
Now that we can store any dynamic attribute on the instances component,
we don't need the special case for `id`, it can just be handled by the
generic attribute storage. Mostly this just allows removing a bunch
of redundant code.
I had to add a null check for `update_custom_data_pointers` because
the instances component doesn't have any pointers to inside of
custom data.
Differential Revision: https://developer.blender.org/D13430
For some underlying data (e.g. spans) we had two virtual array
implementations. One for the mutable and one for the immutable
case. Now that most code does not deal with the virtual array
implementations directly anymore (since rBrBd4c868da9f97a),
we can get away with sharing one implementation for both cases.
This means that we have to do a `const_cast` in a few places, but
this is an implementation detail that does not leak into "user code"
(only when explicitly casting a `VArrayImpl` to a `VMutableArrayImpl`,
which should happen nowhere).
Adds an attribute provider for instance attributes.
A new domain `ATTR_DOMAIN_INSTANCE` is implemented.
Instance attributes are not yet realized correctly.
Differential Revision: D13149
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
Currently the curve to mesh node relies on the order of attributes being
the same on every spline. This is a worthwhile assumption, because it
will allow removing the attribute name storage duplication on every
spline in the future.
However, the join geometry node broke this order, since it just created
new attributes without any regard to the order. To fix this, I added a
"reorder" step after all the merged attributes have been created, the
types have been joined, etc. It should be possible to change this code
so that the attributes are added with the right order in the first
place, but I would like to do that after refactoring spline attribute
storage, and not for 3.0.
Differential Revision: https://developer.blender.org/D13074
This is a better and more general fix for T92511 and T92508 than
the ones that I committed before.
Previously, we tagged caches dirty when first accessing attributes.
This led to incorrect caches when under some circumstances. Now
cache invalidation is part of `OutputAttribute.save()`.
A nice side benefit of this change is that it may make things more
efficient in some cases, because we don't invalidate caches when
they don't have to be invalidated.
Differential Revision: https://developer.blender.org/D13009
In order to address feedback that the "Stable ID" was not easy enough
to use, remove the "Stable ID" output from the distribution node and
the input from the instance on points node. Instead, the nodes write
or read a builtin named attribute called `id`. In the future we may
add more attributes like `edge_id` and `face_id`.
The downside is that more behavior is invisible, which is les
expected now that most attributes are passed around with node links.
This behavior will have to be explained in the manual.
The random value node's "ID" input that had an implicit index input
is converted to a special implicit input that uses the `id` attribute
if possible, but otherwise defaults to the index. There is no way to
tell in the UI which it uses, except by knowing that rule and checking
in the spreadsheet for the id attribute.
Because it isn't always possible to create stable randomness, this
attribute does not always exist, and it will be possible to remove it
when we have the attribute remove node back, to improve performance.
Differential Revision: https://developer.blender.org/D12903
Move the static functions higher in the file so they are usabl
for an upcoming patch, and make it use clearer names instead
of overloading a function name.
Instead of switch statements, make use of generic virtual arrays
so the code is shorter and easier to read.
Differential Revision: https://developer.blender.org/D12908
This adds a toggle to node group inputs exposed in the modifier to use
an attribute instead of a single value. When the toggle is pressed, the
button switches to a text button to choose an attribute name. Attribute
search isn't implemented here yet.
One confusing thing is that some values can't be driven by attributes
at all, like the size of a primitive node. In that case, we should have
a node warning, but that will be separate since it's more general.
We can also have an option to turn off this toggle in node group
input settings.
The two new properties for each input are stored with the same name
as the value, but with `"_use_attribute"` and `"_attribute_name"``
suffixes. The properties are not added for socket types that don't
support attribute input, like object sockets.
Differential Revision: https://developer.blender.org/D12504
Store the optional temporary span storage as a unique_ptr and move
it in the move constructor, to avoid the need to add a special move
constructor that clears the "show_warning" fields from it. Maybe this
is very slightly slower, but we'll need this class less often in the future
anyway.
Previously, a debug name had to be passed to all methods
that added a resource to the `ResourceScope`. The idea was
that this would make it easier to find certain bugs. In reality
I never found this to be useful, and it was mostly annoying.
The thing is, something that is in a resource scope never leaks
(unless the resource scope is not destructed of course).
Removing the name parameter makes the structure easier to use.
Since fields were committed to master, socket inspection did
not work correctly for all socket types anymore. Now the same
functionality as before is back. Furthermore, fields that depend
on some input will now show the inputs in the socket inspection.
I added support for evaluating constant fields more immediately.
This has the benefit that the same constant field is not evaluated
more than once. It also helps with making the field independent
of the multi-functions that it uses. We might still want to change
the ownership handling for the multi-functions of nodes a bit,
but that can be done separately.
Differential Revision: https://developer.blender.org/D12444
This implements the initial core framework for fields and anonymous
attributes (also see T91274).
The new functionality is hidden behind the "Geometry Nodes Fields"
feature flag. When enabled in the user preferences, the following
new nodes become available: `Position`, `Index`, `Normal`,
`Set Position` and `Attribute Capture`.
Socket inspection has not been updated to work with fields yet.
Besides these changes at the user level, this patch contains the
ground work for:
* building and evaluating fields at run-time (`FN_fields.hh`) and
* creating and accessing anonymous attributes on geometry
(`BKE_anonymous_attribute.h`).
For evaluating fields we use a new so called multi-function procedure
(`FN_multi_function_procedure.hh`). It allows composing multi-functions
in arbitrary ways and supports efficient evaluation as is required by
fields. See `FN_multi_function_procedure.hh` for more details on how
this evaluation mechanism can be used.
A new `AttributeIDRef` has been added which allows handling named
and anonymous attributes in the same way in many places.
Hans and I worked on this patch together.
Differential Revision: https://developer.blender.org/D12414
* Reduce code duplication.
* Give methods more standardized names (e.g. `move_to_initialized` -> `move_assign`).
* Support wrapping arbitrary C++ types, even those that e.g. are not copyable.
Often it would be beneficial to avoid the virtual array implementation
in `geometry_component_curve.cc` that flattens an attribute for every
spline and instead read an attribute separately for every input spline.
This commit implements functions to do that.
The downside is some code duplication-- we now have two places handling
this conversion. However, we can head in this general direction for the
attribute API anyway and support accessing attributes in smaller
contiguous chunks where necessary.
No functional changes in this commit.
Differential Revision: https://developer.blender.org/D11456
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
Colors are often thought of as being 4 values that make up that can make any color.
But that is of course too limited. In C we didn’t spend time to annotate what we meant
when using colors.
Recently `BLI_color.hh` was made to facilitate color structures in CPP. CPP has possibilities to
enforce annotating structures during compilation and can adds conversions between them using
function overloading and explicit constructors.
The storage structs can hold 4 channels (r, g, b and a).
Usage:
Convert a theme byte color to a linearrgb premultiplied.
```
ColorTheme4b theme_color;
ColorSceneLinear4f<eAlpha::Premultiplied> linearrgb_color =
BLI_color_convert_to_scene_linear(theme_color).premultiply_alpha();
```
The API is structured to make most use of inlining. Most notable are space
conversions done via `BLI_color_convert_to*` functions.
- Conversions between spaces (theme <=> scene linear) should always be done by
invoking the `BLI_color_convert_to*` methods.
- Encoding colors (compressing to store colors inside a less precision storage)
should be done by invoking the `encode` and `decode` methods.
- Changing alpha association should be done by invoking `premultiply_alpha` or
`unpremultiply_alpha` methods.
# Encoding.
Color encoding is used to store colors with less precision as in using `uint8_t` in
stead of `float`. This encoding is supported for `eSpace::SceneLinear`.
To make this clear to the developer the `eSpace::SceneLinearByteEncoded`
space is added.
# Precision
Colors can be stored using `uint8_t` or `float` colors. The conversion
between the two precisions are available as methods. (`to_4b` and
`to_4f`).
# Alpha conversion
Alpha conversion is only supported in SceneLinear space.
Extending:
- This file can be extended with `ColorHex/Hsl/Hsv` for different representations
of rgb based colors. `ColorHsl4f<eSpace::SceneLinear, eAlpha::Premultiplied>`
- Add non RGB spaces/storages ColorXyz.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D10978
With this patch you will be able to add and remove attributes from curve
data inside of geometry nodes. The following is currently implemented:
* Adding attributes with any data type to splines or spline points.
* Support for working with multiple splines at the same time.
* Interaction with the three builtin point attributes.
* Resampling attributes in the resample node.
The following is not implemented in this patch:
* Joining attributes when joining splines with the join geometry node.
* Domain interpolation between spline and point domains.
* More efficient ways to call attribute operations once per spline.
Differential Revision: https://developer.blender.org/D11251
This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.
However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.
Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.
**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.
Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes
Differential Revision: https://developer.blender.org/D11091
Previously we always had to set attribute values after creating
the attribute. This patch adds an initializer argument to
`attribute_try_create` which can fill it in a few ways, which
are explained in code comments.
This fixes T87597.
Differential Revision: https://developer.blender.org/D11045
Because we use virtual classes (and for other reasons), we had to do a
small allocation when simply retrieving the data type and domain of an
existing attribute. This happened quite a lot actually-- to determine
these values for result attributes.
This patch adds a simple function to retrieve this meta data without
building the virtual array. This should lower the overhead of every
attribute node, though the difference probably won't be noticible
unless a tree has very many nodes.
Differential Revision: https://developer.blender.org/D11047
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
Previously only attributes of "real" geometry were displayed in
attribute search. This commit adds code to look through attributes
on instances and add those to the search drop-down too.
This required implementing the same sort of recursive traversal as
the realize instances code. The situation is a bit different though,
this can return early and doesn't need to keep track of transforms.
I added a limit so that it doesn't look through the attributes of
too many instanced geometry sets. I think this is important, since
this isn't a trivial operation and it could potentially happen for
every node in a large node tree. Currently the limit is set at 8
geometry sets, which I expect will be enough, since the set of
attributes is mostly not very unique anyway.
Fixes T86282
Diffrential Revision: https://developer.blender.org/D10919
Now that we have `ATTR_DOMAIN_AUTO`, it makes sense to use it to skip
automatic domain interpolation. This can make code that depends on the
non-interpolated domain of the attribute a bit simpler.
This patch renames two domains:
* `Polygon` -> `Face`
* `Corner` -> `Face Corner`
For the change from `polygon` to `face` I did a "deep rename" where I updated
all (most?) cases where we refere to the attribute domain in code as well.
The change from `corner` to `face corner` is only a ui change. I did not see
a real need to update all code the code for that. It does not seem to improve
the code, more on the contrary.
Ref T86818.
Differential Revision: https://developer.blender.org/D10803
