2021-03-08 11:41:23 -05: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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "DNA_pointcloud_types.h"
|
|
|
|
|
|
|
|
|
|
#include "BKE_attribute_access.hh"
|
|
|
|
|
#include "BKE_geometry_set.hh"
|
|
|
|
|
#include "BKE_lib_id.h"
|
|
|
|
|
#include "BKE_pointcloud.h"
|
|
|
|
|
|
|
|
|
|
#include "attribute_access_intern.hh"
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Geometry Component Implementation
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2021-03-10 11:53:17 +01:00
|
|
|
PointCloudComponent::PointCloudComponent() : GeometryComponent(GEO_COMPONENT_TYPE_POINT_CLOUD)
|
2021-03-08 11:41:23 -05:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PointCloudComponent::~PointCloudComponent()
|
|
|
|
|
{
|
|
|
|
|
this->clear();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
GeometryComponent *PointCloudComponent::copy() const
|
|
|
|
|
{
|
|
|
|
|
PointCloudComponent *new_component = new PointCloudComponent();
|
|
|
|
|
if (pointcloud_ != nullptr) {
|
|
|
|
|
new_component->pointcloud_ = BKE_pointcloud_copy_for_eval(pointcloud_, false);
|
|
|
|
|
new_component->ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
}
|
|
|
|
|
return new_component;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void PointCloudComponent::clear()
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(this->is_mutable());
|
|
|
|
|
if (pointcloud_ != nullptr) {
|
|
|
|
|
if (ownership_ == GeometryOwnershipType::Owned) {
|
|
|
|
|
BKE_id_free(nullptr, pointcloud_);
|
|
|
|
|
}
|
|
|
|
|
pointcloud_ = nullptr;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool PointCloudComponent::has_pointcloud() const
|
|
|
|
|
{
|
|
|
|
|
return pointcloud_ != nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void PointCloudComponent::replace(PointCloud *pointcloud, GeometryOwnershipType ownership)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(this->is_mutable());
|
|
|
|
|
this->clear();
|
|
|
|
|
pointcloud_ = pointcloud;
|
|
|
|
|
ownership_ = ownership;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PointCloud *PointCloudComponent::release()
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(this->is_mutable());
|
|
|
|
|
PointCloud *pointcloud = pointcloud_;
|
|
|
|
|
pointcloud_ = nullptr;
|
|
|
|
|
return pointcloud;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const PointCloud *PointCloudComponent::get_for_read() const
|
|
|
|
|
{
|
|
|
|
|
return pointcloud_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PointCloud *PointCloudComponent::get_for_write()
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(this->is_mutable());
|
|
|
|
|
if (ownership_ == GeometryOwnershipType::ReadOnly) {
|
|
|
|
|
pointcloud_ = BKE_pointcloud_copy_for_eval(pointcloud_, false);
|
|
|
|
|
ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
}
|
|
|
|
|
return pointcloud_;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool PointCloudComponent::is_empty() const
|
|
|
|
|
{
|
|
|
|
|
return pointcloud_ == nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-08 17:35:06 +02:00
|
|
|
bool PointCloudComponent::owns_direct_data() const
|
|
|
|
|
{
|
|
|
|
|
return ownership_ == GeometryOwnershipType::Owned;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void PointCloudComponent::ensure_owns_direct_data()
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(this->is_mutable());
|
|
|
|
|
if (ownership_ != GeometryOwnershipType::Owned) {
|
|
|
|
|
pointcloud_ = BKE_pointcloud_copy_for_eval(pointcloud_, false);
|
|
|
|
|
ownership_ = GeometryOwnershipType::Owned;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-08 11:41:23 -05:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Attribute Access
|
|
|
|
|
* \{ */
|
|
|
|
|
|
|
|
|
|
int PointCloudComponent::attribute_domain_size(const AttributeDomain domain) const
|
|
|
|
|
{
|
|
|
|
|
if (pointcloud_ == nullptr) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2021-03-23 16:56:38 +01:00
|
|
|
if (domain != ATTR_DOMAIN_POINT) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2021-03-08 11:41:23 -05:00
|
|
|
return pointcloud_->totpoint;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
namespace blender::bke {
|
|
|
|
|
|
Geometry Nodes: use virtual arrays in internal attribute api
A virtual array is a data structure that is similar to a normal array
in that its elements can be accessed by an index. However, a virtual
array does not have to be a contiguous array internally. Instead, its
elements can be layed out arbitrarily while element access happens
through a virtual function call. However, the virtual array data
structures are designed so that the virtual function call can be avoided
in cases where it could become a bottleneck.
Most commonly, a virtual array is backed by an actual array/span or
is a single value internally, that is the same for every index.
Besides those, there are many more specialized virtual arrays like the
ones that provides vertex positions based on the `MVert` struct or
vertex group weights.
Not all attributes used by geometry nodes are stored in simple contiguous
arrays. To provide uniform access to all kinds of attributes, the attribute
API has to provide virtual array functionality that hides the implementation
details of attributes.
Before this refactor, the attribute API provided its own virtual array
implementation as part of the `ReadAttribute` and `WriteAttribute` types.
That resulted in unnecessary code duplication with the virtual array system.
Even worse, it bound many algorithms used by geometry nodes to the specifics
of the attribute API, even though they could also use different data sources
(such as data from sockets, default values, later results of expressions, ...).
This refactor removes the `ReadAttribute` and `WriteAttribute` types and
replaces them with `GVArray` and `GVMutableArray` respectively. The `GV`
stands for "generic virtual". The "generic" means that the data type contained
in those virtual arrays is only known at run-time. There are the corresponding
statically typed types `VArray<T>` and `VMutableArray<T>` as well.
No regressions are expected from this refactor. It does come with one
improvement for users. The attribute API can convert the data type
on write now. This is especially useful when writing to builtin attributes
like `material_index` with e.g. the Attribute Math node (which usually
just writes to float attributes, while `material_index` is an integer attribute).
Differential Revision: https://developer.blender.org/D10994
2021-04-17 16:41:03 +02:00
|
|
|
template<typename T>
|
Geometry Nodes: refactor virtual array system
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
|
|
|
static GVArray make_array_read_attribute(const void *data, const int domain_size)
|
2021-03-08 11:41:23 -05: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 VArray<T>::ForSpan(Span<T>((const T *)data, domain_size));
|
2021-03-08 11:41:23 -05: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
|
|
|
template<typename T>
|
Geometry Nodes: refactor virtual array system
Goals of this refactor:
* Simplify creating virtual arrays.
* Simplify passing virtual arrays around.
* Simplify converting between typed and generic virtual arrays.
* Reduce memory allocations.
As a quick reminder, a virtual arrays is a data structure that behaves like an
array (i.e. it can be accessed using an index). However, it may not actually
be stored as array internally. The two most important implementations
of virtual arrays are those that correspond to an actual plain array and those
that have the same value for every index. However, many more
implementations exist for various reasons (interfacing with legacy attributes,
unified iterator over all points in multiple splines, ...).
With this refactor the core types (`VArray`, `GVArray`, `VMutableArray` and
`GVMutableArray`) can be used like "normal values". They typically live
on the stack. Before, they were usually inside a `std::unique_ptr`. This makes
passing them around much easier. Creation of new virtual arrays is also
much simpler now due to some constructors. Memory allocations are
reduced by making use of small object optimization inside the core types.
Previously, `VArray` was a class with virtual methods that had to be overridden
to change the behavior of a the virtual array. Now,`VArray` has a fixed size
and has no virtual methods. Instead it contains a `VArrayImpl` that is
similar to the old `VArray`. `VArrayImpl` should rarely ever be used directly,
unless a new virtual array implementation is added.
To support the small object optimization for many `VArrayImpl` classes,
a new `blender::Any` type is added. It is similar to `std::any` with two
additional features. It has an adjustable inline buffer size and alignment.
The inline buffer size of `std::any` can't be relied on and is usually too
small for our use case here. Furthermore, `blender::Any` can store
additional user-defined type information without increasing the
stack size.
Differential Revision: https://developer.blender.org/D12986
2021-11-16 10:15:51 +01:00
|
|
|
static GVMutableArray make_array_write_attribute(void *data, const int domain_size)
|
2021-03-08 11:41:23 -05: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 VMutableArray<T>::ForSpan(MutableSpan<T>((T *)data, domain_size));
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* In this function all the attribute providers for a point cloud component are created. Most data
|
|
|
|
|
* in this function is statically allocated, because it does not change over time.
|
|
|
|
|
*/
|
|
|
|
|
static ComponentAttributeProviders create_attribute_providers_for_point_cloud()
|
|
|
|
|
{
|
|
|
|
|
static auto update_custom_data_pointers = [](GeometryComponent &component) {
|
|
|
|
|
PointCloudComponent &pointcloud_component = static_cast<PointCloudComponent &>(component);
|
|
|
|
|
PointCloud *pointcloud = pointcloud_component.get_for_write();
|
|
|
|
|
if (pointcloud != nullptr) {
|
|
|
|
|
BKE_pointcloud_update_customdata_pointers(pointcloud);
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
static CustomDataAccessInfo point_access = {
|
|
|
|
|
[](GeometryComponent &component) -> CustomData * {
|
|
|
|
|
PointCloudComponent &pointcloud_component = static_cast<PointCloudComponent &>(component);
|
|
|
|
|
PointCloud *pointcloud = pointcloud_component.get_for_write();
|
|
|
|
|
return pointcloud ? &pointcloud->pdata : nullptr;
|
|
|
|
|
},
|
|
|
|
|
[](const GeometryComponent &component) -> const CustomData * {
|
|
|
|
|
const PointCloudComponent &pointcloud_component = static_cast<const PointCloudComponent &>(
|
|
|
|
|
component);
|
|
|
|
|
const PointCloud *pointcloud = pointcloud_component.get_for_read();
|
|
|
|
|
return pointcloud ? &pointcloud->pdata : nullptr;
|
|
|
|
|
},
|
|
|
|
|
update_custom_data_pointers};
|
|
|
|
|
|
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
|
|
|
static BuiltinCustomDataLayerProvider position("position",
|
|
|
|
|
ATTR_DOMAIN_POINT,
|
|
|
|
|
CD_PROP_FLOAT3,
|
|
|
|
|
CD_PROP_FLOAT3,
|
|
|
|
|
BuiltinAttributeProvider::NonCreatable,
|
|
|
|
|
BuiltinAttributeProvider::Writable,
|
|
|
|
|
BuiltinAttributeProvider::NonDeletable,
|
|
|
|
|
point_access,
|
|
|
|
|
make_array_read_attribute<float3>,
|
|
|
|
|
make_array_write_attribute<float3>,
|
|
|
|
|
nullptr);
|
|
|
|
|
static BuiltinCustomDataLayerProvider radius("radius",
|
|
|
|
|
ATTR_DOMAIN_POINT,
|
|
|
|
|
CD_PROP_FLOAT,
|
|
|
|
|
CD_PROP_FLOAT,
|
|
|
|
|
BuiltinAttributeProvider::Creatable,
|
|
|
|
|
BuiltinAttributeProvider::Writable,
|
|
|
|
|
BuiltinAttributeProvider::Deletable,
|
|
|
|
|
point_access,
|
|
|
|
|
make_array_read_attribute<float>,
|
|
|
|
|
make_array_write_attribute<float>,
|
|
|
|
|
nullptr);
|
2021-10-20 10:54:54 -05:00
|
|
|
static BuiltinCustomDataLayerProvider id("id",
|
|
|
|
|
ATTR_DOMAIN_POINT,
|
|
|
|
|
CD_PROP_INT32,
|
|
|
|
|
CD_PROP_INT32,
|
|
|
|
|
BuiltinAttributeProvider::Creatable,
|
|
|
|
|
BuiltinAttributeProvider::Writable,
|
|
|
|
|
BuiltinAttributeProvider::Deletable,
|
|
|
|
|
point_access,
|
|
|
|
|
make_array_read_attribute<int>,
|
|
|
|
|
make_array_write_attribute<int>,
|
|
|
|
|
nullptr);
|
2021-03-08 11:41:23 -05:00
|
|
|
static CustomDataAttributeProvider point_custom_data(ATTR_DOMAIN_POINT, point_access);
|
2021-10-20 10:54:54 -05:00
|
|
|
return ComponentAttributeProviders({&position, &radius, &id}, {&point_custom_data});
|
2021-03-08 11:41:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // namespace blender::bke
|
|
|
|
|
|
|
|
|
|
const blender::bke::ComponentAttributeProviders *PointCloudComponent::get_attribute_providers()
|
|
|
|
|
const
|
|
|
|
|
{
|
|
|
|
|
static blender::bke::ComponentAttributeProviders providers =
|
|
|
|
|
blender::bke::create_attribute_providers_for_point_cloud();
|
|
|
|
|
return &providers;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** \} */
|