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 "DEG_depsgraph_query.h"
|
|
|
|
|
|
2021-12-07 15:21:59 +01:00
|
|
|
#include "BKE_type_conversions.hh"
|
|
|
|
|
|
2020-12-02 13:25:25 +01:00
|
|
|
#include "NOD_geometry_exec.hh"
|
|
|
|
|
|
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"
|
|
|
|
|
|
2021-07-07 11:20:19 +02:00
|
|
|
using blender::nodes::geometry_nodes_eval_log::LocalGeoLogger;
|
|
|
|
|
|
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-07-12 14:29:28 +02:00
|
|
|
if (provider_->logger == nullptr) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2021-07-07 11:20:19 +02:00
|
|
|
LocalGeoLogger &local_logger = provider_->logger->local();
|
|
|
|
|
local_logger.log_node_warning(provider_->dnode, type, std::move(message));
|
2021-02-16 17:15:08 -06:00
|
|
|
}
|
|
|
|
|
|
2021-10-26 20:00:03 +02:00
|
|
|
void GeoNodeExecParams::check_input_geometry_set(StringRef identifier,
|
|
|
|
|
const GeometrySet &geometry_set) const
|
|
|
|
|
{
|
2021-11-08 12:23:50 +01:00
|
|
|
const SocketDeclaration &decl =
|
|
|
|
|
*provider_->dnode->input_by_identifier(identifier).bsocket()->declaration;
|
2021-10-26 20:00:03 +02:00
|
|
|
const decl::Geometry *geo_decl = dynamic_cast<const decl::Geometry *>(&decl);
|
|
|
|
|
if (geo_decl == nullptr) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const bool only_realized_data = geo_decl->only_realized_data();
|
|
|
|
|
const bool only_instances = geo_decl->only_instances();
|
|
|
|
|
const Span<GeometryComponentType> supported_types = geo_decl->supported_types();
|
|
|
|
|
|
|
|
|
|
if (only_realized_data) {
|
|
|
|
|
if (geometry_set.has_instances()) {
|
2021-10-27 15:31:00 +02:00
|
|
|
this->error_message_add(NodeWarningType::Info,
|
|
|
|
|
TIP_("Instances in input geometry are ignored"));
|
2021-10-26 20:00:03 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (only_instances) {
|
|
|
|
|
if (geometry_set.has_realized_data()) {
|
|
|
|
|
this->error_message_add(NodeWarningType::Info,
|
2021-10-27 15:31:00 +02:00
|
|
|
TIP_("Realized data in input geometry is ignored"));
|
2021-10-26 20:00:03 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (supported_types.is_empty()) {
|
|
|
|
|
/* Assume all types are supported. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
const Vector<GeometryComponentType> types_in_geometry = geometry_set.gather_component_types(
|
|
|
|
|
true, true);
|
|
|
|
|
for (const GeometryComponentType type : types_in_geometry) {
|
|
|
|
|
if (type == GEO_COMPONENT_TYPE_INSTANCES) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
if (supported_types.contains(type)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
std::string message = TIP_("Input geometry has unsupported type: ");
|
|
|
|
|
switch (type) {
|
|
|
|
|
case GEO_COMPONENT_TYPE_MESH: {
|
|
|
|
|
message += TIP_("Mesh");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case GEO_COMPONENT_TYPE_POINT_CLOUD: {
|
|
|
|
|
message += TIP_("Point Cloud");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case GEO_COMPONENT_TYPE_INSTANCES: {
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case GEO_COMPONENT_TYPE_VOLUME: {
|
|
|
|
|
message += TIP_("Volume");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case GEO_COMPONENT_TYPE_CURVE: {
|
|
|
|
|
message += TIP_("Curve");
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
this->error_message_add(NodeWarningType::Info, std::move(message));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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: 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
|
|
|
GVArray 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: 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 GVArray::ForSingle(*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: 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
|
|
|
GVArray 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: 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 GVArray::ForSingle(*cpp_type, domain_size, default_value);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
2021-12-07 15:21:59 +01:00
|
|
|
const bke::DataTypeConversions &conversions = bke::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);
|
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 GVArray::ForSingle(*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);
|
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 GVArray::ForSingle(*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);
|
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 GVArray::ForSingle(*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: 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 GVArray::ForSingle(*cpp_type, domain_size, buffer);
|
2020-12-09 16:20:48 +01:00
|
|
|
}
|
|
|
|
|
BLI_assert(false);
|
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 GVArray::ForSingle(*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
|
|
|
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-10-26 15:32:01 +02:00
|
|
|
std::string GeoNodeExecParams::attribute_producer_name() const
|
|
|
|
|
{
|
|
|
|
|
return provider_->dnode->label_or_name() + TIP_(" node");
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-26 18:00:52 +01:00
|
|
|
void GeoNodeExecParams::set_default_remaining_outputs()
|
|
|
|
|
{
|
|
|
|
|
provider_->set_default_remaining_outputs();
|
|
|
|
|
}
|
|
|
|
|
|
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) {
|
2021-11-22 10:18:08 +01:00
|
|
|
const CPPType &expected_type = *found_socket->typeinfo->geometry_nodes_cpp_type;
|
2020-12-02 13:25:25 +01:00
|
|
|
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 {
|
2021-11-22 10:18:08 +01:00
|
|
|
const CPPType &expected_type = *found_socket->typeinfo->geometry_nodes_cpp_type;
|
2020-12-02 13:25:25 +01:00
|
|
|
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
|