2020-12-02 13:25:25 +01: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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <atomic>
|
|
|
|
#include <iostream>
|
|
|
|
|
|
|
|
#include "BLI_float3.hh"
|
2021-01-26 18:21:12 +01:00
|
|
|
#include "BLI_float4x4.hh"
|
2021-09-23 17:50:33 +02:00
|
|
|
#include "BLI_function_ref.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "BLI_hash.hh"
|
|
|
|
#include "BLI_map.hh"
|
|
|
|
#include "BLI_set.hh"
|
|
|
|
#include "BLI_user_counter.hh"
|
2021-05-04 10:16:24 +02:00
|
|
|
#include "BLI_vector_set.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
#include "BKE_anonymous_attribute.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "BKE_attribute_access.hh"
|
|
|
|
#include "BKE_geometry_set.h"
|
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
#include "FN_field.hh"
|
|
|
|
|
2020-12-16 06:26:23 +01:00
|
|
|
struct Collection;
|
2021-07-16 03:48:54 +02:00
|
|
|
struct Curve;
|
|
|
|
struct CurveEval;
|
2020-12-02 13:25:25 +01:00
|
|
|
struct Mesh;
|
|
|
|
struct Object;
|
2020-12-16 06:26:23 +01:00
|
|
|
struct PointCloud;
|
2021-01-21 10:32:42 +01:00
|
|
|
struct Volume;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
enum class GeometryOwnershipType {
|
|
|
|
/* The geometry is owned. This implies that it can be changed. */
|
|
|
|
Owned = 0,
|
|
|
|
/* The geometry can be changed, but someone else is responsible for freeing it. */
|
|
|
|
Editable = 1,
|
|
|
|
/* The geometry cannot be changed and someone else is responsible for freeing it. */
|
|
|
|
ReadOnly = 2,
|
|
|
|
};
|
|
|
|
|
2021-02-09 11:24:28 +01:00
|
|
|
namespace blender::bke {
|
2021-02-09 11:47:49 +01:00
|
|
|
class ComponentAttributeProviders;
|
2021-02-09 11:24:28 +01:00
|
|
|
}
|
|
|
|
|
2021-01-14 15:52:08 +01:00
|
|
|
class GeometryComponent;
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/**
|
2021-12-07 19:04:32 +01:00
|
|
|
* This is the base class for specialized geometry component types. A geometry component handles
|
|
|
|
* a user count to allow avoiding duplication when it is wrapped with #UserCounter. It also handles
|
|
|
|
* the attribute API, which generalizes storing and modifying generic information on a geometry.
|
2020-12-02 13:25:25 +01:00
|
|
|
*/
|
|
|
|
class GeometryComponent {
|
|
|
|
private:
|
|
|
|
/* The reference count has two purposes. When it becomes zero, the component is freed. When it is
|
|
|
|
* larger than one, the component becomes immutable. */
|
|
|
|
mutable std::atomic<int> users_ = 1;
|
|
|
|
GeometryComponentType type_;
|
|
|
|
|
|
|
|
public:
|
|
|
|
GeometryComponent(GeometryComponentType type);
|
2021-04-08 11:07:12 +02:00
|
|
|
virtual ~GeometryComponent() = default;
|
2020-12-02 13:25:25 +01:00
|
|
|
static GeometryComponent *create(GeometryComponentType component_type);
|
|
|
|
|
|
|
|
/* The returned component should be of the same type as the type this is called on. */
|
|
|
|
virtual GeometryComponent *copy() const = 0;
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
/* Direct data is everything except for instances of objects/collections.
|
|
|
|
* If this returns true, the geometry set can be cached and is still valid after e.g. modifier
|
|
|
|
* evaluation ends. Instances can only be valid as long as the data they instance is valid. */
|
|
|
|
virtual bool owns_direct_data() const = 0;
|
|
|
|
virtual void ensure_owns_direct_data() = 0;
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
void user_add() const;
|
|
|
|
void user_remove() const;
|
|
|
|
bool is_mutable() const;
|
|
|
|
|
|
|
|
GeometryComponentType type() const;
|
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Return true when any attribute with this name exists, including built in attributes.
|
|
|
|
*/
|
2021-09-09 12:54:20 +02:00
|
|
|
bool attribute_exists(const blender::bke::AttributeIDRef &attribute_id) const;
|
2020-12-10 17:50:37 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Return the data type and domain of an attribute with the given name if it exists.
|
|
|
|
*/
|
2021-04-22 15:05:02 +02:00
|
|
|
std::optional<AttributeMetaData> attribute_get_meta_data(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id) const;
|
2021-04-22 15:05:02 +02:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Return true when the geometry component supports this attribute domain.
|
|
|
|
* \note Conceptually this function is static, the result is always the same for different
|
|
|
|
* instances of the same geometry component type.
|
|
|
|
*/
|
2021-02-09 11:24:28 +01:00
|
|
|
bool attribute_domain_supported(const AttributeDomain domain) const;
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Return the length of a specific domain, or 0 if the domain is not supported.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
virtual int attribute_domain_size(const AttributeDomain domain) const;
|
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Return true if the attribute name corresponds to a built-in attribute with a hardcoded domain
|
|
|
|
* and data type.
|
|
|
|
*/
|
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
|
|
|
bool attribute_is_builtin(const blender::StringRef attribute_name) const;
|
2021-09-16 18:56:31 +02:00
|
|
|
bool attribute_is_builtin(const blender::bke::AttributeIDRef &attribute_id) const;
|
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
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get read-only access to an attribute with the given name or id, on the highest priority domain
|
|
|
|
* if there is a name collision.
|
|
|
|
* \return null if the attribute does not exist.
|
|
|
|
*/
|
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
|
|
|
blender::bke::ReadAttributeLookup attribute_try_get_for_read(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id) const;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get read and write access to an attribute with the given name or id, on the highest priority
|
|
|
|
* domain if there is a name collision.
|
|
|
|
* \note #WriteAttributeLookup.tag_modified_fn must be called after modifying data.
|
|
|
|
* \return null if the attribute does not exist
|
|
|
|
*/
|
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
|
|
|
blender::bke::WriteAttributeLookup attribute_try_get_for_write(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id);
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get a read-only attribute for the domain based on the given attribute. This can be used to
|
2020-12-02 13:25:25 +01:00
|
|
|
* interpolate from one domain to another.
|
2021-12-25 22:08:38 +01:00
|
|
|
* \return null if the interpolation is not implemented.
|
|
|
|
*/
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
blender::fn::GVArray attribute_try_adapt_domain(const blender::fn::GVArray &varray,
|
|
|
|
const AttributeDomain from_domain,
|
|
|
|
const AttributeDomain to_domain) const
|
|
|
|
{
|
|
|
|
return this->attribute_try_adapt_domain_impl(varray, from_domain, to_domain);
|
|
|
|
}
|
2021-12-25 22:08:38 +01:00
|
|
|
/* Use instead of the method above when the type is known at compile time for type safety. */
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
template<typename T>
|
|
|
|
blender::VArray<T> attribute_try_adapt_domain(const blender::VArray<T> &varray,
|
|
|
|
const AttributeDomain from_domain,
|
|
|
|
const AttributeDomain to_domain) const
|
|
|
|
{
|
|
|
|
return this->attribute_try_adapt_domain_impl(varray, from_domain, to_domain)
|
|
|
|
.template typed<T>();
|
|
|
|
}
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/** Returns true when the attribute has been deleted. */
|
2021-09-09 12:54:20 +02:00
|
|
|
bool attribute_try_delete(const blender::bke::AttributeIDRef &attribute_id);
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/** Returns true when the attribute has been created. */
|
2021-09-09 12:54:20 +02:00
|
|
|
bool attribute_try_create(const blender::bke::AttributeIDRef &attribute_id,
|
2021-02-09 11:24:28 +01:00
|
|
|
const AttributeDomain domain,
|
2021-04-22 16:20:03 +02:00
|
|
|
const CustomDataType data_type,
|
|
|
|
const AttributeInit &initializer);
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Try to create the builtin attribute with the given name. No data type or domain has to be
|
|
|
|
* provided, because those are fixed for builtin attributes.
|
|
|
|
*/
|
2021-04-22 16:20:03 +02:00
|
|
|
bool attribute_try_create_builtin(const blender::StringRef attribute_name,
|
|
|
|
const AttributeInit &initializer);
|
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
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
blender::Set<blender::bke::AttributeIDRef> attribute_ids() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* \return False if the callback explicitly returned false at any point, otherwise true,
|
|
|
|
* meaning the callback made it all the way through.
|
|
|
|
*/
|
2021-04-08 19:19:09 +02:00
|
|
|
bool attribute_foreach(const AttributeForeachCallback callback) const;
|
2021-02-23 15:15:23 +01:00
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
virtual bool is_empty() const;
|
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get a virtual array that refers to the data of an attribute, interpolated to the given domain
|
|
|
|
* and converted to the data type. Returns null when the attribute does not exist or cannot be
|
|
|
|
* interpolated or converted.
|
|
|
|
*/
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
blender::fn::GVArray attribute_try_get_for_read(const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType data_type) const;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get a virtual array that refers to the data of an attribute, interpolated to the given domain.
|
|
|
|
* The data type is left unchanged. Returns null when the attribute does not exist or cannot be
|
|
|
|
* interpolated.
|
|
|
|
*/
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
blender::fn::GVArray attribute_try_get_for_read(const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain) const;
|
2020-12-17 14:43:31 +01:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get a virtual array that refers to the data of an attribute converted to the given data type.
|
|
|
|
* The attribute's domain is left unchanged. Returns null when the attribute does not exist or
|
|
|
|
* cannot be converted.
|
|
|
|
*/
|
2021-04-21 17:07:00 +02:00
|
|
|
blender::bke::ReadAttributeLookup attribute_try_get_for_read(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id, const CustomDataType data_type) const;
|
2021-04-21 17:07:00 +02:00
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Get a virtual array that refers to the data of an attribute, interpolated to the given domain
|
|
|
|
* and converted to the data type. If that is not possible, the returned virtual array will
|
|
|
|
* contain a default value. This never returns null.
|
|
|
|
*/
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
blender::fn::GVArray attribute_get_for_read(const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType data_type,
|
|
|
|
const void *default_value = nullptr) const;
|
2021-12-25 22:08:38 +01:00
|
|
|
/* Use instead of the method above when the type is known at compile time for type safety. */
|
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
|
|
|
template<typename T>
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
blender::VArray<T> attribute_get_for_read(const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const T &default_value) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<T>();
|
|
|
|
const CustomDataType type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
return this->attribute_get_for_read(attribute_id, domain, type, &default_value)
|
|
|
|
.template typed<T>();
|
2020-12-02 13:25:25 +01: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
|
|
|
/**
|
|
|
|
* Returns an "output attribute", which is essentially a mutable virtual array with some commonly
|
2021-04-19 15:56:12 +02:00
|
|
|
* used convince features. The returned output attribute might be empty if requested 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
|
|
|
* cannot exist on the geometry.
|
|
|
|
*
|
|
|
|
* The included convenience features are:
|
|
|
|
* - Implicit type conversion when writing to builtin attributes.
|
|
|
|
* - If the attribute name exists already, but has a different type/domain, a temporary attribute
|
|
|
|
* is created that will overwrite the existing attribute in the end.
|
|
|
|
*/
|
|
|
|
blender::bke::OutputAttribute attribute_try_get_for_output(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id,
|
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
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType data_type,
|
|
|
|
const void *default_value = nullptr);
|
2021-12-25 22:08:38 +01:00
|
|
|
/* Use instead of the method above when the type is known at compile time for type safety. */
|
2020-12-02 13:25:25 +01: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
|
|
|
blender::bke::OutputAttribute_Typed<T> attribute_try_get_for_output(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const T default_value)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<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
|
|
|
const CustomDataType data_type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
|
2021-09-09 12:54:20 +02:00
|
|
|
return this->attribute_try_get_for_output(attribute_id, domain, data_type, &default_value);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
2021-12-25 22:08:38 +01:00
|
|
|
/**
|
|
|
|
* Same as #attribute_try_get_for_output, but should be used when the original values in the
|
|
|
|
* attributes are not read, i.e. the attribute is used only for output. The can be faster because
|
|
|
|
* it can avoid interpolation and conversion of existing values. Since values are not read from
|
|
|
|
* this attribute, no default value is necessary.
|
|
|
|
*/
|
|
|
|
blender::bke::OutputAttribute attribute_try_get_for_output_only(
|
|
|
|
const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType data_type);
|
|
|
|
/* Use instead of the method above when the type is known at compile time for type safety. */
|
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
|
|
|
template<typename T>
|
|
|
|
blender::bke::OutputAttribute_Typed<T> attribute_try_get_for_output_only(
|
2021-09-09 12:54:20 +02:00
|
|
|
const blender::bke::AttributeIDRef &attribute_id, const AttributeDomain domain)
|
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
|
|
|
{
|
|
|
|
const blender::fn::CPPType &cpp_type = blender::fn::CPPType::get<T>();
|
|
|
|
const CustomDataType data_type = blender::bke::cpp_type_to_custom_data_type(cpp_type);
|
2021-09-09 12:54:20 +02:00
|
|
|
return this->attribute_try_get_for_output_only(attribute_id, domain, data_type);
|
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
|
|
|
}
|
2021-02-09 11:24:28 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
virtual const blender::bke::ComponentAttributeProviders *get_attribute_providers() const;
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
|
|
|
|
virtual blender::fn::GVArray attribute_try_adapt_domain_impl(
|
|
|
|
const blender::fn::GVArray &varray,
|
|
|
|
const AttributeDomain from_domain,
|
|
|
|
const AttributeDomain to_domain) const;
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
inline constexpr bool is_geometry_component_v = std::is_base_of_v<GeometryComponent, T>;
|
|
|
|
|
|
|
|
/**
|
2021-12-07 19:04:32 +01:00
|
|
|
* A geometry set is a container for multiple kinds of geometry. It does not own geometry directly
|
|
|
|
* itself, instead geometry is owned by multiple #GeometryComponents, and the geometry set
|
|
|
|
* increases the user count of each component, so they avoid losing the data. This means
|
|
|
|
* individual components might be shared between multiple geometries and other code. Shared
|
|
|
|
* components are copied automatically when write access is requested.
|
|
|
|
*
|
2021-12-13 06:00:39 +01:00
|
|
|
* The components usually do not store data directly, but keep a reference to a data
|
|
|
|
* structure defined elsewhere. There is at most one component of each type:
|
2021-12-07 19:04:32 +01:00
|
|
|
* - #MeshComponent
|
|
|
|
* - #CurveComponent
|
|
|
|
* - #PointCloudComponent
|
|
|
|
* - #InstancesComponent
|
|
|
|
* - #VolumeComponent
|
2020-12-02 13:25:25 +01:00
|
|
|
*
|
|
|
|
* Copying a geometry set is a relatively cheap operation, because it does not copy the referenced
|
2021-12-07 19:04:32 +01:00
|
|
|
* geometry components, so #GeometrySet can often be passed or moved by value.
|
2020-12-02 13:25:25 +01:00
|
|
|
*/
|
|
|
|
struct GeometrySet {
|
|
|
|
private:
|
|
|
|
using GeometryComponentPtr = blender::UserCounter<class GeometryComponent>;
|
2021-12-05 15:10:11 +01:00
|
|
|
/* Indexed by #GeometryComponentType. */
|
|
|
|
std::array<GeometryComponentPtr, GEO_COMPONENT_TYPE_ENUM_SIZE> components_;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
public:
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* The methods are defaulted here so that they are not instantiated in every translation unit.
|
|
|
|
*/
|
2021-10-03 16:58:33 +02:00
|
|
|
GeometrySet();
|
|
|
|
GeometrySet(const GeometrySet &other);
|
|
|
|
GeometrySet(GeometrySet &&other);
|
|
|
|
~GeometrySet();
|
|
|
|
GeometrySet &operator=(const GeometrySet &other);
|
|
|
|
GeometrySet &operator=(GeometrySet &&other);
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* This method can only be used when the geometry set is mutable. It returns a mutable geometry
|
|
|
|
* component of the given type.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
GeometryComponent &get_component_for_write(GeometryComponentType component_type);
|
|
|
|
template<typename Component> Component &get_component_for_write()
|
|
|
|
{
|
|
|
|
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
|
|
|
|
return static_cast<Component &>(this->get_component_for_write(Component::static_type));
|
|
|
|
}
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the component of the given type. Might return null if the component does not exist yet.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
const GeometryComponent *get_component_for_read(GeometryComponentType component_type) const;
|
|
|
|
template<typename Component> const Component *get_component_for_read() const
|
|
|
|
{
|
|
|
|
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
|
|
|
|
return static_cast<const Component *>(get_component_for_read(Component::static_type));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool has(const GeometryComponentType component_type) const;
|
|
|
|
template<typename Component> bool has() const
|
|
|
|
{
|
|
|
|
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
|
|
|
|
return this->has(Component::static_type);
|
|
|
|
}
|
|
|
|
|
|
|
|
void remove(const GeometryComponentType component_type);
|
|
|
|
template<typename Component> void remove()
|
|
|
|
{
|
|
|
|
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
|
|
|
|
return this->remove(Component::static_type);
|
|
|
|
}
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Remove all geometry components with types that are not in the provided list.
|
|
|
|
*/
|
2021-09-28 15:52:04 +02:00
|
|
|
void keep_only(const blender::Span<GeometryComponentType> component_types);
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
void add(const GeometryComponent &component);
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get all geometry components in this geometry set for read-only access.
|
|
|
|
*/
|
2021-02-19 12:29:37 +01:00
|
|
|
blender::Vector<const GeometryComponent *> get_components_for_read() const;
|
|
|
|
|
2021-12-29 16:27:24 +01:00
|
|
|
bool compute_boundbox_without_instances(blender::float3 *r_min, blender::float3 *r_max) const;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
friend std::ostream &operator<<(std::ostream &stream, const GeometrySet &geometry_set);
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Remove all geometry components from the geometry set.
|
|
|
|
*/
|
2021-03-30 12:34:05 +02:00
|
|
|
void clear();
|
|
|
|
|
2021-09-06 18:22:24 +02:00
|
|
|
bool owns_direct_data() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Make sure that the geometry can be cached. This does not ensure ownership of object/collection
|
2021-12-07 19:04:32 +01:00
|
|
|
* instances. This is necessary because sometimes components only have read-only or editing
|
|
|
|
* access to their data, which might be freed later if this geometry set outlasts the data.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2021-04-08 17:35:06 +02:00
|
|
|
void ensure_owns_direct_data();
|
|
|
|
|
2021-09-23 17:50:33 +02:00
|
|
|
using AttributeForeachCallback =
|
|
|
|
blender::FunctionRef<void(const blender::bke::AttributeIDRef &attribute_id,
|
|
|
|
const AttributeMetaData &meta_data,
|
|
|
|
const GeometryComponent &component)>;
|
|
|
|
|
|
|
|
void attribute_foreach(blender::Span<GeometryComponentType> component_types,
|
|
|
|
bool include_instances,
|
|
|
|
AttributeForeachCallback callback) const;
|
|
|
|
|
|
|
|
void gather_attributes_for_propagation(
|
|
|
|
blender::Span<GeometryComponentType> component_types,
|
|
|
|
GeometryComponentType dst_component_type,
|
|
|
|
bool include_instances,
|
|
|
|
blender::Map<blender::bke::AttributeIDRef, AttributeKind> &r_attributes) const;
|
|
|
|
|
2021-10-27 04:59:41 +02:00
|
|
|
blender::Vector<GeometryComponentType> gather_component_types(bool include_instances,
|
|
|
|
bool ignore_empty) const;
|
2021-10-26 20:00:03 +02:00
|
|
|
|
2021-09-27 17:35:26 +02:00
|
|
|
using ForeachSubGeometryCallback = blender::FunctionRef<void(GeometrySet &geometry_set)>;
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Modify every (recursive) instance separately. This is often more efficient than realizing all
|
|
|
|
* instances just to change the same thing on all of them.
|
|
|
|
*/
|
2021-09-27 17:35:26 +02:00
|
|
|
void modify_geometry_sets(ForeachSubGeometryCallback callback);
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/* Utility methods for creation. */
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create a new geometry set that only contains the given mesh.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
static GeometrySet create_with_mesh(
|
|
|
|
Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create a new geometry set that only contains the given point cloud.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
static GeometrySet create_with_pointcloud(
|
|
|
|
PointCloud *pointcloud, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create a new geometry set that only contains the given curve.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
static GeometrySet create_with_curve(
|
|
|
|
CurveEval *curve, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
/* Utility methods for access. */
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has a mesh component that has a mesh.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
bool has_mesh() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has a point cloud component that has a point cloud.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
bool has_pointcloud() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has an instances component that has at least one instance.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
bool has_instances() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has a volume component that has a volume.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
bool has_volume() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has a curve component that has a curve.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
bool has_curve() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true when the geometry set has any data that is not an instance.
|
|
|
|
*/
|
2021-09-27 10:16:38 +02:00
|
|
|
bool has_realized_data() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Return true if the geometry set has any component that isn't empty.
|
|
|
|
*/
|
2021-09-28 18:36:28 +02:00
|
|
|
bool is_empty() const;
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a read-only mesh or null.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
const Mesh *get_mesh_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a read-only point cloud of null.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
const PointCloud *get_pointcloud_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a read-only volume or null.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
const Volume *get_volume_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a read-only curve or null.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
const CurveEval *get_curve_for_read() const;
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a mutable mesh or null. No ownership is transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
Mesh *get_mesh_for_write();
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a mutable point cloud or null. No ownership is transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
PointCloud *get_pointcloud_for_write();
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a mutable volume or null. No ownership is transferred.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
Volume *get_volume_for_write();
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a mutable curve or null. No ownership is transferred.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
CurveEval *get_curve_for_write();
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
/* Utility methods for replacement. */
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the existing mesh and replace it with the given one.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
void replace_mesh(Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the existing point cloud and replace with the given one.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
void replace_pointcloud(PointCloud *pointcloud,
|
|
|
|
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the existing volume and replace with the given one.
|
|
|
|
*/
|
2021-04-26 21:42:03 +02:00
|
|
|
void replace_volume(Volume *volume,
|
|
|
|
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the existing curve and replace it with the given one.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
void replace_curve(CurveEval *curve,
|
|
|
|
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-10-14 19:43:36 +02:00
|
|
|
|
|
|
|
private:
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Retrieve the pointer to a component without creating it if it does not exist,
|
|
|
|
* unlike #get_component_for_write.
|
|
|
|
*/
|
2021-10-14 19:43:36 +02:00
|
|
|
GeometryComponent *get_component_ptr(GeometryComponentType type);
|
|
|
|
template<typename Component> Component *get_component_ptr()
|
|
|
|
{
|
|
|
|
BLI_STATIC_ASSERT(is_geometry_component_v<Component>, "");
|
|
|
|
return static_cast<Component *>(get_component_ptr(Component::static_type));
|
|
|
|
}
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* A geometry component that can store a mesh, storing the #Mesh data structure.
|
|
|
|
*
|
|
|
|
* Attributes are stored in the mesh itself, on any of the four attribute domains. Generic
|
|
|
|
* attributes are stored in contiguous arrays, but often built-in attributes are stored in an
|
|
|
|
* array of structs fashion for historical reasons, requiring more complex attribute access.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
class MeshComponent : public GeometryComponent {
|
|
|
|
private:
|
|
|
|
Mesh *mesh_ = nullptr;
|
|
|
|
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
|
|
|
public:
|
|
|
|
MeshComponent();
|
|
|
|
~MeshComponent();
|
|
|
|
GeometryComponent *copy() const override;
|
|
|
|
|
|
|
|
void clear();
|
|
|
|
bool has_mesh() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the component and replace it with the new mesh.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
void replace(Mesh *mesh, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Return the mesh and clear the component. The caller takes over responsibility for freeing the
|
|
|
|
* mesh (if the component was responsible before).
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
Mesh *release();
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the mesh from this component. This method can be used by multiple threads at the same
|
|
|
|
* time. Therefore, the returned mesh should not be modified. No ownership is transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
const Mesh *get_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the mesh from this component. This method can only be used when the component is mutable,
|
|
|
|
* i.e. it is not shared. The returned mesh can be modified. No ownership is transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
Mesh *get_for_write();
|
|
|
|
|
|
|
|
int attribute_domain_size(const AttributeDomain domain) const final;
|
|
|
|
|
|
|
|
bool is_empty() const final;
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
bool owns_direct_data() const override;
|
|
|
|
void ensure_owns_direct_data() override;
|
|
|
|
|
2021-03-10 11:53:17 +01:00
|
|
|
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_MESH;
|
2021-02-09 11:24:28 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
|
|
|
|
blender::fn::GVArray attribute_try_adapt_domain_impl(
|
|
|
|
const blender::fn::GVArray &varray,
|
|
|
|
const AttributeDomain from_domain,
|
|
|
|
const AttributeDomain to_domain) const final;
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* A geometry component that stores a point cloud, corresponding to the #PointCloud data structure.
|
|
|
|
* While a point cloud is technically a subset of a mesh in some respects, it is useful because of
|
|
|
|
* its simplicity, partly on a conceptual level for the user, but also in the code, though partly
|
2021-12-13 06:00:39 +01:00
|
|
|
* for historical reasons. Point clouds can also be rendered in special ways, based on the built-in
|
2021-12-07 19:04:32 +01:00
|
|
|
* `radius` attribute.
|
|
|
|
*
|
|
|
|
* Attributes on point clouds are all stored in contiguous arrays in its #CustomData,
|
|
|
|
* which makes them efficient to process, relative to some legacy built-in mesh attributes.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
class PointCloudComponent : public GeometryComponent {
|
|
|
|
private:
|
|
|
|
PointCloud *pointcloud_ = nullptr;
|
|
|
|
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
|
|
|
public:
|
|
|
|
PointCloudComponent();
|
|
|
|
~PointCloudComponent();
|
|
|
|
GeometryComponent *copy() const override;
|
|
|
|
|
|
|
|
void clear();
|
|
|
|
bool has_pointcloud() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the component and replace it with the new point cloud.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
void replace(PointCloud *pointcloud,
|
|
|
|
GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Return the point cloud and clear the component. The caller takes over responsibility for
|
|
|
|
* freeing the point cloud (if the component was responsible before).
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
PointCloud *release();
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the point cloud from this component. This method can be used by multiple threads at the
|
|
|
|
* same time. Therefore, the returned point cloud should not be modified. No ownership is
|
|
|
|
* transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
const PointCloud *get_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the point cloud from this component. This method can only be used when the component is
|
|
|
|
* mutable, i.e. it is not shared. The returned point cloud can be modified. No ownership is
|
|
|
|
* transferred.
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
PointCloud *get_for_write();
|
|
|
|
|
|
|
|
int attribute_domain_size(const AttributeDomain domain) const final;
|
|
|
|
|
|
|
|
bool is_empty() const final;
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
bool owns_direct_data() const override;
|
|
|
|
void ensure_owns_direct_data() override;
|
|
|
|
|
2021-03-10 11:53:17 +01:00
|
|
|
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_POINT_CLOUD;
|
2021-02-09 11:24:28 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* A geometry component that stores curve data, in other words, a group of splines.
|
|
|
|
* Curves are stored differently than other geometry components, because the data structure used
|
|
|
|
* here does not correspond exactly to the #Curve DNA data structure. A #CurveEval is stored here
|
|
|
|
* instead, though the component does give access to a #Curve for interfacing with render engines
|
|
|
|
* and other areas of Blender that expect to use a data-block with an #ID.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
class CurveComponent : public GeometryComponent {
|
|
|
|
private:
|
|
|
|
CurveEval *curve_ = nullptr;
|
|
|
|
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
2021-05-27 16:08:40 +02:00
|
|
|
/**
|
|
|
|
* Curve data necessary to hold the draw cache for rendering, consistent over multiple redraws.
|
|
|
|
* This is necessary because Blender assumes that objects evaluate to an object data type, and
|
|
|
|
* we use #CurveEval rather than #Curve here. It also allows us to mostly reuse the same
|
|
|
|
* batch cache implementation.
|
|
|
|
*/
|
|
|
|
mutable Curve *curve_for_render_ = nullptr;
|
|
|
|
mutable std::mutex curve_for_render_mutex_;
|
|
|
|
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
public:
|
|
|
|
CurveComponent();
|
|
|
|
~CurveComponent();
|
|
|
|
GeometryComponent *copy() const override;
|
|
|
|
|
|
|
|
void clear();
|
|
|
|
bool has_curve() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the component and replace it with the new curve.
|
|
|
|
*/
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
void replace(CurveEval *curve, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
|
|
|
CurveEval *release();
|
|
|
|
|
|
|
|
const CurveEval *get_for_read() const;
|
|
|
|
CurveEval *get_for_write();
|
|
|
|
|
|
|
|
int attribute_domain_size(const AttributeDomain domain) const final;
|
|
|
|
|
|
|
|
bool is_empty() const final;
|
|
|
|
|
|
|
|
bool owns_direct_data() const override;
|
|
|
|
void ensure_owns_direct_data() override;
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Create empty curve data used for rendering the spline's wire edges.
|
|
|
|
* \note See comment on #curve_for_render_ for further explanation.
|
|
|
|
*/
|
2021-05-27 16:08:40 +02:00
|
|
|
const Curve *get_curve_for_render() const;
|
|
|
|
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_CURVE;
|
|
|
|
|
|
|
|
private:
|
|
|
|
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
|
Geometry Nodes: refactor virtual array system
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
2021-11-16 10:15:51 +01:00
|
|
|
|
|
|
|
blender::fn::GVArray attribute_try_adapt_domain_impl(
|
|
|
|
const blender::fn::GVArray &varray,
|
|
|
|
const AttributeDomain from_domain,
|
|
|
|
const AttributeDomain to_domain) const final;
|
Geometry Nodes: Initial basic curve data support
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
2021-05-03 19:29:17 +02:00
|
|
|
};
|
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* Holds a reference to conceptually unique geometry or a pointer to object/collection data
|
|
|
|
* that is is instanced with a transform in #InstancesComponent.
|
|
|
|
*/
|
2021-05-04 10:16:24 +02:00
|
|
|
class InstanceReference {
|
|
|
|
public:
|
|
|
|
enum class Type {
|
|
|
|
/**
|
|
|
|
* An empty instance. This allows an `InstanceReference` to be default constructed without
|
|
|
|
* being in an invalid state. There might also be other use cases that we haven't explored much
|
|
|
|
* yet (such as changing the instance later on, and "disabling" some instances).
|
|
|
|
*/
|
|
|
|
None,
|
|
|
|
Object,
|
|
|
|
Collection,
|
2021-09-06 18:22:24 +02:00
|
|
|
GeometrySet,
|
2021-05-04 10:16:24 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
private:
|
|
|
|
Type type_ = Type::None;
|
|
|
|
/** Depending on the type this is either null, an Object or Collection pointer. */
|
|
|
|
void *data_ = nullptr;
|
2021-09-27 17:35:26 +02:00
|
|
|
std::unique_ptr<GeometrySet> geometry_set_;
|
2021-05-04 10:16:24 +02:00
|
|
|
|
|
|
|
public:
|
|
|
|
InstanceReference() = default;
|
|
|
|
|
|
|
|
InstanceReference(Object &object) : type_(Type::Object), data_(&object)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
InstanceReference(Collection &collection) : type_(Type::Collection), data_(&collection)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2021-09-06 18:22:24 +02:00
|
|
|
InstanceReference(GeometrySet geometry_set)
|
|
|
|
: type_(Type::GeometrySet),
|
2021-09-27 17:35:26 +02:00
|
|
|
geometry_set_(std::make_unique<GeometrySet>(std::move(geometry_set)))
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
InstanceReference(const InstanceReference &other) : type_(other.type_), data_(other.data_)
|
2021-09-06 18:22:24 +02:00
|
|
|
{
|
2021-09-27 17:35:26 +02:00
|
|
|
if (other.geometry_set_) {
|
|
|
|
geometry_set_ = std::make_unique<GeometrySet>(*other.geometry_set_);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-09-28 10:17:49 +02:00
|
|
|
InstanceReference(InstanceReference &&other)
|
|
|
|
: type_(other.type_), data_(other.data_), geometry_set_(std::move(other.geometry_set_))
|
|
|
|
{
|
|
|
|
other.type_ = Type::None;
|
|
|
|
other.data_ = nullptr;
|
|
|
|
}
|
|
|
|
|
2021-09-27 17:35:26 +02:00
|
|
|
InstanceReference &operator=(const InstanceReference &other)
|
|
|
|
{
|
|
|
|
if (this == &other) {
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
this->~InstanceReference();
|
|
|
|
new (this) InstanceReference(other);
|
|
|
|
return *this;
|
2021-09-06 18:22:24 +02:00
|
|
|
}
|
|
|
|
|
2021-09-28 10:17:49 +02:00
|
|
|
InstanceReference &operator=(InstanceReference &&other)
|
|
|
|
{
|
|
|
|
if (this == &other) {
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
this->~InstanceReference();
|
|
|
|
new (this) InstanceReference(std::move(other));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2021-05-04 10:16:24 +02:00
|
|
|
Type type() const
|
|
|
|
{
|
|
|
|
return type_;
|
|
|
|
}
|
|
|
|
|
|
|
|
Object &object() const
|
|
|
|
{
|
|
|
|
BLI_assert(type_ == Type::Object);
|
|
|
|
return *(Object *)data_;
|
|
|
|
}
|
|
|
|
|
|
|
|
Collection &collection() const
|
|
|
|
{
|
|
|
|
BLI_assert(type_ == Type::Collection);
|
|
|
|
return *(Collection *)data_;
|
|
|
|
}
|
|
|
|
|
2021-09-06 18:22:24 +02:00
|
|
|
const GeometrySet &geometry_set() const
|
|
|
|
{
|
|
|
|
BLI_assert(type_ == Type::GeometrySet);
|
|
|
|
return *geometry_set_;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool owns_direct_data() const
|
|
|
|
{
|
|
|
|
if (type_ != Type::GeometrySet) {
|
|
|
|
/* The object and collection instances are not direct data. */
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return geometry_set_->owns_direct_data();
|
|
|
|
}
|
|
|
|
|
|
|
|
void ensure_owns_direct_data()
|
|
|
|
{
|
|
|
|
if (type_ != Type::GeometrySet) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
geometry_set_->ensure_owns_direct_data();
|
|
|
|
}
|
|
|
|
|
2021-05-04 10:16:24 +02:00
|
|
|
uint64_t hash() const
|
|
|
|
{
|
2021-09-06 18:22:24 +02:00
|
|
|
return blender::get_default_hash_2(data_, geometry_set_.get());
|
2021-05-04 10:16:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
friend bool operator==(const InstanceReference &a, const InstanceReference &b)
|
|
|
|
{
|
2021-09-06 18:22:24 +02:00
|
|
|
return a.data_ == b.data_ && a.geometry_set_.get() == b.geometry_set_.get();
|
2021-05-04 10:16:24 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* A geometry component that stores instances. The instance data can be any type described by
|
|
|
|
* #InstanceReference. Geometry instances can even contain instances themselves, for nested
|
|
|
|
* instancing. Each instance has an index into an array of unique instance data, and a transform.
|
|
|
|
* The component can also store generic attributes for each instance.
|
|
|
|
*
|
|
|
|
* The component works differently from other geometry components in that it stores
|
|
|
|
* data about instancing directly, rather than owning a pointer to a separate data structure.
|
|
|
|
*
|
|
|
|
* This component is not responsible for handling the interface to a render engine, or other
|
|
|
|
* areas that work with all visible geometry, that is handled by the dependency graph iterator
|
|
|
|
* (see `DEG_depsgraph_query.h`).
|
|
|
|
*/
|
2020-12-02 13:25:25 +01:00
|
|
|
class InstancesComponent : public GeometryComponent {
|
|
|
|
private:
|
2021-05-04 10:16:24 +02:00
|
|
|
/**
|
|
|
|
* Indexed set containing information about the data that is instanced.
|
|
|
|
* Actual instances store an index ("handle") into this set.
|
|
|
|
*/
|
|
|
|
blender::VectorSet<InstanceReference> references_;
|
|
|
|
|
|
|
|
/** Index into `references_`. Determines what data is instanced. */
|
|
|
|
blender::Vector<int> instance_reference_handles_;
|
|
|
|
/** Transformation of the instances. */
|
|
|
|
blender::Vector<blender::float4x4> instance_transforms_;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/* These almost unique ids are generated based on the `id` attribute, which might not contain
|
|
|
|
* unique ids at all. They are *almost* unique, because under certain very unlikely
|
|
|
|
* circumstances, they are not unique. Code using these ids should not crash when they are not
|
|
|
|
* unique but can generally expect them to be unique. */
|
2021-02-12 17:41:28 +01:00
|
|
|
mutable std::mutex almost_unique_ids_mutex_;
|
|
|
|
mutable blender::Array<int> almost_unique_ids_;
|
|
|
|
|
2021-11-19 17:53:48 +01:00
|
|
|
blender::bke::CustomDataAttributes attributes_;
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
public:
|
|
|
|
InstancesComponent();
|
|
|
|
~InstancesComponent() = default;
|
|
|
|
GeometryComponent *copy() const override;
|
|
|
|
|
|
|
|
void clear();
|
2021-05-04 10:16:24 +02:00
|
|
|
|
|
|
|
void reserve(int min_capacity);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2021-12-07 19:04:32 +01:00
|
|
|
* Resize the transform, handles, and attributes to the specified capacity.
|
2021-12-07 07:19:15 +01:00
|
|
|
*
|
|
|
|
* \note This function should be used carefully, only when it's guaranteed
|
|
|
|
* that the data will be filled.
|
|
|
|
*/
|
2021-05-09 06:57:36 +02:00
|
|
|
void resize(int capacity);
|
2021-05-04 10:16:24 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns a handle for the given reference.
|
|
|
|
* If the reference exists already, the handle of the existing reference is returned.
|
|
|
|
* Otherwise a new handle is added.
|
|
|
|
*/
|
2021-09-06 18:22:24 +02:00
|
|
|
int add_reference(const InstanceReference &reference);
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* Add a reference to the instance reference with an index specified by the #instance_handle
|
|
|
|
* argument. For adding many instances, using #resize and accessing the transform array directly
|
|
|
|
* is preferred.
|
|
|
|
*/
|
2021-10-26 19:50:39 +02:00
|
|
|
void add_instance(int instance_handle, const blender::float4x4 &transform);
|
2021-05-04 10:16:24 +02:00
|
|
|
|
|
|
|
blender::Span<InstanceReference> references() const;
|
2021-09-27 10:16:38 +02:00
|
|
|
void remove_unused_references();
|
2021-05-04 10:16:24 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* If references have a collection or object type, convert them into geometry instances
|
|
|
|
* recursively. After that, the geometry sets can be edited. There may still be instances of
|
|
|
|
* other types of they can't be converted to geometry sets.
|
|
|
|
*/
|
2021-09-21 21:20:54 +02:00
|
|
|
void ensure_geometry_instances();
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* With write access to the instances component, the data in the instanced geometry sets can be
|
|
|
|
* changed. This is a function on the component rather than each reference to ensure `const`
|
|
|
|
* correctness for that reason.
|
|
|
|
*/
|
2021-09-21 21:20:54 +02:00
|
|
|
GeometrySet &geometry_set_from_reference(const int reference_index);
|
|
|
|
|
2021-05-04 10:16:24 +02:00
|
|
|
blender::Span<int> instance_reference_handles() const;
|
2021-05-09 06:57:36 +02:00
|
|
|
blender::MutableSpan<int> instance_reference_handles();
|
2021-05-04 10:16:24 +02:00
|
|
|
blender::MutableSpan<blender::float4x4> instance_transforms();
|
|
|
|
blender::Span<blender::float4x4> instance_transforms() const;
|
2021-10-26 19:50:39 +02:00
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
int instances_amount() const;
|
2021-09-21 21:20:54 +02:00
|
|
|
int references_amount() const;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-12-29 18:31:58 +01:00
|
|
|
/**
|
2022-01-03 20:19:04 +01:00
|
|
|
* Remove the indices that are not contained in the mask input, and remove unused instance
|
|
|
|
* references afterwards.
|
2021-12-29 18:31:58 +01:00
|
|
|
*/
|
2022-01-03 20:19:04 +01:00
|
|
|
void remove_instances(const blender::IndexMask mask);
|
2021-12-29 18:31:58 +01:00
|
|
|
|
2021-02-12 17:41:28 +01:00
|
|
|
blender::Span<int> almost_unique_ids() const;
|
|
|
|
|
2021-11-19 17:53:48 +01:00
|
|
|
blender::bke::CustomDataAttributes &attributes();
|
|
|
|
const blender::bke::CustomDataAttributes &attributes() const;
|
|
|
|
|
2021-09-20 12:49:11 +02:00
|
|
|
int attribute_domain_size(const AttributeDomain domain) const final;
|
|
|
|
|
2021-09-23 17:50:33 +02:00
|
|
|
void foreach_referenced_geometry(
|
|
|
|
blender::FunctionRef<void(const GeometrySet &geometry_set)> callback) const;
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
bool is_empty() const final;
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
bool owns_direct_data() const override;
|
|
|
|
void ensure_owns_direct_data() override;
|
|
|
|
|
2021-03-10 11:53:17 +01:00
|
|
|
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_INSTANCES;
|
2021-09-20 12:49:11 +02:00
|
|
|
|
|
|
|
private:
|
|
|
|
const blender::bke::ComponentAttributeProviders *get_attribute_providers() const final;
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
2021-01-21 10:32:42 +01:00
|
|
|
|
2021-12-07 19:04:32 +01:00
|
|
|
/**
|
|
|
|
* A geometry component that stores volume grids, corresponding to the #Volume data structure.
|
|
|
|
* This component does not implement an attribute API, partly because storage of sparse volume
|
|
|
|
* information in grids is much more complicated than it is for other types
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
class VolumeComponent : public GeometryComponent {
|
|
|
|
private:
|
|
|
|
Volume *volume_ = nullptr;
|
|
|
|
GeometryOwnershipType ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
|
|
|
public:
|
|
|
|
VolumeComponent();
|
|
|
|
~VolumeComponent();
|
|
|
|
GeometryComponent *copy() const override;
|
|
|
|
|
|
|
|
void clear();
|
|
|
|
bool has_volume() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Clear the component and replace it with the new volume.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
void replace(Volume *volume, GeometryOwnershipType ownership = GeometryOwnershipType::Owned);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Return the volume and clear the component. The caller takes over responsibility for freeing
|
|
|
|
* the volume (if the component was responsible before).
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
Volume *release();
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the volume from this component. This method can be used by multiple threads at the same
|
|
|
|
* time. Therefore, the returned volume should not be modified. No ownership is transferred.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
const Volume *get_for_read() const;
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the volume from this component. This method can only be used when the component is
|
|
|
|
* mutable, i.e. it is not shared. The returned volume can be modified. No ownership is
|
|
|
|
* transferred.
|
|
|
|
*/
|
2021-01-21 10:32:42 +01:00
|
|
|
Volume *get_for_write();
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
bool owns_direct_data() const override;
|
|
|
|
void ensure_owns_direct_data() override;
|
|
|
|
|
2021-03-10 11:53:17 +01:00
|
|
|
static constexpr inline GeometryComponentType static_type = GEO_COMPONENT_TYPE_VOLUME;
|
2021-01-21 10:32:42 +01:00
|
|
|
};
|
2021-09-09 12:54:20 +02:00
|
|
|
|
|
|
|
namespace blender::bke {
|
|
|
|
|
|
|
|
class GeometryComponentFieldContext : public fn::FieldContext {
|
|
|
|
private:
|
|
|
|
const GeometryComponent &component_;
|
|
|
|
const AttributeDomain domain_;
|
|
|
|
|
|
|
|
public:
|
|
|
|
GeometryComponentFieldContext(const GeometryComponent &component, const AttributeDomain domain)
|
|
|
|
: component_(component), domain_(domain)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
const GeometryComponent &geometry_component() const
|
|
|
|
{
|
|
|
|
return component_;
|
|
|
|
}
|
|
|
|
|
|
|
|
AttributeDomain domain() const
|
|
|
|
{
|
|
|
|
return domain_;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
class GeometryFieldInput : public fn::FieldInput {
|
|
|
|
public:
|
|
|
|
using fn::FieldInput::FieldInput;
|
|
|
|
|
|
|
|
GVArray get_varray_for_context(const fn::FieldContext &context,
|
|
|
|
IndexMask mask,
|
|
|
|
ResourceScope &scope) const override;
|
|
|
|
|
|
|
|
virtual GVArray get_varray_for_context(const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
IndexMask mask) const = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
class AttributeFieldInput : public GeometryFieldInput {
|
2021-09-09 12:54:20 +02:00
|
|
|
private:
|
|
|
|
std::string name_;
|
|
|
|
|
|
|
|
public:
|
|
|
|
AttributeFieldInput(std::string name, const CPPType &type)
|
2021-12-06 19:05:29 +01:00
|
|
|
: GeometryFieldInput(type, name), name_(std::move(name))
|
2021-09-09 12:54:20 +02:00
|
|
|
{
|
2021-10-26 15:32:01 +02:00
|
|
|
category_ = Category::NamedAttribute;
|
2021-09-09 12:54:20 +02:00
|
|
|
}
|
|
|
|
|
2021-09-29 06:19:33 +02:00
|
|
|
template<typename T> static fn::Field<T> Create(std::string name)
|
|
|
|
{
|
|
|
|
const CPPType &type = CPPType::get<T>();
|
|
|
|
auto field_input = std::make_shared<AttributeFieldInput>(std::move(name), type);
|
|
|
|
return fn::Field<T>{field_input};
|
|
|
|
}
|
|
|
|
|
2021-09-11 13:05:20 +02:00
|
|
|
StringRefNull attribute_name() const
|
|
|
|
{
|
|
|
|
return name_;
|
|
|
|
}
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
GVArray get_varray_for_context(const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
IndexMask mask) const override;
|
2021-09-09 12:54:20 +02:00
|
|
|
|
2021-09-11 13:05:20 +02:00
|
|
|
std::string socket_inspection_name() const override;
|
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
uint64_t hash() const override;
|
|
|
|
bool is_equal_to(const fn::FieldNode &other) const override;
|
|
|
|
};
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
class IDAttributeFieldInput : public GeometryFieldInput {
|
2021-10-20 17:54:54 +02:00
|
|
|
public:
|
2021-12-06 19:05:29 +01:00
|
|
|
IDAttributeFieldInput() : GeometryFieldInput(CPPType::get<int>())
|
2021-10-20 17:54:54 +02:00
|
|
|
{
|
2021-10-26 15:32:01 +02:00
|
|
|
category_ = Category::Generated;
|
2021-10-20 17:54:54 +02:00
|
|
|
}
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
GVArray get_varray_for_context(const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
IndexMask mask) const override;
|
2021-10-20 17:54:54 +02:00
|
|
|
|
|
|
|
std::string socket_inspection_name() const override;
|
|
|
|
|
|
|
|
uint64_t hash() const override;
|
|
|
|
bool is_equal_to(const fn::FieldNode &other) const override;
|
|
|
|
};
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
class AnonymousAttributeFieldInput : public GeometryFieldInput {
|
2021-09-09 12:54:20 +02:00
|
|
|
private:
|
|
|
|
/**
|
|
|
|
* A strong reference is required to make sure that the referenced attribute is not removed
|
|
|
|
* automatically.
|
|
|
|
*/
|
|
|
|
StrongAnonymousAttributeID anonymous_id_;
|
2021-10-26 15:32:01 +02:00
|
|
|
std::string producer_name_;
|
2021-09-09 12:54:20 +02:00
|
|
|
|
|
|
|
public:
|
2021-10-26 15:32:01 +02:00
|
|
|
AnonymousAttributeFieldInput(StrongAnonymousAttributeID anonymous_id,
|
|
|
|
const CPPType &type,
|
|
|
|
std::string producer_name)
|
2021-12-06 19:05:29 +01:00
|
|
|
: GeometryFieldInput(type, anonymous_id.debug_name()),
|
2021-10-26 15:32:01 +02:00
|
|
|
anonymous_id_(std::move(anonymous_id)),
|
|
|
|
producer_name_(producer_name)
|
2021-09-09 12:54:20 +02:00
|
|
|
{
|
2021-10-26 15:32:01 +02:00
|
|
|
category_ = Category::AnonymousAttribute;
|
2021-09-09 12:54:20 +02:00
|
|
|
}
|
|
|
|
|
2021-10-26 15:32:01 +02:00
|
|
|
template<typename T>
|
|
|
|
static fn::Field<T> Create(StrongAnonymousAttributeID anonymous_id, std::string producer_name)
|
2021-09-24 11:50:02 +02:00
|
|
|
{
|
|
|
|
const CPPType &type = CPPType::get<T>();
|
2021-10-26 15:32:01 +02:00
|
|
|
auto field_input = std::make_shared<AnonymousAttributeFieldInput>(
|
|
|
|
std::move(anonymous_id), type, std::move(producer_name));
|
2021-09-24 11:50:02 +02:00
|
|
|
return fn::Field<T>{field_input};
|
|
|
|
}
|
|
|
|
|
2021-12-06 19:05:29 +01:00
|
|
|
GVArray get_varray_for_context(const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
IndexMask mask) const override;
|
2021-09-09 12:54:20 +02:00
|
|
|
|
2021-09-11 13:05:20 +02:00
|
|
|
std::string socket_inspection_name() const override;
|
|
|
|
|
2021-09-09 12:54:20 +02:00
|
|
|
uint64_t hash() const override;
|
|
|
|
bool is_equal_to(const fn::FieldNode &other) const override;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace blender::bke
|