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.
|
|
|
|
*/
|
|
|
|
|
2021-02-16 17:15:08 -06:00
|
|
|
#include "DNA_modifier_types.h"
|
|
|
|
|
|
|
|
#include "BKE_node_ui_storage.hh"
|
|
|
|
|
|
|
|
#include "DEG_depsgraph_query.h"
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "NOD_geometry_exec.hh"
|
|
|
|
#include "NOD_type_callbacks.hh"
|
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
|
|
|
#include "NOD_type_conversions.hh"
|
2020-12-02 13:25:25 +01:00
|
|
|
|
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
|
|
|
#include "node_geometry_util.hh"
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
namespace blender::nodes {
|
|
|
|
|
2021-02-16 17:15:08 -06:00
|
|
|
void GeoNodeExecParams::error_message_add(const NodeWarningType type, std::string message) const
|
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
bNodeTree *btree_cow = provider_->dnode->btree();
|
2021-02-16 17:15:08 -06:00
|
|
|
BLI_assert(btree_cow != nullptr);
|
|
|
|
if (btree_cow == nullptr) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
bNodeTree *btree_original = (bNodeTree *)DEG_get_original_id((ID *)btree_cow);
|
|
|
|
|
2021-04-27 13:03:40 +02:00
|
|
|
const NodeTreeEvaluationContext context(*provider_->self_object, *provider_->modifier);
|
2021-02-16 17:15:08 -06:00
|
|
|
|
|
|
|
BKE_nodetree_error_message_add(
|
2021-04-27 13:03:40 +02:00
|
|
|
*btree_original, context, *provider_->dnode->bnode(), type, std::move(message));
|
2021-02-16 17:15:08 -06:00
|
|
|
}
|
|
|
|
|
2020-12-14 11:43:46 -06:00
|
|
|
const bNodeSocket *GeoNodeExecParams::find_available_socket(const StringRef name) const
|
2020-12-09 16:20:48 +01:00
|
|
|
{
|
2021-04-27 13:03:40 +02:00
|
|
|
for (const InputSocketRef *socket : provider_->dnode->inputs()) {
|
2021-02-16 13:06:18 -06:00
|
|
|
if (socket->is_available() && socket->name() == name) {
|
|
|
|
return socket->bsocket();
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
}
|
2020-12-14 11:43:46 -06:00
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
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 GeoNodeExecParams::get_input_attribute(const StringRef name,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const AttributeDomain domain,
|
|
|
|
const CustomDataType type,
|
|
|
|
const void *default_value) const
|
2020-12-14 11:43:46 -06:00
|
|
|
{
|
|
|
|
const bNodeSocket *found_socket = this->find_available_socket(name);
|
|
|
|
BLI_assert(found_socket != nullptr); /* There should always be available socket for the name. */
|
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 CPPType *cpp_type = bke::custom_data_type_to_cpp_type(type);
|
|
|
|
const int64_t domain_size = component.attribute_domain_size(domain);
|
|
|
|
|
|
|
|
if (default_value == nullptr) {
|
|
|
|
default_value = cpp_type->default_value();
|
|
|
|
}
|
|
|
|
|
2020-12-14 11:43:46 -06:00
|
|
|
if (found_socket == nullptr) {
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, default_value);
|
2020-12-14 11:43:46 -06:00
|
|
|
}
|
2020-12-09 16:20:48 +01:00
|
|
|
|
|
|
|
if (found_socket->type == SOCK_STRING) {
|
|
|
|
const std::string name = this->get_input<std::string>(found_socket->identifier);
|
2021-02-16 17:15:08 -06:00
|
|
|
/* Try getting the attribute without the default value. */
|
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 attribute = component.attribute_try_get_for_read(name, domain, type);
|
2021-02-16 17:15:08 -06:00
|
|
|
if (attribute) {
|
|
|
|
return attribute;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the attribute doesn't exist, use the default value and output an error message
|
2021-02-25 08:20:02 -06:00
|
|
|
* (except when the field is empty, to avoid spamming error messages, and not when
|
|
|
|
* the domain is empty and we don't expect an attribute anyway). */
|
|
|
|
if (!name.empty() && component.attribute_domain_size(domain) != 0) {
|
2021-02-16 17:15:08 -06:00
|
|
|
this->error_message_add(NodeWarningType::Error,
|
2021-03-03 12:58:33 -06:00
|
|
|
TIP_("No attribute with name \"") + name + "\"");
|
2021-02-16 17:15:08 -06:00
|
|
|
}
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, default_value);
|
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
|
|
|
const DataTypeConversions &conversions = get_implicit_type_conversions();
|
2020-12-09 16:20:48 +01:00
|
|
|
if (found_socket->type == SOCK_FLOAT) {
|
|
|
|
const float value = this->get_input<float>(found_socket->identifier);
|
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
|
|
|
BUFFER_FOR_CPP_TYPE_VALUE(*cpp_type, buffer);
|
|
|
|
conversions.convert_to_uninitialized(CPPType::get<float>(), *cpp_type, &value, buffer);
|
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, buffer);
|
2021-06-17 11:39:23 -05:00
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_INT) {
|
|
|
|
const int value = this->get_input<int>(found_socket->identifier);
|
|
|
|
BUFFER_FOR_CPP_TYPE_VALUE(*cpp_type, buffer);
|
|
|
|
conversions.convert_to_uninitialized(CPPType::get<int>(), *cpp_type, &value, buffer);
|
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, buffer);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_VECTOR) {
|
|
|
|
const float3 value = this->get_input<float3>(found_socket->identifier);
|
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
|
|
|
BUFFER_FOR_CPP_TYPE_VALUE(*cpp_type, buffer);
|
|
|
|
conversions.convert_to_uninitialized(CPPType::get<float3>(), *cpp_type, &value, buffer);
|
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, buffer);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_RGBA) {
|
2021-05-25 17:16:35 +02:00
|
|
|
const ColorGeometry4f value = this->get_input<ColorGeometry4f>(found_socket->identifier);
|
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
|
|
|
BUFFER_FOR_CPP_TYPE_VALUE(*cpp_type, buffer);
|
2021-05-25 17:16:35 +02:00
|
|
|
conversions.convert_to_uninitialized(
|
|
|
|
CPPType::get<ColorGeometry4f>(), *cpp_type, &value, buffer);
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, buffer);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
BLI_assert(false);
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
return std::make_unique<fn::GVArray_For_SingleValue>(*cpp_type, domain_size, default_value);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
|
2020-12-14 11:43:46 -06:00
|
|
|
CustomDataType GeoNodeExecParams::get_input_attribute_data_type(
|
|
|
|
const StringRef name,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const CustomDataType default_type) const
|
|
|
|
{
|
|
|
|
const bNodeSocket *found_socket = this->find_available_socket(name);
|
|
|
|
BLI_assert(found_socket != nullptr); /* There should always be available socket for the name. */
|
|
|
|
if (found_socket == nullptr) {
|
|
|
|
return default_type;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (found_socket->type == SOCK_STRING) {
|
|
|
|
const std::string name = this->get_input<std::string>(found_socket->identifier);
|
2021-04-22 08:05:02 -05:00
|
|
|
std::optional<AttributeMetaData> info = component.attribute_get_meta_data(name);
|
|
|
|
if (info) {
|
|
|
|
return info->data_type;
|
2020-12-14 11:43:46 -06:00
|
|
|
}
|
2021-04-22 08:05:02 -05:00
|
|
|
return default_type;
|
2020-12-14 11:43:46 -06:00
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_FLOAT) {
|
|
|
|
return CD_PROP_FLOAT;
|
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_VECTOR) {
|
|
|
|
return CD_PROP_FLOAT3;
|
|
|
|
}
|
|
|
|
if (found_socket->type == SOCK_RGBA) {
|
|
|
|
return CD_PROP_COLOR;
|
|
|
|
}
|
2020-12-16 12:50:45 -06:00
|
|
|
if (found_socket->type == SOCK_BOOLEAN) {
|
|
|
|
return CD_PROP_BOOL;
|
|
|
|
}
|
2020-12-14 11:43:46 -06:00
|
|
|
|
|
|
|
BLI_assert(false);
|
|
|
|
return default_type;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* If any of the corresponding input sockets are attributes instead of single values,
|
|
|
|
* use the highest priority attribute domain from among them.
|
|
|
|
* Otherwise return the default domain.
|
|
|
|
*/
|
|
|
|
AttributeDomain GeoNodeExecParams::get_highest_priority_input_domain(
|
|
|
|
Span<std::string> names,
|
|
|
|
const GeometryComponent &component,
|
|
|
|
const AttributeDomain default_domain) const
|
|
|
|
{
|
|
|
|
Vector<AttributeDomain, 8> input_domains;
|
|
|
|
for (const std::string &name : names) {
|
|
|
|
const bNodeSocket *found_socket = this->find_available_socket(name);
|
|
|
|
BLI_assert(found_socket != nullptr); /* A socket should be available socket for the name. */
|
|
|
|
if (found_socket == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (found_socket->type == SOCK_STRING) {
|
|
|
|
const std::string name = this->get_input<std::string>(found_socket->identifier);
|
2021-04-22 08:05:02 -05:00
|
|
|
std::optional<AttributeMetaData> info = component.attribute_get_meta_data(name);
|
|
|
|
if (info) {
|
|
|
|
input_domains.append(info->domain);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (input_domains.size() > 0) {
|
2021-02-16 11:55:00 +01:00
|
|
|
return bke::attribute_domain_highest_priority(input_domains);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
return default_domain;
|
|
|
|
}
|
|
|
|
|
2021-04-27 13:03:40 +02:00
|
|
|
void GeoNodeExecParams::check_input_access(StringRef identifier,
|
|
|
|
const CPPType *requested_type) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
bNodeSocket *found_socket = nullptr;
|
2021-04-27 13:03:40 +02:00
|
|
|
for (const InputSocketRef *socket : provider_->dnode->inputs()) {
|
2021-02-16 13:06:18 -06:00
|
|
|
if (socket->identifier() == identifier) {
|
|
|
|
found_socket = socket->bsocket();
|
2020-12-02 13:25:25 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2021-02-16 13:06:18 -06:00
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
if (found_socket == nullptr) {
|
|
|
|
std::cout << "Did not find an input socket with the identifier '" << identifier << "'.\n";
|
|
|
|
std::cout << "Possible identifiers are: ";
|
2021-04-27 13:03:40 +02:00
|
|
|
for (const InputSocketRef *socket : provider_->dnode->inputs()) {
|
2021-02-16 13:06:18 -06:00
|
|
|
if (socket->is_available()) {
|
|
|
|
std::cout << "'" << socket->identifier() << "', ";
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
std::cout << "\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
else if (found_socket->flag & SOCK_UNAVAIL) {
|
|
|
|
std::cout << "The socket corresponding to the identifier '" << identifier
|
|
|
|
<< "' is disabled.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
2021-04-27 13:03:40 +02:00
|
|
|
else if (!provider_->can_get_input(identifier)) {
|
2020-12-02 13:25:25 +01:00
|
|
|
std::cout << "The identifier '" << identifier
|
|
|
|
<< "' is valid, but there is no value for it anymore.\n";
|
|
|
|
std::cout << "Most likely it has been extracted before.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
else if (requested_type != nullptr) {
|
|
|
|
const CPPType &expected_type = *socket_cpp_type_get(*found_socket->typeinfo);
|
|
|
|
if (*requested_type != expected_type) {
|
|
|
|
std::cout << "The requested type '" << requested_type->name() << "' is incorrect. Expected '"
|
|
|
|
<< expected_type.name() << "'.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-27 13:03:40 +02:00
|
|
|
void GeoNodeExecParams::check_output_access(StringRef identifier, const CPPType &value_type) const
|
2020-12-02 13:25:25 +01:00
|
|
|
{
|
|
|
|
bNodeSocket *found_socket = nullptr;
|
2021-04-27 13:03:40 +02:00
|
|
|
for (const OutputSocketRef *socket : provider_->dnode->outputs()) {
|
2021-02-16 13:06:18 -06:00
|
|
|
if (socket->identifier() == identifier) {
|
|
|
|
found_socket = socket->bsocket();
|
2020-12-02 13:25:25 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2021-02-16 13:06:18 -06:00
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
if (found_socket == nullptr) {
|
|
|
|
std::cout << "Did not find an output socket with the identifier '" << identifier << "'.\n";
|
|
|
|
std::cout << "Possible identifiers are: ";
|
2021-04-27 13:03:40 +02:00
|
|
|
for (const OutputSocketRef *socket : provider_->dnode->outputs()) {
|
2021-02-16 13:06:18 -06:00
|
|
|
if (socket->is_available()) {
|
|
|
|
std::cout << "'" << socket->identifier() << "', ";
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
std::cout << "\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
else if (found_socket->flag & SOCK_UNAVAIL) {
|
|
|
|
std::cout << "The socket corresponding to the identifier '" << identifier
|
|
|
|
<< "' is disabled.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
2021-04-27 13:03:40 +02:00
|
|
|
else if (!provider_->can_set_output(identifier)) {
|
2020-12-02 13:25:25 +01:00
|
|
|
std::cout << "The identifier '" << identifier << "' has been set already.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
const CPPType &expected_type = *socket_cpp_type_get(*found_socket->typeinfo);
|
|
|
|
if (value_type != expected_type) {
|
|
|
|
std::cout << "The value type '" << value_type.name() << "' is incorrect. Expected '"
|
|
|
|
<< expected_type.name() << "'.\n";
|
2021-04-27 13:03:40 +02:00
|
|
|
BLI_assert_unreachable();
|
2020-12-02 13:25:25 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace blender::nodes
|