2023-08-15 16:20:26 +02:00
|
|
|
/* SPDX-FileCopyrightText: 2006 Blender Authors
|
2023-05-31 16:19:06 +02:00
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2020-07-03 15:30:04 +02:00
|
|
|
|
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
2022-02-09 06:00:03 +01:00
|
|
|
* Implementation of generic geometry attributes management. This is built
|
|
|
|
* on top of CustomData, which manages individual domains.
|
2020-07-03 15:30:04 +02:00
|
|
|
*/
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
#include <cstring>
|
2022-07-24 02:59:59 +02:00
|
|
|
#include <optional>
|
2020-07-03 15:30:04 +02:00
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
#include "DNA_ID.h"
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 18:55:54 +01:00
|
|
|
#include "DNA_curves_types.h"
|
2020-07-03 15:30:04 +02:00
|
|
|
#include "DNA_customdata_types.h"
|
|
|
|
#include "DNA_mesh_types.h"
|
|
|
|
#include "DNA_meshdata_types.h"
|
|
|
|
#include "DNA_pointcloud_types.h"
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
#include "BLI_index_range.hh"
|
2022-08-04 00:16:46 +02:00
|
|
|
#include "BLI_string.h"
|
2020-07-03 15:30:04 +02:00
|
|
|
#include "BLI_string_utf8.h"
|
2023-10-18 17:15:30 +02:00
|
|
|
#include "BLI_string_utils.hh"
|
2020-07-03 15:30:04 +02:00
|
|
|
|
2022-08-04 00:16:46 +02:00
|
|
|
#include "BLT_translation.h"
|
|
|
|
|
2020-07-03 15:30:04 +02:00
|
|
|
#include "BKE_attribute.h"
|
Geometry Nodes: new geometry attribute API
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
2022-07-08 16:16:56 +02:00
|
|
|
#include "BKE_attribute.hh"
|
2022-07-24 02:59:59 +02:00
|
|
|
#include "BKE_curves.hh"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BKE_customdata.hh"
|
|
|
|
#include "BKE_editmesh.hh"
|
2023-10-10 16:49:30 +02:00
|
|
|
#include "BKE_grease_pencil.hh"
|
2023-03-12 22:29:15 +01:00
|
|
|
#include "BKE_mesh.hh"
|
2020-08-04 12:52:04 +02:00
|
|
|
#include "BKE_pointcloud.h"
|
2020-07-03 15:30:04 +02:00
|
|
|
#include "BKE_report.h"
|
|
|
|
|
2023-08-10 22:40:27 +02:00
|
|
|
#include "RNA_access.hh"
|
2020-07-03 15:30:04 +02:00
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
using blender::IndexRange;
|
|
|
|
|
|
|
|
struct DomainInfo {
|
2020-07-03 15:30:04 +02:00
|
|
|
CustomData *customdata;
|
|
|
|
int length;
|
2022-05-30 18:06:39 +02:00
|
|
|
};
|
2020-07-03 15:30:04 +02:00
|
|
|
|
2021-09-09 17:22:20 +02:00
|
|
|
static void get_domains(const ID *id, DomainInfo info[ATTR_DOMAIN_NUM])
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
|
|
|
memset(info, 0, sizeof(DomainInfo) * ATTR_DOMAIN_NUM);
|
|
|
|
|
|
|
|
switch (GS(id->name)) {
|
|
|
|
case ID_PT: {
|
|
|
|
PointCloud *pointcloud = (PointCloud *)id;
|
|
|
|
info[ATTR_DOMAIN_POINT].customdata = &pointcloud->pdata;
|
|
|
|
info[ATTR_DOMAIN_POINT].length = pointcloud->totpoint;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case ID_ME: {
|
|
|
|
Mesh *mesh = (Mesh *)id;
|
2021-07-22 14:05:55 +02:00
|
|
|
BMEditMesh *em = mesh->edit_mesh;
|
2022-05-30 18:06:39 +02:00
|
|
|
if (em != nullptr) {
|
2021-07-22 14:05:55 +02:00
|
|
|
BMesh *bm = em->bm;
|
|
|
|
info[ATTR_DOMAIN_POINT].customdata = &bm->vdata;
|
|
|
|
info[ATTR_DOMAIN_POINT].length = bm->totvert;
|
|
|
|
info[ATTR_DOMAIN_EDGE].customdata = &bm->edata;
|
|
|
|
info[ATTR_DOMAIN_EDGE].length = bm->totedge;
|
|
|
|
info[ATTR_DOMAIN_CORNER].customdata = &bm->ldata;
|
|
|
|
info[ATTR_DOMAIN_CORNER].length = bm->totloop;
|
|
|
|
info[ATTR_DOMAIN_FACE].customdata = &bm->pdata;
|
|
|
|
info[ATTR_DOMAIN_FACE].length = bm->totface;
|
|
|
|
}
|
|
|
|
else {
|
2023-07-25 21:15:52 +02:00
|
|
|
info[ATTR_DOMAIN_POINT].customdata = &mesh->vert_data;
|
2021-07-22 14:05:55 +02:00
|
|
|
info[ATTR_DOMAIN_POINT].length = mesh->totvert;
|
2023-07-25 21:15:52 +02:00
|
|
|
info[ATTR_DOMAIN_EDGE].customdata = &mesh->edge_data;
|
2021-07-22 14:05:55 +02:00
|
|
|
info[ATTR_DOMAIN_EDGE].length = mesh->totedge;
|
2023-07-25 21:15:52 +02:00
|
|
|
info[ATTR_DOMAIN_CORNER].customdata = &mesh->loop_data;
|
2021-07-22 14:05:55 +02:00
|
|
|
info[ATTR_DOMAIN_CORNER].length = mesh->totloop;
|
2023-07-25 21:15:52 +02:00
|
|
|
info[ATTR_DOMAIN_FACE].customdata = &mesh->face_data;
|
2023-07-24 22:06:55 +02:00
|
|
|
info[ATTR_DOMAIN_FACE].length = mesh->faces_num;
|
2021-07-22 14:05:55 +02:00
|
|
|
}
|
2020-07-03 15:30:04 +02:00
|
|
|
break;
|
|
|
|
}
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 18:55:54 +01:00
|
|
|
case ID_CV: {
|
|
|
|
Curves *curves = (Curves *)id;
|
|
|
|
info[ATTR_DOMAIN_POINT].customdata = &curves->geometry.point_data;
|
2022-05-11 01:58:39 +02:00
|
|
|
info[ATTR_DOMAIN_POINT].length = curves->geometry.point_num;
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 18:55:54 +01:00
|
|
|
info[ATTR_DOMAIN_CURVE].customdata = &curves->geometry.curve_data;
|
2022-05-11 01:58:39 +02:00
|
|
|
info[ATTR_DOMAIN_CURVE].length = curves->geometry.curve_num;
|
2020-07-03 15:30:04 +02:00
|
|
|
break;
|
|
|
|
}
|
2023-10-10 16:49:30 +02:00
|
|
|
case ID_GP: {
|
|
|
|
GreasePencil *grease_pencil = (GreasePencil *)id;
|
2023-10-12 13:54:32 +02:00
|
|
|
info[ATTR_DOMAIN_LAYER].customdata = &grease_pencil->layers_data;
|
|
|
|
info[ATTR_DOMAIN_LAYER].length = grease_pencil->layers().size();
|
2023-10-10 16:49:30 +02:00
|
|
|
break;
|
|
|
|
}
|
2020-07-03 15:30:04 +02:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-24 02:59:59 +02:00
|
|
|
namespace blender::bke {
|
|
|
|
|
|
|
|
static std::optional<blender::bke::MutableAttributeAccessor> get_attribute_accessor_for_write(
|
|
|
|
ID &id)
|
|
|
|
{
|
|
|
|
switch (GS(id.name)) {
|
|
|
|
case ID_ME: {
|
|
|
|
Mesh &mesh = reinterpret_cast<Mesh &>(id);
|
|
|
|
/* The attribute API isn't implemented for BMesh, so edit mode meshes are not supported. */
|
|
|
|
BLI_assert(mesh.edit_mesh == nullptr);
|
2022-09-08 04:41:39 +02:00
|
|
|
return mesh.attributes_for_write();
|
2022-07-24 02:59:59 +02:00
|
|
|
}
|
|
|
|
case ID_PT: {
|
|
|
|
PointCloud &pointcloud = reinterpret_cast<PointCloud &>(id);
|
2022-09-08 04:41:39 +02:00
|
|
|
return pointcloud.attributes_for_write();
|
2022-07-24 02:59:59 +02:00
|
|
|
}
|
|
|
|
case ID_CV: {
|
|
|
|
Curves &curves_id = reinterpret_cast<Curves &>(id);
|
2023-01-31 18:45:34 +01:00
|
|
|
CurvesGeometry &curves = curves_id.geometry.wrap();
|
2022-07-24 02:59:59 +02:00
|
|
|
return curves.attributes_for_write();
|
|
|
|
}
|
2023-10-10 16:49:30 +02:00
|
|
|
case ID_GP: {
|
|
|
|
GreasePencil &grease_pencil = reinterpret_cast<GreasePencil &>(id);
|
|
|
|
return grease_pencil.attributes_for_write();
|
|
|
|
}
|
2022-07-24 02:59:59 +02:00
|
|
|
default: {
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace blender::bke
|
|
|
|
|
2022-06-07 18:55:56 +02:00
|
|
|
bool BKE_id_attributes_supported(const ID *id)
|
2020-08-19 18:12:52 +02:00
|
|
|
{
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2020-08-19 18:12:52 +02:00
|
|
|
if (info[domain].customdata) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-05-31 13:20:16 +02:00
|
|
|
bool BKE_attribute_allow_procedural_access(const char *attribute_name)
|
|
|
|
{
|
|
|
|
return blender::bke::allow_procedural_attribute_access(attribute_name);
|
|
|
|
}
|
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
static bool bke_id_attribute_rename_if_exists(ID *id,
|
|
|
|
const char *old_name,
|
|
|
|
const char *new_name,
|
|
|
|
ReportList *reports)
|
|
|
|
{
|
2023-10-24 20:19:14 +02:00
|
|
|
CustomDataLayer *layer = BKE_id_attribute_search_for_write(
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
id, old_name, CD_MASK_PROP_ALL, ATTR_DOMAIN_MASK_ALL);
|
|
|
|
if (layer == nullptr) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return BKE_id_attribute_rename(id, old_name, new_name, reports);
|
|
|
|
}
|
|
|
|
|
2020-07-03 15:30:04 +02:00
|
|
|
bool BKE_id_attribute_rename(ID *id,
|
2022-06-08 10:42:21 +02:00
|
|
|
const char *old_name,
|
2020-07-03 15:30:04 +02:00
|
|
|
const char *new_name,
|
|
|
|
ReportList *reports)
|
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
using namespace blender;
|
2022-06-08 10:42:21 +02:00
|
|
|
if (BKE_id_attribute_required(id, old_name)) {
|
2021-07-15 10:23:28 +02:00
|
|
|
BLI_assert_msg(0, "Required attribute name is not editable");
|
2020-08-04 12:52:04 +02:00
|
|
|
return false;
|
|
|
|
}
|
2022-07-25 13:16:59 +02:00
|
|
|
if (STREQ(new_name, "")) {
|
|
|
|
BKE_report(reports, RPT_ERROR, "Attribute name can not be empty");
|
|
|
|
return false;
|
|
|
|
}
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
|
|
|
|
/* NOTE: Checking if the new name matches the old name only makes sense when the name
|
|
|
|
* is clamped to it's maximum length, otherwise assigning an over-long name multiple times
|
|
|
|
* will add `.001` suffix unnecessarily. */
|
|
|
|
{
|
2023-06-10 09:21:24 +02:00
|
|
|
const int new_name_maxncpy = CustomData_name_maxncpy_calc(new_name);
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
/* NOTE: A function that performs a clamped comparison without copying would be handy here. */
|
|
|
|
char new_name_clamped[MAX_CUSTOMDATA_LAYER_NAME];
|
2023-05-13 09:34:23 +02:00
|
|
|
BLI_strncpy_utf8(new_name_clamped, new_name, new_name_maxncpy);
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
if (STREQ(old_name, new_name_clamped)) {
|
|
|
|
return false;
|
|
|
|
}
|
2022-07-25 13:16:59 +02:00
|
|
|
}
|
2020-08-04 12:52:04 +02:00
|
|
|
|
2023-10-24 20:19:14 +02:00
|
|
|
CustomDataLayer *layer = BKE_id_attribute_search_for_write(
|
2022-06-08 10:42:21 +02:00
|
|
|
id, old_name, CD_MASK_PROP_ALL, ATTR_DOMAIN_MASK_ALL);
|
|
|
|
if (layer == nullptr) {
|
2020-07-03 15:30:04 +02:00
|
|
|
BKE_report(reports, RPT_ERROR, "Attribute is not part of this geometry");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-06-07 14:51:52 +02:00
|
|
|
char result_name[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
BKE_id_attribute_calc_unique_name(id, new_name, result_name);
|
2022-12-15 21:18:57 +01:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
if (layer->type == CD_PROP_FLOAT2 && GS(id->name) == ID_ME) {
|
|
|
|
/* Rename UV sub-attributes. */
|
|
|
|
char buffer_src[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
char buffer_dst[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
|
|
|
|
bke_id_attribute_rename_if_exists(id,
|
|
|
|
BKE_uv_map_vert_select_name_get(layer->name, buffer_src),
|
|
|
|
BKE_uv_map_vert_select_name_get(result_name, buffer_dst),
|
|
|
|
reports);
|
|
|
|
bke_id_attribute_rename_if_exists(id,
|
|
|
|
BKE_uv_map_edge_select_name_get(layer->name, buffer_src),
|
|
|
|
BKE_uv_map_edge_select_name_get(result_name, buffer_dst),
|
|
|
|
reports);
|
|
|
|
bke_id_attribute_rename_if_exists(id,
|
|
|
|
BKE_uv_map_pin_name_get(layer->name, buffer_src),
|
|
|
|
BKE_uv_map_pin_name_get(result_name, buffer_dst),
|
|
|
|
reports);
|
|
|
|
}
|
2022-12-15 21:18:57 +01:00
|
|
|
if (StringRef(old_name) == BKE_id_attributes_active_color_name(id)) {
|
|
|
|
BKE_id_attributes_active_color_set(id, result_name);
|
|
|
|
}
|
|
|
|
if (StringRef(old_name) == BKE_id_attributes_default_color_name(id)) {
|
|
|
|
BKE_id_attributes_default_color_set(id, result_name);
|
|
|
|
}
|
|
|
|
|
2023-05-09 04:50:37 +02:00
|
|
|
STRNCPY_UTF8(layer->name, result_name);
|
2022-06-07 14:51:52 +02:00
|
|
|
|
2020-07-03 15:30:04 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2023-09-26 15:36:12 +02:00
|
|
|
struct AttrUniqueData {
|
|
|
|
ID *id;
|
|
|
|
};
|
2023-08-08 10:11:10 +02:00
|
|
|
|
2023-09-26 15:36:12 +02:00
|
|
|
static bool unique_name_cb(void *arg, const char *name)
|
|
|
|
{
|
|
|
|
AttrUniqueData *data = (AttrUniqueData *)arg;
|
2022-04-05 20:42:55 +02:00
|
|
|
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(data->id, info);
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-04-05 20:42:55 +02:00
|
|
|
if (!info[domain].customdata) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-08-30 00:00:46 +02:00
|
|
|
const CustomData *cdata = info[domain].customdata;
|
2022-04-05 20:42:55 +02:00
|
|
|
for (int i = 0; i < cdata->totlayer; i++) {
|
2022-08-30 00:00:46 +02:00
|
|
|
const CustomDataLayer *layer = cdata->layers + i;
|
2022-04-05 20:42:55 +02:00
|
|
|
|
|
|
|
if (STREQ(layer->name, name)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2023-10-19 15:07:57 +02:00
|
|
|
void BKE_id_attribute_calc_unique_name(ID *id, const char *name, char *outname)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2023-09-26 15:36:12 +02:00
|
|
|
AttrUniqueData data{id};
|
2023-08-08 10:11:10 +02:00
|
|
|
|
2023-06-10 09:21:24 +02:00
|
|
|
const int name_maxncpy = CustomData_name_maxncpy_calc(name);
|
2022-04-05 20:42:55 +02:00
|
|
|
|
2022-08-04 00:16:46 +02:00
|
|
|
/* Set default name if none specified.
|
2023-10-22 13:54:25 +02:00
|
|
|
* NOTE: We only call DATA_() if needed to avoid locale lookup overhead. */
|
|
|
|
BLI_strncpy_utf8(outname, (name && name[0]) ? name : DATA_("Attribute"), name_maxncpy);
|
2022-04-05 20:42:55 +02:00
|
|
|
|
2023-05-03 02:23:00 +02:00
|
|
|
const char *defname = ""; /* Dummy argument, never used as `name` is never zero length. */
|
2023-10-19 15:07:57 +02:00
|
|
|
BLI_uniquename_cb(unique_name_cb, &data, defname, '.', outname, name_maxncpy);
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2023-03-29 17:10:49 +02:00
|
|
|
CustomDataLayer *BKE_id_attribute_new(ID *id,
|
|
|
|
const char *name,
|
|
|
|
const eCustomDataType type,
|
|
|
|
const eAttrDomain domain,
|
|
|
|
ReportList *reports)
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
2022-07-24 19:46:08 +02:00
|
|
|
using namespace blender::bke;
|
2020-07-03 15:30:04 +02:00
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
CustomData *customdata = info[domain].customdata;
|
2022-05-30 18:06:39 +02:00
|
|
|
if (customdata == nullptr) {
|
2020-07-03 15:30:04 +02:00
|
|
|
BKE_report(reports, RPT_ERROR, "Attribute domain not supported by this geometry type");
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
2022-04-05 20:42:55 +02:00
|
|
|
char uniquename[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
BKE_id_attribute_calc_unique_name(id, name, uniquename);
|
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
if (GS(id->name) == ID_ME) {
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
|
|
|
if (BMEditMesh *em = mesh->edit_mesh) {
|
|
|
|
BM_data_layer_add_named(em->bm, customdata, type, uniquename);
|
|
|
|
const int index = CustomData_get_named_layer_index(customdata, type, uniquename);
|
|
|
|
return (index == -1) ? nullptr : &(customdata->layers[index]);
|
2021-07-22 14:05:55 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
std::optional<MutableAttributeAccessor> attributes = get_attribute_accessor_for_write(*id);
|
|
|
|
if (!attributes) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
Attributes: Improve custom data initialization options
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
2022-08-30 21:54:53 +02:00
|
|
|
attributes->add(uniquename, domain, eCustomDataType(type), AttributeInitDefaultValue());
|
2022-07-24 19:46:08 +02:00
|
|
|
|
2022-04-05 20:42:55 +02:00
|
|
|
const int index = CustomData_get_named_layer_index(customdata, type, uniquename);
|
2023-08-08 10:11:10 +02:00
|
|
|
if (index == -1) {
|
|
|
|
BKE_reportf(reports, RPT_WARNING, "Layer '%s' could not be created", uniquename);
|
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
return (index == -1) ? nullptr : &(customdata->layers[index]);
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
static void bke_id_attribute_copy_if_exists(ID *id, const char *srcname, const char *dstname)
|
|
|
|
{
|
|
|
|
using namespace blender::bke;
|
|
|
|
|
|
|
|
std::optional<MutableAttributeAccessor> attributes = get_attribute_accessor_for_write(*id);
|
|
|
|
if (!attributes) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
GAttributeReader src = attributes->lookup(srcname);
|
|
|
|
if (!src) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
const eCustomDataType type = cpp_type_to_custom_data_type(src.varray.type());
|
|
|
|
attributes->add(dstname, src.domain, type, AttributeInitVArray(src.varray));
|
|
|
|
}
|
|
|
|
|
2022-06-14 16:25:24 +02:00
|
|
|
CustomDataLayer *BKE_id_attribute_duplicate(ID *id, const char *name, ReportList *reports)
|
2022-06-08 21:10:32 +02:00
|
|
|
{
|
2022-07-24 19:46:08 +02:00
|
|
|
using namespace blender::bke;
|
|
|
|
char uniquename[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
BKE_id_attribute_calc_unique_name(id, name, uniquename);
|
2022-06-08 21:10:32 +02:00
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
if (GS(id->name) == ID_ME) {
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
|
|
|
if (BMEditMesh *em = mesh->edit_mesh) {
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
UNUSED_VARS(em);
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
2022-06-08 21:10:32 +02:00
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
std::optional<MutableAttributeAccessor> attributes = get_attribute_accessor_for_write(*id);
|
|
|
|
if (!attributes) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2022-06-14 16:25:24 +02:00
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
GAttributeReader src = attributes->lookup(name);
|
|
|
|
if (!src) {
|
|
|
|
BKE_report(reports, RPT_ERROR, "Attribute is not part of this geometry");
|
2022-06-14 16:25:24 +02:00
|
|
|
return nullptr;
|
2022-06-08 21:10:32 +02:00
|
|
|
}
|
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
const eCustomDataType type = cpp_type_to_custom_data_type(src.varray.type());
|
|
|
|
attributes->add(uniquename, src.domain, type, AttributeInitVArray(src.varray));
|
2022-06-08 21:10:32 +02:00
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
if (GS(id->name) == ID_ME && type == CD_PROP_FLOAT2) {
|
|
|
|
/* Duplicate UV sub-attributes. */
|
|
|
|
char buffer_src[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
char buffer_dst[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
|
|
|
|
bke_id_attribute_copy_if_exists(id,
|
|
|
|
BKE_uv_map_vert_select_name_get(name, buffer_src),
|
|
|
|
BKE_uv_map_vert_select_name_get(uniquename, buffer_dst));
|
|
|
|
bke_id_attribute_copy_if_exists(id,
|
|
|
|
BKE_uv_map_edge_select_name_get(name, buffer_src),
|
|
|
|
BKE_uv_map_edge_select_name_get(uniquename, buffer_dst));
|
|
|
|
bke_id_attribute_copy_if_exists(id,
|
|
|
|
BKE_uv_map_pin_name_get(name, buffer_src),
|
|
|
|
BKE_uv_map_pin_name_get(uniquename, buffer_dst));
|
|
|
|
}
|
|
|
|
|
2023-10-24 20:19:14 +02:00
|
|
|
return BKE_id_attribute_search_for_write(id, uniquename, CD_MASK_PROP_ALL, ATTR_DOMAIN_MASK_ALL);
|
2022-06-08 21:10:32 +02:00
|
|
|
}
|
|
|
|
|
2023-03-19 00:57:22 +01:00
|
|
|
static int color_name_to_index(ID *id, const char *name)
|
|
|
|
{
|
|
|
|
const CustomDataLayer *layer = BKE_id_attribute_search(
|
|
|
|
id, name, CD_MASK_COLOR_ALL, ATTR_DOMAIN_MASK_COLOR);
|
|
|
|
return BKE_id_attribute_to_index(id, layer, ATTR_DOMAIN_MASK_COLOR, CD_MASK_COLOR_ALL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int color_clamp_index(ID *id, int index)
|
|
|
|
{
|
|
|
|
const int length = BKE_id_attributes_length(id, ATTR_DOMAIN_MASK_COLOR, CD_MASK_COLOR_ALL);
|
|
|
|
return min_ii(index, length - 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *color_name_from_index(ID *id, int index)
|
|
|
|
{
|
|
|
|
const CustomDataLayer *layer = BKE_id_attribute_from_index(
|
|
|
|
id, index, ATTR_DOMAIN_MASK_COLOR, CD_MASK_COLOR_ALL);
|
|
|
|
return layer ? layer->name : nullptr;
|
|
|
|
}
|
|
|
|
|
2022-06-08 10:42:21 +02:00
|
|
|
bool BKE_id_attribute_remove(ID *id, const char *name, ReportList *reports)
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
using namespace blender;
|
2022-07-24 02:59:59 +02:00
|
|
|
using namespace blender::bke;
|
2022-08-29 21:45:55 +02:00
|
|
|
if (!name || name[0] == '\0') {
|
|
|
|
BKE_report(reports, RPT_ERROR, "The attribute name must not be empty");
|
|
|
|
return false;
|
|
|
|
}
|
2022-06-08 10:42:21 +02:00
|
|
|
if (BKE_id_attribute_required(id, name)) {
|
2020-08-04 12:52:04 +02:00
|
|
|
BKE_report(reports, RPT_ERROR, "Attribute is required and can't be removed");
|
2020-08-19 18:12:52 +02:00
|
|
|
return false;
|
2020-08-04 12:52:04 +02:00
|
|
|
}
|
|
|
|
|
2022-06-08 10:42:21 +02:00
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
if (GS(id->name) == ID_ME) {
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
|
|
|
if (BMEditMesh *em = mesh->edit_mesh) {
|
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
|
|
|
if (CustomData *data = info[domain].customdata) {
|
2023-03-19 15:02:29 +01:00
|
|
|
const std::string name_copy = name;
|
|
|
|
const int layer_index = CustomData_get_named_layer_index_notype(data, name_copy.c_str());
|
|
|
|
if (layer_index == -1) {
|
|
|
|
continue;
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
}
|
2023-03-19 15:02:29 +01:00
|
|
|
|
|
|
|
const eCustomDataType type = eCustomDataType(data->layers[layer_index].type);
|
|
|
|
const bool is_active_color_attribute = name_copy.c_str() ==
|
|
|
|
StringRef(mesh->active_color_attribute);
|
|
|
|
const bool is_default_color_attribute = name_copy.c_str() ==
|
|
|
|
StringRef(mesh->default_color_attribute);
|
2023-03-19 15:30:53 +01:00
|
|
|
const int active_color_index = color_name_to_index(id, mesh->active_color_attribute);
|
|
|
|
const int default_color_index = color_name_to_index(id, mesh->default_color_attribute);
|
2023-03-19 15:02:29 +01:00
|
|
|
|
|
|
|
if (!BM_data_layer_free_named(em->bm, data, name_copy.c_str())) {
|
|
|
|
BLI_assert_unreachable();
|
2023-03-19 00:57:22 +01:00
|
|
|
}
|
2023-03-19 15:02:29 +01:00
|
|
|
|
2023-03-19 00:57:22 +01:00
|
|
|
if (is_active_color_attribute) {
|
|
|
|
BKE_id_attributes_active_color_set(
|
2023-03-19 15:30:53 +01:00
|
|
|
id, color_name_from_index(id, color_clamp_index(id, active_color_index)));
|
2023-03-19 00:57:22 +01:00
|
|
|
}
|
|
|
|
if (is_default_color_attribute) {
|
|
|
|
BKE_id_attributes_default_color_set(
|
2023-03-19 15:30:53 +01:00
|
|
|
id, color_name_from_index(id, color_clamp_index(id, default_color_index)));
|
2022-06-08 10:42:21 +02:00
|
|
|
}
|
2023-03-19 15:02:29 +01:00
|
|
|
|
2023-03-19 15:10:04 +01:00
|
|
|
if (type == CD_PROP_FLOAT2 && domain == ATTR_DOMAIN_CORNER) {
|
2023-03-19 15:02:29 +01:00
|
|
|
char buffer[MAX_CUSTOMDATA_LAYER_NAME];
|
|
|
|
BM_data_layer_free_named(
|
|
|
|
em->bm, data, BKE_uv_map_vert_select_name_get(name_copy.c_str(), buffer));
|
|
|
|
BM_data_layer_free_named(
|
|
|
|
em->bm, data, BKE_uv_map_edge_select_name_get(name_copy.c_str(), buffer));
|
|
|
|
BM_data_layer_free_named(
|
|
|
|
em->bm, data, BKE_uv_map_pin_name_get(name_copy.c_str(), buffer));
|
|
|
|
}
|
2023-03-19 00:57:22 +01:00
|
|
|
return true;
|
2022-06-08 10:42:21 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
2022-07-24 19:46:08 +02:00
|
|
|
}
|
2021-07-22 14:05:55 +02:00
|
|
|
}
|
2022-07-24 19:46:08 +02:00
|
|
|
|
|
|
|
std::optional<MutableAttributeAccessor> attributes = get_attribute_accessor_for_write(*id);
|
|
|
|
if (!attributes) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
if (GS(id->name) == ID_ME) {
|
2023-03-19 15:02:29 +01:00
|
|
|
const std::string name_copy = name;
|
|
|
|
std::optional<blender::bke::AttributeMetaData> metadata = attributes->lookup_meta_data(
|
|
|
|
name_copy);
|
|
|
|
if (!metadata) {
|
|
|
|
return false;
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
}
|
2023-03-19 00:57:22 +01:00
|
|
|
/* Update active and default color attributes. */
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
2023-03-19 15:02:29 +01:00
|
|
|
const bool is_active_color_attribute = name_copy == StringRef(mesh->active_color_attribute);
|
|
|
|
const bool is_default_color_attribute = name_copy == StringRef(mesh->default_color_attribute);
|
2023-03-19 15:30:53 +01:00
|
|
|
const int active_color_index = color_name_to_index(id, mesh->active_color_attribute);
|
|
|
|
const int default_color_index = color_name_to_index(id, mesh->default_color_attribute);
|
2023-03-19 15:02:29 +01:00
|
|
|
|
|
|
|
if (!attributes->remove(name_copy)) {
|
|
|
|
BLI_assert_unreachable();
|
2023-03-19 00:57:22 +01:00
|
|
|
}
|
2023-03-19 15:02:29 +01:00
|
|
|
|
2023-03-19 00:57:22 +01:00
|
|
|
if (is_active_color_attribute) {
|
|
|
|
BKE_id_attributes_active_color_set(
|
2023-03-19 15:30:53 +01:00
|
|
|
id, color_name_from_index(id, color_clamp_index(id, active_color_index)));
|
2023-03-19 00:57:22 +01:00
|
|
|
}
|
|
|
|
if (is_default_color_attribute) {
|
|
|
|
BKE_id_attributes_default_color_set(
|
2023-03-19 15:30:53 +01:00
|
|
|
id, color_name_from_index(id, color_clamp_index(id, default_color_index)));
|
2023-03-19 00:57:22 +01:00
|
|
|
}
|
2023-03-19 15:30:53 +01:00
|
|
|
|
2023-03-19 15:10:04 +01:00
|
|
|
if (metadata->data_type == CD_PROP_FLOAT2 && metadata->domain == ATTR_DOMAIN_CORNER) {
|
2023-03-19 15:02:29 +01:00
|
|
|
char buffer[MAX_CUSTOMDATA_LAYER_NAME];
|
2023-03-19 15:07:54 +01:00
|
|
|
attributes->remove(BKE_uv_map_vert_select_name_get(name_copy.c_str(), buffer));
|
|
|
|
attributes->remove(BKE_uv_map_edge_select_name_get(name_copy.c_str(), buffer));
|
|
|
|
attributes->remove(BKE_uv_map_pin_name_get(name_copy.c_str(), buffer));
|
2023-03-19 15:02:29 +01:00
|
|
|
}
|
2023-03-19 00:57:22 +01:00
|
|
|
return true;
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
}
|
|
|
|
|
2022-07-24 19:46:08 +02:00
|
|
|
return attributes->remove(name);
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
2021-09-09 17:22:20 +02:00
|
|
|
CustomDataLayer *BKE_id_attribute_find(const ID *id,
|
|
|
|
const char *name,
|
2023-03-29 17:10:49 +02:00
|
|
|
const eCustomDataType type,
|
2022-06-01 06:38:06 +02:00
|
|
|
const eAttrDomain domain)
|
2021-09-09 17:22:20 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
if (!name) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2021-09-09 17:22:20 +02:00
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
CustomData *customdata = info[domain].customdata;
|
2022-05-30 18:06:39 +02:00
|
|
|
if (customdata == nullptr) {
|
|
|
|
return nullptr;
|
2021-09-09 17:22:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < customdata->totlayer; i++) {
|
|
|
|
CustomDataLayer *layer = &customdata->layers[i];
|
|
|
|
if (layer->type == type && STREQ(layer->name, name)) {
|
|
|
|
return layer;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2021-09-09 17:22:20 +02:00
|
|
|
}
|
|
|
|
|
2023-10-24 20:19:14 +02:00
|
|
|
const CustomDataLayer *BKE_id_attribute_search(const ID *id,
|
|
|
|
const char *name,
|
|
|
|
const eCustomDataMask type_mask,
|
|
|
|
const eAttrDomainMask domain_mask)
|
2022-06-01 00:46:09 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
if (!name) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2022-06-01 00:46:09 +02:00
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
2022-06-01 06:38:06 +02:00
|
|
|
for (eAttrDomain domain = ATTR_DOMAIN_POINT; domain < ATTR_DOMAIN_NUM;
|
2022-09-25 10:33:28 +02:00
|
|
|
domain = static_cast<eAttrDomain>(int(domain) + 1))
|
|
|
|
{
|
2022-06-01 00:46:09 +02:00
|
|
|
if (!(domain_mask & ATTR_DOMAIN_AS_MASK(domain))) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
CustomData *customdata = info[domain].customdata;
|
2022-06-08 21:10:32 +02:00
|
|
|
if (customdata == nullptr) {
|
2022-06-07 18:38:30 +02:00
|
|
|
continue;
|
2022-06-01 00:46:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < customdata->totlayer; i++) {
|
|
|
|
CustomDataLayer *layer = &customdata->layers[i];
|
|
|
|
if ((CD_TYPE_AS_MASK(layer->type) & type_mask) && STREQ(layer->name, name)) {
|
|
|
|
return layer;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-08 21:10:32 +02:00
|
|
|
return nullptr;
|
2022-06-01 00:46:09 +02:00
|
|
|
}
|
|
|
|
|
2023-10-24 20:19:14 +02:00
|
|
|
CustomDataLayer *BKE_id_attribute_search_for_write(ID *id,
|
|
|
|
const char *name,
|
|
|
|
const eCustomDataMask type_mask,
|
|
|
|
const eAttrDomainMask domain_mask)
|
|
|
|
{
|
|
|
|
/* Reuse the implementation of the const version.
|
|
|
|
* Implicit sharing for the layer's data is handled below. */
|
|
|
|
CustomDataLayer *layer = const_cast<CustomDataLayer *>(
|
|
|
|
BKE_id_attribute_search(id, name, type_mask, domain_mask));
|
|
|
|
if (!layer) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
const eAttrDomain domain = BKE_id_attribute_domain(id, layer);
|
|
|
|
CustomData_ensure_data_is_mutable(layer, info[domain].length);
|
|
|
|
|
|
|
|
return layer;
|
|
|
|
}
|
|
|
|
|
2022-06-01 06:38:06 +02:00
|
|
|
int BKE_id_attributes_length(const ID *id, eAttrDomainMask domain_mask, eCustomDataMask mask)
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
int length = 0;
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-09-06 09:27:28 +02:00
|
|
|
const CustomData *customdata = info[domain].customdata;
|
|
|
|
if (customdata == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
2022-04-05 20:42:55 +02:00
|
|
|
|
2022-09-25 10:33:28 +02:00
|
|
|
if ((1 << int(domain)) & domain_mask) {
|
2020-07-03 15:30:04 +02:00
|
|
|
length += CustomData_number_of_layers_typemask(customdata, mask);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return length;
|
|
|
|
}
|
|
|
|
|
2022-06-01 06:38:06 +02:00
|
|
|
eAttrDomain BKE_id_attribute_domain(const ID *id, const CustomDataLayer *layer)
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-09-06 09:27:28 +02:00
|
|
|
const CustomData *customdata = info[domain].customdata;
|
|
|
|
if (customdata == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (ARRAY_HAS_ITEM((CustomDataLayer *)layer, customdata->layers, customdata->totlayer)) {
|
2022-06-01 06:38:06 +02:00
|
|
|
return static_cast<eAttrDomain>(domain);
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-15 10:23:28 +02:00
|
|
|
BLI_assert_msg(0, "Custom data layer not found in geometry");
|
2022-06-01 06:38:06 +02:00
|
|
|
return static_cast<eAttrDomain>(ATTR_DOMAIN_POINT);
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int BKE_id_attribute_data_length(ID *id, CustomDataLayer *layer)
|
|
|
|
{
|
2022-04-21 12:39:09 +02:00
|
|
|
/* When in mesh editmode, attributes point to bmesh customdata layers, the attribute data is
|
|
|
|
* empty since custom data is stored per element instead of a single array there (same es UVs
|
|
|
|
* etc.), see D11998. */
|
|
|
|
switch (GS(id->name)) {
|
|
|
|
case ID_ME: {
|
|
|
|
Mesh *mesh = (Mesh *)id;
|
2022-05-30 18:06:39 +02:00
|
|
|
if (mesh->edit_mesh != nullptr) {
|
2022-04-21 12:39:09 +02:00
|
|
|
return 0;
|
|
|
|
}
|
2022-08-31 07:58:33 +02:00
|
|
|
break;
|
2022-04-21 12:39:09 +02:00
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-07-03 15:30:04 +02:00
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-09-06 09:27:28 +02:00
|
|
|
const CustomData *customdata = info[domain].customdata;
|
|
|
|
if (customdata == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (ARRAY_HAS_ITEM((CustomDataLayer *)layer, customdata->layers, customdata->totlayer)) {
|
2020-07-03 15:30:04 +02:00
|
|
|
return info[domain].length;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-15 10:23:28 +02:00
|
|
|
BLI_assert_msg(0, "Custom data layer not found in geometry");
|
2020-07-03 15:30:04 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-08 10:42:21 +02:00
|
|
|
bool BKE_id_attribute_required(const ID *id, const char *name)
|
2020-08-04 12:52:04 +02:00
|
|
|
{
|
|
|
|
switch (GS(id->name)) {
|
2022-09-15 20:14:31 +02:00
|
|
|
case ID_PT:
|
|
|
|
return BKE_pointcloud_attribute_required((const PointCloud *)id, name);
|
|
|
|
case ID_CV:
|
|
|
|
return BKE_curves_attribute_required((const Curves *)id, name);
|
Mesh: Move positions to a generic attribute
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
2023-01-10 06:10:43 +01:00
|
|
|
case ID_ME:
|
|
|
|
return BKE_mesh_attribute_required(name);
|
2020-08-04 12:52:04 +02:00
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-03 15:30:04 +02:00
|
|
|
CustomDataLayer *BKE_id_attributes_active_get(ID *id)
|
|
|
|
{
|
|
|
|
int active_index = *BKE_id_attributes_active_index_p(id);
|
2022-04-05 20:42:55 +02:00
|
|
|
if (active_index > BKE_id_attributes_length(id, ATTR_DOMAIN_MASK_ALL, CD_MASK_PROP_ALL)) {
|
2020-07-03 15:30:04 +02:00
|
|
|
active_index = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
int index = 0;
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2020-07-03 15:30:04 +02:00
|
|
|
CustomData *customdata = info[domain].customdata;
|
2022-09-06 09:27:28 +02:00
|
|
|
if (customdata == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
for (int i = 0; i < customdata->totlayer; i++) {
|
|
|
|
CustomDataLayer *layer = &customdata->layers[i];
|
|
|
|
if (CD_MASK_PROP_ALL & CD_TYPE_AS_MASK(layer->type)) {
|
|
|
|
if (index == active_index) {
|
|
|
|
if (BKE_attribute_allow_procedural_access(layer->name)) {
|
|
|
|
return layer;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
2022-09-06 09:27:28 +02:00
|
|
|
return nullptr;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
2022-09-06 09:27:28 +02:00
|
|
|
index++;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
2022-11-10 21:38:49 +01:00
|
|
|
void BKE_id_attributes_active_set(ID *id, const char *name)
|
2020-07-03 15:30:04 +02:00
|
|
|
{
|
2022-11-10 21:38:49 +01:00
|
|
|
const CustomDataLayer *layer = BKE_id_attribute_search(
|
|
|
|
id, name, CD_MASK_PROP_ALL, ATTR_DOMAIN_MASK_ALL);
|
|
|
|
BLI_assert(layer != nullptr);
|
2020-07-03 15:30:04 +02:00
|
|
|
|
2022-11-10 21:38:49 +01:00
|
|
|
const int index = BKE_id_attribute_to_index(id, layer, ATTR_DOMAIN_MASK_ALL, CD_MASK_PROP_ALL);
|
|
|
|
*BKE_id_attributes_active_index_p(id) = index;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int *BKE_id_attributes_active_index_p(ID *id)
|
|
|
|
{
|
|
|
|
switch (GS(id->name)) {
|
|
|
|
case ID_PT: {
|
|
|
|
return &((PointCloud *)id)->attributes_active_index;
|
|
|
|
}
|
|
|
|
case ID_ME: {
|
|
|
|
return &((Mesh *)id)->attributes_active_index;
|
|
|
|
}
|
Curves: Rename "Hair" types, variables, and functions to "Curves"
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
2022-02-07 18:55:54 +01:00
|
|
|
case ID_CV: {
|
|
|
|
return &((Curves *)id)->attributes_active_index;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
2023-10-10 16:49:30 +02:00
|
|
|
case ID_GP: {
|
|
|
|
return &((GreasePencil *)id)->attributes_active_index;
|
|
|
|
}
|
2020-07-03 15:30:04 +02:00
|
|
|
default:
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
CustomData *BKE_id_attributes_iterator_next_domain(ID *id, CustomDataLayer *layers)
|
|
|
|
{
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
bool use_next = (layers == nullptr);
|
2020-07-03 15:30:04 +02:00
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2020-07-03 15:30:04 +02:00
|
|
|
CustomData *customdata = info[domain].customdata;
|
2022-09-06 09:27:28 +02:00
|
|
|
if (customdata == nullptr) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (customdata->layers && customdata->totlayer) {
|
2020-07-03 15:30:04 +02:00
|
|
|
if (customdata->layers == layers) {
|
|
|
|
use_next = true;
|
|
|
|
}
|
|
|
|
else if (use_next) {
|
|
|
|
return customdata;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2020-07-03 15:30:04 +02:00
|
|
|
}
|
2022-04-05 20:42:55 +02:00
|
|
|
|
|
|
|
CustomDataLayer *BKE_id_attribute_from_index(ID *id,
|
|
|
|
int lookup_index,
|
2022-06-01 06:38:06 +02:00
|
|
|
eAttrDomainMask domain_mask,
|
|
|
|
eCustomDataMask layer_mask)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
int index = 0;
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int domain : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-04-05 20:42:55 +02:00
|
|
|
CustomData *customdata = info[domain].customdata;
|
|
|
|
|
2022-09-25 10:33:28 +02:00
|
|
|
if (!customdata || !((1 << int(domain)) & domain_mask)) {
|
2022-04-05 20:42:55 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i = 0; i < customdata->totlayer; i++) {
|
|
|
|
if (!(layer_mask & CD_TYPE_AS_MASK(customdata->layers[i].type)) ||
|
2022-04-11 18:40:13 +02:00
|
|
|
(customdata->layers[i].flag & CD_FLAG_TEMPORARY))
|
|
|
|
{
|
2022-04-05 20:42:55 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index == lookup_index) {
|
|
|
|
return customdata->layers + i;
|
|
|
|
}
|
|
|
|
|
|
|
|
index++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
return nullptr;
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2023-05-27 07:10:58 +02:00
|
|
|
/**
|
|
|
|
* Get list of domain types but with ATTR_DOMAIN_FACE and
|
2022-04-05 20:42:55 +02:00
|
|
|
* ATTR_DOMAIN_CORNER swapped.
|
|
|
|
*/
|
2022-06-01 06:38:06 +02:00
|
|
|
static void get_domains_types(eAttrDomain domains[ATTR_DOMAIN_NUM])
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2022-05-30 18:06:39 +02:00
|
|
|
for (const int i : IndexRange(ATTR_DOMAIN_NUM)) {
|
2022-06-01 06:38:06 +02:00
|
|
|
domains[i] = static_cast<eAttrDomain>(i);
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Swap corner and face. */
|
2023-01-09 17:12:03 +01:00
|
|
|
std::swap(domains[ATTR_DOMAIN_FACE], domains[ATTR_DOMAIN_CORNER]);
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2022-05-30 18:06:39 +02:00
|
|
|
int BKE_id_attribute_to_index(const ID *id,
|
2022-04-05 20:42:55 +02:00
|
|
|
const CustomDataLayer *layer,
|
2022-06-01 06:38:06 +02:00
|
|
|
eAttrDomainMask domain_mask,
|
|
|
|
eCustomDataMask layer_mask)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
|
|
|
if (!layer) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
DomainInfo info[ATTR_DOMAIN_NUM];
|
2022-06-01 06:38:06 +02:00
|
|
|
eAttrDomain domains[ATTR_DOMAIN_NUM];
|
2022-04-05 20:42:55 +02:00
|
|
|
get_domains_types(domains);
|
|
|
|
get_domains(id, info);
|
|
|
|
|
|
|
|
int index = 0;
|
|
|
|
for (int i = 0; i < ATTR_DOMAIN_NUM; i++) {
|
|
|
|
if (!(domain_mask & (1 << domains[i])) || !info[domains[i]].customdata) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-06-08 10:42:21 +02:00
|
|
|
const CustomData *cdata = info[domains[i]].customdata;
|
2022-04-05 20:42:55 +02:00
|
|
|
for (int j = 0; j < cdata->totlayer; j++) {
|
2022-06-08 10:42:21 +02:00
|
|
|
const CustomDataLayer *layer_iter = cdata->layers + j;
|
2022-04-05 20:42:55 +02:00
|
|
|
|
|
|
|
if (!(CD_TYPE_AS_MASK(layer_iter->type) & layer_mask) ||
|
2022-04-11 18:40:13 +02:00
|
|
|
(layer_iter->flag & CD_FLAG_TEMPORARY)) {
|
2022-04-05 20:42:55 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (layer == layer_iter) {
|
|
|
|
return index;
|
|
|
|
}
|
|
|
|
|
|
|
|
index++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2022-12-15 21:18:57 +01:00
|
|
|
const char *BKE_id_attributes_active_color_name(const ID *id)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
if (GS(id->name) == ID_ME) {
|
|
|
|
return reinterpret_cast<const Mesh *>(id)->active_color_attribute;
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
2022-12-15 21:18:57 +01:00
|
|
|
return nullptr;
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2022-12-15 21:18:57 +01:00
|
|
|
const char *BKE_id_attributes_default_color_name(const ID *id)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
if (GS(id->name) == ID_ME) {
|
|
|
|
return reinterpret_cast<const Mesh *>(id)->default_color_attribute;
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
2022-12-15 21:18:57 +01:00
|
|
|
return nullptr;
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2022-12-15 21:18:57 +01:00
|
|
|
void BKE_id_attributes_active_color_set(ID *id, const char *name)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
switch (GS(id->name)) {
|
|
|
|
case ID_ME: {
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
|
|
|
MEM_SAFE_FREE(mesh->active_color_attribute);
|
|
|
|
if (name) {
|
|
|
|
mesh->active_color_attribute = BLI_strdup(name);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2022-12-15 21:18:57 +01:00
|
|
|
void BKE_id_attributes_default_color_set(ID *id, const char *name)
|
2022-04-05 20:42:55 +02:00
|
|
|
{
|
2022-12-15 21:18:57 +01:00
|
|
|
switch (GS(id->name)) {
|
|
|
|
case ID_ME: {
|
|
|
|
Mesh *mesh = reinterpret_cast<Mesh *>(id);
|
|
|
|
MEM_SAFE_FREE(mesh->default_color_attribute);
|
|
|
|
if (name) {
|
|
|
|
mesh->default_color_attribute = BLI_strdup(name);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2022-04-05 20:42:55 +02:00
|
|
|
}
|
|
|
|
|
2023-07-11 22:50:27 +02:00
|
|
|
const CustomDataLayer *BKE_id_attributes_color_find(const ID *id, const char *name)
|
2022-04-08 16:37:35 +02:00
|
|
|
{
|
2023-07-11 22:50:27 +02:00
|
|
|
return BKE_id_attribute_search(
|
|
|
|
const_cast<ID *>(id), name, CD_MASK_COLOR_ALL, ATTR_DOMAIN_MASK_COLOR);
|
2022-04-08 16:37:35 +02:00
|
|
|
}
|
|
|
|
|
Mesh: Move UV layers to generic attributes
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
2023-01-10 06:47:04 +01:00
|
|
|
const char *BKE_uv_map_vert_select_name_get(const char *uv_map_name, char *buffer)
|
|
|
|
{
|
|
|
|
BLI_assert(strlen(UV_VERTSEL_NAME) == 2);
|
|
|
|
BLI_assert(strlen(uv_map_name) < MAX_CUSTOMDATA_LAYER_NAME - 4);
|
|
|
|
BLI_snprintf(buffer, MAX_CUSTOMDATA_LAYER_NAME, ".%s.%s", UV_VERTSEL_NAME, uv_map_name);
|
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *BKE_uv_map_edge_select_name_get(const char *uv_map_name, char *buffer)
|
|
|
|
{
|
|
|
|
BLI_assert(strlen(UV_EDGESEL_NAME) == 2);
|
|
|
|
BLI_assert(strlen(uv_map_name) < MAX_CUSTOMDATA_LAYER_NAME - 4);
|
|
|
|
BLI_snprintf(buffer, MAX_CUSTOMDATA_LAYER_NAME, ".%s.%s", UV_EDGESEL_NAME, uv_map_name);
|
|
|
|
return buffer;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *BKE_uv_map_pin_name_get(const char *uv_map_name, char *buffer)
|
|
|
|
{
|
|
|
|
BLI_assert(strlen(UV_PINNED_NAME) == 2);
|
|
|
|
BLI_assert(strlen(uv_map_name) < MAX_CUSTOMDATA_LAYER_NAME - 4);
|
|
|
|
BLI_snprintf(buffer, MAX_CUSTOMDATA_LAYER_NAME, ".%s.%s", UV_PINNED_NAME, uv_map_name);
|
|
|
|
return buffer;
|
|
|
|
}
|