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
|
|
|
|
|
|
|
|
#include "FN_generic_value_map.hh"
|
|
|
|
|
|
|
|
#include "BKE_attribute_access.hh"
|
|
|
|
#include "BKE_geometry_set.hh"
|
2021-02-16 12:30:42 +01:00
|
|
|
#include "BKE_geometry_set_instances.hh"
|
2021-02-16 17:15:08 -06:00
|
|
|
#include "BKE_node_ui_storage.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
#include "DNA_node_types.h"
|
|
|
|
|
2021-02-16 13:06:18 -06:00
|
|
|
#include "NOD_derived_node_tree.hh"
|
|
|
|
|
2021-01-19 16:58:05 +01:00
|
|
|
struct Depsgraph;
|
2021-02-16 17:15:08 -06:00
|
|
|
struct ModifierData;
|
2021-01-19 16:58:05 +01:00
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
namespace blender::nodes {
|
|
|
|
|
2021-02-16 12:30:42 +01:00
|
|
|
using bke::geometry_set_realize_instances;
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
using bke::OutputAttribute;
|
|
|
|
using bke::OutputAttribute_Typed;
|
|
|
|
using bke::ReadAttributeLookup;
|
|
|
|
using bke::WriteAttributeLookup;
|
2020-12-02 13:25:25 +01:00
|
|
|
using fn::CPPType;
|
|
|
|
using fn::GMutablePointer;
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
using fn::GMutableSpan;
|
2020-12-18 13:28:43 +01:00
|
|
|
using fn::GPointer;
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
using fn::GSpan;
|
2020-12-02 13:25:25 +01:00
|
|
|
using fn::GValueMap;
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
using fn::GVArray;
|
|
|
|
using fn::GVArray_GSpan;
|
|
|
|
using fn::GVArray_Span;
|
|
|
|
using fn::GVArray_Typed;
|
|
|
|
using fn::GVArrayPtr;
|
|
|
|
using fn::GVMutableArray;
|
|
|
|
using fn::GVMutableArray_GSpan;
|
|
|
|
using fn::GVMutableArray_Typed;
|
|
|
|
using fn::GVMutableArrayPtr;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
2021-04-27 13:03:40 +02:00
|
|
|
/**
|
|
|
|
* This class exists to separate the memory management details of the geometry nodes evaluator from
|
|
|
|
* the node execution functions and related utilities.
|
|
|
|
*/
|
|
|
|
class GeoNodeExecParamsProvider {
|
|
|
|
public:
|
|
|
|
DNode dnode;
|
|
|
|
const Object *self_object = nullptr;
|
|
|
|
const ModifierData *modifier = nullptr;
|
|
|
|
Depsgraph *depsgraph = nullptr;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true when the node is allowed to get/extract the input value. The identifier is
|
|
|
|
* expected to be valid. This may return false if the input value has been consumed already.
|
|
|
|
*/
|
|
|
|
virtual bool can_get_input(StringRef identifier) const = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true when the node is allowed to set the output value. The identifier is expected to
|
|
|
|
* be valid. This may return false if the output value has been set already.
|
|
|
|
*/
|
|
|
|
virtual bool can_set_output(StringRef identifier) const = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Take ownership of an input value. The caller is responsible for destructing the value. It does
|
|
|
|
* not have to be freed, because the memory is managed by the geometry nodes evaluator.
|
|
|
|
*/
|
|
|
|
virtual GMutablePointer extract_input(StringRef identifier) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Similar to #extract_input, but has to be used for multi-input sockets.
|
|
|
|
*/
|
|
|
|
virtual Vector<GMutablePointer> extract_multi_input(StringRef identifier) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the input value for the identifier without taking ownership of it.
|
|
|
|
*/
|
|
|
|
virtual GPointer get_input(StringRef identifier) const = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Prepare a memory buffer for an output value of the node. The returned memory has to be
|
|
|
|
* initialized by the caller. The identifier and type are expected to be correct.
|
|
|
|
*/
|
2021-05-20 11:34:47 +02:00
|
|
|
virtual GMutablePointer alloc_output_value(const CPPType &type) = 0;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The value has been allocated with #alloc_output_value.
|
|
|
|
*/
|
|
|
|
virtual void set_output(StringRef identifier, GMutablePointer value) = 0;
|
|
|
|
|
|
|
|
/* A description for these methods is provided in GeoNodeExecParams. */
|
|
|
|
virtual void set_input_unused(StringRef identifier) = 0;
|
|
|
|
virtual bool output_is_required(StringRef identifier) const = 0;
|
|
|
|
virtual bool lazy_require_input(StringRef identifier) = 0;
|
|
|
|
virtual bool lazy_output_is_required(StringRef identifier) const = 0;
|
2021-04-27 13:03:40 +02:00
|
|
|
};
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
class GeoNodeExecParams {
|
|
|
|
private:
|
2021-04-27 13:03:40 +02:00
|
|
|
GeoNodeExecParamsProvider *provider_;
|
2020-12-02 13:25:25 +01:00
|
|
|
|
|
|
|
public:
|
2021-04-27 13:03:40 +02:00
|
|
|
GeoNodeExecParams(GeoNodeExecParamsProvider &provider) : provider_(&provider)
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the input value for the input socket with the given identifier.
|
|
|
|
*
|
|
|
|
* The node calling becomes responsible for destructing the value before it is done
|
|
|
|
* executing. This method can only be called once for each identifier.
|
|
|
|
*/
|
|
|
|
GMutablePointer extract_input(StringRef identifier)
|
|
|
|
{
|
|
|
|
#ifdef DEBUG
|
2021-04-27 13:03:40 +02:00
|
|
|
this->check_input_access(identifier);
|
2020-12-02 13:25:25 +01:00
|
|
|
#endif
|
2021-04-27 13:03:40 +02:00
|
|
|
return provider_->extract_input(identifier);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the input value for the input socket with the given identifier.
|
|
|
|
*
|
|
|
|
* This method can only be called once for each identifier.
|
|
|
|
*/
|
|
|
|
template<typename T> T extract_input(StringRef identifier)
|
|
|
|
{
|
|
|
|
#ifdef DEBUG
|
2021-04-27 13:03:40 +02:00
|
|
|
this->check_input_access(identifier, &CPPType::get<T>());
|
2020-12-02 13:25:25 +01:00
|
|
|
#endif
|
2021-04-27 13:03:40 +02:00
|
|
|
GMutablePointer gvalue = this->extract_input(identifier);
|
|
|
|
return gvalue.relocate_out<T>();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
2021-02-03 11:02:01 -06:00
|
|
|
/**
|
|
|
|
* Get input as vector for multi input socket with the given identifier.
|
|
|
|
*
|
|
|
|
* This method can only be called once for each identifier.
|
|
|
|
*/
|
|
|
|
template<typename T> Vector<T> extract_multi_input(StringRef identifier)
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
Vector<GMutablePointer> gvalues = provider_->extract_multi_input(identifier);
|
2021-02-03 11:02:01 -06:00
|
|
|
Vector<T> values;
|
2021-04-27 13:03:40 +02:00
|
|
|
for (GMutablePointer gvalue : gvalues) {
|
|
|
|
values.append(gvalue.relocate_out<T>());
|
2021-02-03 11:02:01 -06:00
|
|
|
}
|
|
|
|
return values;
|
|
|
|
}
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/**
|
|
|
|
* Get the input value for the input socket with the given identifier.
|
|
|
|
*/
|
2021-02-18 12:40:27 +01:00
|
|
|
template<typename T> const T &get_input(StringRef identifier) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
#ifdef DEBUG
|
2021-04-27 13:03:40 +02:00
|
|
|
this->check_input_access(identifier, &CPPType::get<T>());
|
2020-12-18 13:28:43 +01:00
|
|
|
#endif
|
2021-04-27 13:03:40 +02:00
|
|
|
GPointer gvalue = provider_->get_input(identifier);
|
|
|
|
BLI_assert(gvalue.is_type<T>());
|
|
|
|
return *(const T *)gvalue.get();
|
2020-12-18 13:28:43 +01:00
|
|
|
}
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
/**
|
|
|
|
* Store the output value for the given socket identifier.
|
|
|
|
*/
|
|
|
|
template<typename T> void set_output(StringRef identifier, T &&value)
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
using StoredT = std::decay_t<T>;
|
|
|
|
const CPPType &type = CPPType::get<std::decay_t<T>>();
|
2020-12-02 13:25:25 +01:00
|
|
|
#ifdef DEBUG
|
2021-04-27 13:03:40 +02:00
|
|
|
this->check_output_access(identifier, type);
|
2020-12-02 13:25:25 +01:00
|
|
|
#endif
|
2021-05-20 11:34:47 +02:00
|
|
|
GMutablePointer gvalue = provider_->alloc_output_value(type);
|
2021-04-27 13:03:40 +02:00
|
|
|
new (gvalue.get()) StoredT(std::forward<T>(value));
|
2021-05-20 11:34:47 +02:00
|
|
|
provider_->set_output(identifier, gvalue);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Tell the evaluator that a specific input won't be used anymore.
|
|
|
|
*/
|
|
|
|
void set_input_unused(StringRef identifier)
|
|
|
|
{
|
|
|
|
provider_->set_input_unused(identifier);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true when the output has to be computed.
|
2021-05-25 18:25:55 +10:00
|
|
|
* Nodes that support laziness could use the #lazy_output_is_required variant to possibly avoid
|
2021-05-20 11:34:47 +02:00
|
|
|
* some computations.
|
|
|
|
*/
|
|
|
|
bool output_is_required(StringRef identifier) const
|
|
|
|
{
|
|
|
|
return provider_->output_is_required(identifier);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Tell the evaluator that a specific input is required.
|
|
|
|
* This returns true when the input will only be available in the next execution.
|
|
|
|
* False is returned if the input is available already.
|
2021-05-25 18:25:55 +10:00
|
|
|
* This can only be used when the node supports laziness.
|
2021-05-20 11:34:47 +02:00
|
|
|
*/
|
|
|
|
bool lazy_require_input(StringRef identifier)
|
|
|
|
{
|
|
|
|
return provider_->lazy_require_input(identifier);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Asks the evaluator if a specific output is required right now. If this returns false, the
|
|
|
|
* value might still need to be computed later.
|
2021-05-25 18:25:55 +10:00
|
|
|
* This can only be used when the node supports laziness.
|
2021-05-20 11:34:47 +02:00
|
|
|
*/
|
|
|
|
bool lazy_output_is_required(StringRef identifier)
|
|
|
|
{
|
|
|
|
return provider_->lazy_output_is_required(identifier);
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the node that is currently being executed.
|
|
|
|
*/
|
|
|
|
const bNode &node() const
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
return *provider_->dnode->bnode();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
const Object *self_object() const
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
return provider_->self_object;
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
|
2021-01-19 16:58:05 +01:00
|
|
|
Depsgraph *depsgraph() const
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
return provider_->depsgraph;
|
2021-01-19 16:58:05 +01:00
|
|
|
}
|
|
|
|
|
2021-02-16 17:15:08 -06:00
|
|
|
/**
|
|
|
|
* Add an error message displayed at the top of the node when displaying the node tree,
|
|
|
|
* and potentially elsewhere in Blender.
|
|
|
|
*/
|
|
|
|
void error_message_add(const NodeWarningType type, std::string message) const;
|
|
|
|
|
2020-12-09 16:20:48 +01:00
|
|
|
/**
|
|
|
|
* Creates a read-only attribute based on node inputs. The method automatically detects which
|
2021-02-16 17:15:08 -06:00
|
|
|
* input socket with the given name is available.
|
|
|
|
*
|
|
|
|
* \note This will add an error message if the string socket is active and
|
|
|
|
* the input attribute does not exist.
|
2020-12-09 16:20:48 +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
|
|
|
GVArrayPtr get_input_attribute(const StringRef name,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType type,
|
|
|
|
const void *default_value) const;
|
2020-12-09 16:20:48 +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
|
|
|
GVArray_Typed<T> get_input_attribute(const StringRef name,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const T &default_value) const
|
2020-12-09 16:20:48 +01:00
|
|
|
{
|
|
|
|
const CustomDataType type = bke::cpp_type_to_custom_data_type(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
|
|
|
GVArrayPtr varray = this->get_input_attribute(name, component, domain, type, &default_value);
|
|
|
|
return GVArray_Typed<T>(std::move(varray));
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
|
2020-12-14 11:43:46 -06:00
|
|
|
/**
|
|
|
|
* Get the type of an input property or the associated constant socket types with the
|
|
|
|
* same names. Fall back to the default value if no attribute exists with the name.
|
|
|
|
*/
|
|
|
|
CustomDataType get_input_attribute_data_type(const StringRef name,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const CustomDataType default_type) const;
|
|
|
|
|
Geometry Nodes: Allow attribute nodes to use different domains
Currently every attribute node assumes that the attribute exists on the
"points" domain, so it generally isn't possible to work with attributes
on other domains like edges, polygons, and corners.
This commit adds a heuristic to each attribute node to determine the
correct domain for the result attribute. In general, it works like this:
- If the output attribute already exists, use that domain.
- Otherwise, use the highest priority domain of the input attributes.
- If none of the inputs are attributes, use the default domain (points).
For the implementation I abstracted the check a bit, but in each
node has a slightly different situation, so we end up with slightly
different `get_result_domain` functions in each node. I think this makes
sense, it keeps the code flexible and more easily understandable.
Note that we might eventually want to expose a domain drop-down to some
of the nodes. But that will be a separate discussion; this commit focuses
on making a more useful choice automatically.
Differential Revision: https://developer.blender.org/D10389
2021-02-12 12:46:17 -06:00
|
|
|
AttributeDomain get_highest_priority_input_domain(Span<std::string> names,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const AttributeDomain default_domain) const;
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
private:
|
|
|
|
/* Utilities for detecting common errors at when using this class. */
|
2021-04-27 13:03:40 +02:00
|
|
|
void check_input_access(StringRef identifier, const CPPType *requested_type = nullptr) const;
|
|
|
|
void check_output_access(StringRef identifier, const CPPType &value_type) const;
|
2020-12-14 11:43:46 -06:00
|
|
|
|
|
|
|
/* Find the active socket socket with the input name (not the identifier). */
|
|
|
|
const bNodeSocket *find_available_socket(const StringRef name) const;
|
2020-12-02 13:25:25 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace blender::nodes
|