2021-03-08 11:41:23 -05:00
|
|
|
/*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "BLI_map.hh"
|
|
|
|
|
#include "BLI_span.hh"
|
|
|
|
|
#include "BLI_string_ref.hh"
|
|
|
|
|
#include "BLI_vector.hh"
|
2021-03-17 11:50:13 +01:00
|
|
|
#include "BLI_vector_set.hh"
|
|
|
|
|
|
|
|
|
|
#include "BKE_geometry_set.hh"
|
2021-03-08 11:41:23 -05:00
|
|
|
|
|
|
|
|
namespace blender::bke {
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
using fn::GVArrayPtr;
|
|
|
|
|
using fn::GVMutableArrayPtr;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Utility to group together multiple functions that are used to access custom data on geometry
|
|
|
|
|
* components in a generic way.
|
|
|
|
|
*/
|
|
|
|
|
struct CustomDataAccessInfo {
|
|
|
|
|
using CustomDataGetter = CustomData *(*)(GeometryComponent &component);
|
|
|
|
|
using ConstCustomDataGetter = const CustomData *(*)(const GeometryComponent &component);
|
|
|
|
|
using UpdateCustomDataPointers = void (*)(GeometryComponent &component);
|
|
|
|
|
|
|
|
|
|
CustomDataGetter get_custom_data;
|
|
|
|
|
ConstCustomDataGetter get_const_custom_data;
|
|
|
|
|
UpdateCustomDataPointers update_custom_data_pointers;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A #BuiltinAttributeProvider is responsible for exactly one attribute on a geometry component.
|
|
|
|
|
* The attribute is identified by its name and has a fixed domain and type. Builtin attributes do
|
|
|
|
|
* not follow the same loose rules as other attributes, because they are mapped to internal
|
|
|
|
|
* "legacy" data structures. For example, some builtin attributes cannot be deleted. */
|
|
|
|
|
class BuiltinAttributeProvider {
|
|
|
|
|
public:
|
|
|
|
|
/* Some utility enums to avoid hard to read booleans in function calls. */
|
|
|
|
|
enum CreatableEnum {
|
|
|
|
|
Creatable,
|
|
|
|
|
NonCreatable,
|
|
|
|
|
};
|
|
|
|
|
enum WritableEnum {
|
|
|
|
|
Writable,
|
|
|
|
|
Readonly,
|
|
|
|
|
};
|
|
|
|
|
enum DeletableEnum {
|
|
|
|
|
Deletable,
|
|
|
|
|
NonDeletable,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
const std::string name_;
|
|
|
|
|
const AttributeDomain domain_;
|
|
|
|
|
const CustomDataType data_type_;
|
|
|
|
|
const CreatableEnum createable_;
|
|
|
|
|
const WritableEnum writable_;
|
|
|
|
|
const DeletableEnum deletable_;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
BuiltinAttributeProvider(std::string name,
|
|
|
|
|
const AttributeDomain domain,
|
|
|
|
|
const CustomDataType data_type,
|
|
|
|
|
const CreatableEnum createable,
|
|
|
|
|
const WritableEnum writable,
|
|
|
|
|
const DeletableEnum deletable)
|
|
|
|
|
: name_(std::move(name)),
|
|
|
|
|
domain_(domain),
|
|
|
|
|
data_type_(data_type),
|
|
|
|
|
createable_(createable),
|
|
|
|
|
writable_(writable),
|
|
|
|
|
deletable_(deletable)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
virtual GVArrayPtr try_get_for_read(const GeometryComponent &component) const = 0;
|
|
|
|
|
virtual GVMutableArrayPtr try_get_for_write(GeometryComponent &component) const = 0;
|
2021-03-08 11:41:23 -05:00
|
|
|
virtual bool try_delete(GeometryComponent &component) const = 0;
|
2021-04-22 09:20:03 -05:00
|
|
|
virtual bool try_create(GeometryComponent &UNUSED(component),
|
|
|
|
|
const AttributeInit &UNUSED(initializer)) const = 0;
|
2021-03-08 11:41:23 -05:00
|
|
|
virtual bool exists(const GeometryComponent &component) const = 0;
|
|
|
|
|
|
2021-03-17 11:51:51 +01:00
|
|
|
StringRefNull name() const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
return name_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
AttributeDomain domain() const
|
|
|
|
|
{
|
|
|
|
|
return domain_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
CustomDataType data_type() const
|
|
|
|
|
{
|
|
|
|
|
return data_type_;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* A #DynamicAttributesProvider manages a set of named attributes on a geometry component. Each
|
|
|
|
|
* attribute has a name, domain and type.
|
|
|
|
|
*/
|
|
|
|
|
class DynamicAttributesProvider {
|
|
|
|
|
public:
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
virtual ReadAttributeLookup try_get_for_read(const GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const = 0;
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
virtual WriteAttributeLookup try_get_for_write(GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const = 0;
|
|
|
|
|
virtual bool try_delete(GeometryComponent &component,
|
|
|
|
|
const AttributeIDRef &attribute_id) const = 0;
|
2021-03-08 11:41:23 -05:00
|
|
|
virtual bool try_create(GeometryComponent &UNUSED(component),
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &UNUSED(attribute_id),
|
2021-03-08 11:41:23 -05:00
|
|
|
const AttributeDomain UNUSED(domain),
|
2021-04-22 09:20:03 -05:00
|
|
|
const CustomDataType UNUSED(data_type),
|
|
|
|
|
const AttributeInit &UNUSED(initializer)) const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
/* Some providers should not create new attributes. */
|
|
|
|
|
return false;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
virtual bool foreach_attribute(const GeometryComponent &component,
|
|
|
|
|
const AttributeForeachCallback callback) const = 0;
|
2021-03-17 11:50:13 +01:00
|
|
|
virtual void foreach_domain(const FunctionRef<void(AttributeDomain)> callback) const = 0;
|
2021-03-08 11:41:23 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This is the attribute provider for most user generated attributes.
|
|
|
|
|
*/
|
|
|
|
|
class CustomDataAttributeProvider final : public DynamicAttributesProvider {
|
|
|
|
|
private:
|
|
|
|
|
static constexpr uint64_t supported_types_mask = CD_MASK_PROP_FLOAT | CD_MASK_PROP_FLOAT2 |
|
|
|
|
|
CD_MASK_PROP_FLOAT3 | CD_MASK_PROP_INT32 |
|
|
|
|
|
CD_MASK_PROP_COLOR | CD_MASK_PROP_BOOL;
|
|
|
|
|
const AttributeDomain domain_;
|
|
|
|
|
const CustomDataAccessInfo custom_data_access_;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
CustomDataAttributeProvider(const AttributeDomain domain,
|
|
|
|
|
const CustomDataAccessInfo custom_data_access)
|
|
|
|
|
: domain_(domain), custom_data_access_(custom_data_access)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
ReadAttributeLookup try_get_for_read(const GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
WriteAttributeLookup try_get_for_write(GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
bool try_delete(GeometryComponent &component, const AttributeIDRef &attribute_id) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
|
|
|
|
bool try_create(GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id,
|
2021-03-08 11:41:23 -05:00
|
|
|
const AttributeDomain domain,
|
2021-04-22 09:20:03 -05:00
|
|
|
const CustomDataType data_type,
|
|
|
|
|
const AttributeInit &initializer) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
|
|
|
|
bool foreach_attribute(const GeometryComponent &component,
|
|
|
|
|
const AttributeForeachCallback callback) const final;
|
|
|
|
|
|
2021-03-17 11:50:13 +01:00
|
|
|
void foreach_domain(const FunctionRef<void(AttributeDomain)> callback) const final
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
2021-03-17 11:50:13 +01:00
|
|
|
callback(domain_);
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
template<typename T>
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
ReadAttributeLookup layer_to_read_attribute(const CustomDataLayer &layer,
|
|
|
|
|
const int domain_size) const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
return {std::make_unique<fn::GVArray_For_Span<T>>(
|
|
|
|
|
Span(static_cast<const T *>(layer.data), domain_size)),
|
|
|
|
|
domain_};
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<typename T>
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
WriteAttributeLookup layer_to_write_attribute(CustomDataLayer &layer,
|
|
|
|
|
const int domain_size) const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
return {std::make_unique<fn::GVMutableArray_For_MutableSpan<T>>(
|
|
|
|
|
MutableSpan(static_cast<T *>(layer.data), domain_size)),
|
|
|
|
|
domain_};
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool type_is_supported(CustomDataType data_type) const
|
|
|
|
|
{
|
|
|
|
|
return ((1ULL << data_type) & supported_types_mask) != 0;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This attribute provider is used for uv maps and vertex colors.
|
|
|
|
|
*/
|
|
|
|
|
class NamedLegacyCustomDataProvider final : public DynamicAttributesProvider {
|
|
|
|
|
private:
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
using AsReadAttribute = GVArrayPtr (*)(const void *data, const int domain_size);
|
|
|
|
|
using AsWriteAttribute = GVMutableArrayPtr (*)(void *data, const int domain_size);
|
2021-03-08 11:41:23 -05:00
|
|
|
const AttributeDomain domain_;
|
|
|
|
|
const CustomDataType attribute_type_;
|
|
|
|
|
const CustomDataType stored_type_;
|
|
|
|
|
const CustomDataAccessInfo custom_data_access_;
|
|
|
|
|
const AsReadAttribute as_read_attribute_;
|
|
|
|
|
const AsWriteAttribute as_write_attribute_;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
NamedLegacyCustomDataProvider(const AttributeDomain domain,
|
|
|
|
|
const CustomDataType attribute_type,
|
|
|
|
|
const CustomDataType stored_type,
|
|
|
|
|
const CustomDataAccessInfo custom_data_access,
|
|
|
|
|
const AsReadAttribute as_read_attribute,
|
|
|
|
|
const AsWriteAttribute as_write_attribute)
|
|
|
|
|
: domain_(domain),
|
|
|
|
|
attribute_type_(attribute_type),
|
|
|
|
|
stored_type_(stored_type),
|
|
|
|
|
custom_data_access_(custom_data_access),
|
|
|
|
|
as_read_attribute_(as_read_attribute),
|
|
|
|
|
as_write_attribute_(as_write_attribute)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
ReadAttributeLookup try_get_for_read(const GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const final;
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
WriteAttributeLookup try_get_for_write(GeometryComponent &component,
|
2021-09-09 12:54:20 +02:00
|
|
|
const AttributeIDRef &attribute_id) const final;
|
|
|
|
|
bool try_delete(GeometryComponent &component, const AttributeIDRef &attribute_id) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
bool foreach_attribute(const GeometryComponent &component,
|
|
|
|
|
const AttributeForeachCallback callback) const final;
|
2021-03-17 11:50:13 +01:00
|
|
|
void foreach_domain(const FunctionRef<void(AttributeDomain)> callback) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This provider is used to provide access to builtin attributes. It supports making internal types
|
|
|
|
|
* available as different types. For example, the vertex position attribute is stored as part of
|
|
|
|
|
* the #MVert struct, but is exposed as float3 attribute.
|
|
|
|
|
*/
|
|
|
|
|
class BuiltinCustomDataLayerProvider final : public BuiltinAttributeProvider {
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
using AsReadAttribute = GVArrayPtr (*)(const void *data, const int domain_size);
|
|
|
|
|
using AsWriteAttribute = GVMutableArrayPtr (*)(void *data, const int domain_size);
|
2021-03-08 11:41:23 -05:00
|
|
|
using UpdateOnRead = void (*)(const GeometryComponent &component);
|
|
|
|
|
using UpdateOnWrite = void (*)(GeometryComponent &component);
|
|
|
|
|
const CustomDataType stored_type_;
|
|
|
|
|
const CustomDataAccessInfo custom_data_access_;
|
|
|
|
|
const AsReadAttribute as_read_attribute_;
|
|
|
|
|
const AsWriteAttribute as_write_attribute_;
|
|
|
|
|
const UpdateOnWrite update_on_write_;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
BuiltinCustomDataLayerProvider(std::string attribute_name,
|
|
|
|
|
const AttributeDomain domain,
|
|
|
|
|
const CustomDataType attribute_type,
|
|
|
|
|
const CustomDataType stored_type,
|
|
|
|
|
const CreatableEnum creatable,
|
|
|
|
|
const WritableEnum writable,
|
|
|
|
|
const DeletableEnum deletable,
|
|
|
|
|
const CustomDataAccessInfo custom_data_access,
|
|
|
|
|
const AsReadAttribute as_read_attribute,
|
|
|
|
|
const AsWriteAttribute as_write_attribute,
|
|
|
|
|
const UpdateOnWrite update_on_write)
|
|
|
|
|
: BuiltinAttributeProvider(
|
|
|
|
|
std::move(attribute_name), domain, attribute_type, creatable, writable, deletable),
|
|
|
|
|
stored_type_(stored_type),
|
|
|
|
|
custom_data_access_(custom_data_access),
|
|
|
|
|
as_read_attribute_(as_read_attribute),
|
|
|
|
|
as_write_attribute_(as_write_attribute),
|
|
|
|
|
update_on_write_(update_on_write)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
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
2021-04-17 16:41:03 +02:00
|
|
|
GVArrayPtr try_get_for_read(const GeometryComponent &component) const final;
|
|
|
|
|
GVMutableArrayPtr try_get_for_write(GeometryComponent &component) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
bool try_delete(GeometryComponent &component) const final;
|
2021-04-22 09:20:03 -05:00
|
|
|
bool try_create(GeometryComponent &component, const AttributeInit &initializer) const final;
|
2021-03-08 11:41:23 -05:00
|
|
|
bool exists(const GeometryComponent &component) const final;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This is a container for multiple attribute providers that are used by one geometry component
|
|
|
|
|
* type (e.g. there is a set of attribute providers for mesh components).
|
|
|
|
|
*/
|
|
|
|
|
class ComponentAttributeProviders {
|
|
|
|
|
private:
|
|
|
|
|
/**
|
|
|
|
|
* Builtin attribute providers are identified by their name. Attribute names that are in this
|
|
|
|
|
* map will only be accessed using builtin attribute providers. Therefore, these providers have
|
|
|
|
|
* higher priority when an attribute name is looked up. Usually, that means that builtin
|
|
|
|
|
* providers are checked before dynamic ones.
|
|
|
|
|
*/
|
2021-03-17 11:51:51 +01:00
|
|
|
Map<std::string, const BuiltinAttributeProvider *> builtin_attribute_providers_;
|
2021-03-08 11:41:23 -05:00
|
|
|
/**
|
|
|
|
|
* An ordered list of dynamic attribute providers. The order is important because that is order
|
|
|
|
|
* in which they are checked when an attribute is looked up.
|
|
|
|
|
*/
|
2021-03-17 11:51:51 +01:00
|
|
|
Vector<const DynamicAttributesProvider *> dynamic_attribute_providers_;
|
2021-03-08 11:41:23 -05:00
|
|
|
/**
|
|
|
|
|
* All the domains that are supported by at least one of the providers above.
|
|
|
|
|
*/
|
2021-03-17 11:51:51 +01:00
|
|
|
VectorSet<AttributeDomain> supported_domains_;
|
2021-03-08 11:41:23 -05:00
|
|
|
|
|
|
|
|
public:
|
2021-03-17 11:51:51 +01:00
|
|
|
ComponentAttributeProviders(Span<const BuiltinAttributeProvider *> builtin_attribute_providers,
|
|
|
|
|
Span<const DynamicAttributesProvider *> dynamic_attribute_providers)
|
2021-03-08 11:41:23 -05:00
|
|
|
: dynamic_attribute_providers_(dynamic_attribute_providers)
|
|
|
|
|
{
|
|
|
|
|
for (const BuiltinAttributeProvider *provider : builtin_attribute_providers) {
|
|
|
|
|
/* Use #add_new to make sure that no two builtin attributes have the same name. */
|
|
|
|
|
builtin_attribute_providers_.add_new(provider->name(), provider);
|
2021-03-17 11:50:13 +01:00
|
|
|
supported_domains_.add(provider->domain());
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
for (const DynamicAttributesProvider *provider : dynamic_attribute_providers) {
|
2021-03-17 11:50:13 +01:00
|
|
|
provider->foreach_domain([&](AttributeDomain domain) { supported_domains_.add(domain); });
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 11:51:51 +01:00
|
|
|
const Map<std::string, const BuiltinAttributeProvider *> &builtin_attribute_providers() const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
return builtin_attribute_providers_;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 11:51:51 +01:00
|
|
|
Span<const DynamicAttributesProvider *> dynamic_attribute_providers() const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
return dynamic_attribute_providers_;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-17 11:51:51 +01:00
|
|
|
Span<AttributeDomain> supported_domains() const
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
return supported_domains_;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2021-03-17 11:50:13 +01:00
|
|
|
} // namespace blender::bke
|