2023-08-15 16:20:26 +02:00
|
|
|
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2021-04-15 09:35:56 +02:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
2022-04-21 16:11:26 +02:00
|
|
|
#include "FN_field.hh"
|
2021-04-15 09:35:56 +02:00
|
|
|
#include "FN_multi_function.hh"
|
|
|
|
|
2021-12-07 15:21:59 +01:00
|
|
|
namespace blender::bke {
|
2021-04-15 09:35:56 +02:00
|
|
|
|
2021-04-15 11:21:35 +02:00
|
|
|
struct ConversionFunctions {
|
2023-01-07 17:32:28 +01:00
|
|
|
const mf::MultiFunction *multi_function;
|
2021-04-15 11:21:35 +02:00
|
|
|
void (*convert_single_to_initialized)(const void *src, void *dst);
|
|
|
|
void (*convert_single_to_uninitialized)(const void *src, void *dst);
|
|
|
|
};
|
2021-04-15 09:35:56 +02:00
|
|
|
|
|
|
|
class DataTypeConversions {
|
|
|
|
private:
|
2023-01-07 17:32:28 +01:00
|
|
|
Map<std::pair<mf::DataType, mf::DataType>, ConversionFunctions> conversions_;
|
2021-04-15 09:35:56 +02:00
|
|
|
|
|
|
|
public:
|
2023-01-07 17:32:28 +01:00
|
|
|
void add(mf::DataType from_type,
|
|
|
|
mf::DataType to_type,
|
|
|
|
const mf::MultiFunction &fn,
|
2021-04-15 11:21:35 +02:00
|
|
|
void (*convert_single_to_initialized)(const void *src, void *dst),
|
|
|
|
void (*convert_single_to_uninitialized)(const void *src, void *dst))
|
|
|
|
{
|
|
|
|
conversions_.add_new({from_type, to_type},
|
|
|
|
{&fn, convert_single_to_initialized, convert_single_to_uninitialized});
|
|
|
|
}
|
|
|
|
|
2023-01-07 17:32:28 +01:00
|
|
|
const ConversionFunctions *get_conversion_functions(mf::DataType from, mf::DataType to) const
|
2021-04-15 11:21:35 +02:00
|
|
|
{
|
|
|
|
return conversions_.lookup_ptr({from, to});
|
|
|
|
}
|
|
|
|
|
|
|
|
const ConversionFunctions *get_conversion_functions(const CPPType &from, const CPPType &to) const
|
2021-04-15 09:35:56 +02:00
|
|
|
{
|
2023-01-07 17:32:28 +01:00
|
|
|
return this->get_conversion_functions(mf::DataType::ForSingle(from),
|
|
|
|
mf::DataType::ForSingle(to));
|
2021-04-15 09:35:56 +02:00
|
|
|
}
|
|
|
|
|
2023-01-07 17:32:28 +01:00
|
|
|
const mf::MultiFunction *get_conversion_multi_function(mf::DataType from, mf::DataType to) const
|
2021-04-15 09:35:56 +02:00
|
|
|
{
|
2021-04-15 11:21:35 +02:00
|
|
|
const ConversionFunctions *functions = this->get_conversion_functions(from, to);
|
|
|
|
return functions ? functions->multi_function : nullptr;
|
2021-04-15 09:35:56 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool is_convertible(const CPPType &from_type, const CPPType &to_type) const
|
|
|
|
{
|
|
|
|
return conversions_.contains(
|
2023-01-07 17:32:28 +01:00
|
|
|
{mf::DataType::ForSingle(from_type), mf::DataType::ForSingle(to_type)});
|
2021-04-15 09:35:56 +02:00
|
|
|
}
|
|
|
|
|
2021-04-15 11:21:35 +02:00
|
|
|
void convert_to_uninitialized(const CPPType &from_type,
|
|
|
|
const CPPType &to_type,
|
|
|
|
const void *from_value,
|
|
|
|
void *to_value) const;
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
|
2022-03-19 08:26:29 +01:00
|
|
|
void convert_to_initialized_n(GSpan from_span, GMutableSpan to_span) const;
|
Geometry Nodes: support instance attributes when realizing instances
This patch refactors the instance-realization code and adds new functionality.
* Named and anonymous attributes are propagated from instances to the
realized geometry. If the same attribute exists on the geometry and on an
instance, the attribute on the geometry has precedence.
* The id attribute has special handling to avoid creating the same id on many
output points. This is necessary to make e.g. the Random Value node work
as expected afterwards.
Realizing instance attributes has an effect on existing files, especially due to the
id attribute. To avoid breaking existing files, the Realize Instances node now has
a legacy option that is enabled for all already existing Realize Instances nodes.
Removing this legacy behavior does affect some existing files (although not many).
We can decide whether it's worth to remove the old behavior as a separate step.
This refactor also improves performance when realizing instances. That is mainly
due to multi-threading. See D13446 to get the file used for benchmarking. The
curve code is not as optimized as it could be yet. That's mainly because the storage
for these attributes might change soonish and it wasn't worth optimizing for the
current storage format right now.
```
1,000,000 x mesh vertex: 530 ms -> 130 ms
1,000,000 x simple cube: 1290 ms -> 190 ms
1,000,000 x point: 1000 ms -> 150 ms
1,000,000 x curve spiral: 1740 ms -> 330 ms
1,000,000 x curve line: 1110 ms -> 210 ms
10,000 x subdivided cylinder: 170 ms -> 40 ms
10 x subdivided spiral: 180 ms -> 180 ms
```
Differential Revision: https://developer.blender.org/D13446
2021-12-14 15:57:58 +01:00
|
|
|
|
2022-03-19 08:26:29 +01:00
|
|
|
GVArray try_convert(GVArray varray, const CPPType &to_type) const;
|
|
|
|
GVMutableArray try_convert(GVMutableArray varray, const CPPType &to_type) const;
|
2022-04-21 16:11:26 +02:00
|
|
|
fn::GField try_convert(fn::GField field, const CPPType &to_type) const;
|
2021-04-15 09:35:56 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
const DataTypeConversions &get_implicit_type_conversions();
|
|
|
|
|
2021-12-07 15:21:59 +01:00
|
|
|
} // namespace blender::bke
|