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 */
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2019-02-17 22:08:12 +01:00
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
|
|
|
* \brief CustomData interface, see also DNA_customdata_types.h.
|
2011-02-18 14:05:18 +01:00
|
|
|
*/
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2012-02-17 19:59:41 +01:00
|
|
|
#pragma once
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BLI_cpp_type.hh"
|
2023-04-13 14:57:57 +02:00
|
|
|
#include "BLI_implicit_sharing.h"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BLI_set.hh"
|
|
|
|
#include "BLI_span.hh"
|
|
|
|
#include "BLI_string_ref.hh"
|
2013-05-30 04:16:22 +02:00
|
|
|
#include "BLI_sys_types.h"
|
2013-01-08 15:25:17 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2023-11-16 11:41:55 +01:00
|
|
|
#include "BLI_vector.hh"
|
2011-12-25 22:27:23 +01:00
|
|
|
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
#include "DNA_customdata_types.h"
|
|
|
|
|
2020-09-30 03:51:13 +02:00
|
|
|
struct BlendDataReader;
|
|
|
|
struct BlendWriter;
|
2023-11-16 12:00:12 +01:00
|
|
|
struct BMesh;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
struct CustomData_MeshMasks;
|
2023-11-16 12:00:12 +01:00
|
|
|
struct CustomData;
|
|
|
|
struct CustomDataTransferLayerMap;
|
2019-01-28 11:08:24 +01:00
|
|
|
struct ID;
|
2023-11-16 12:00:12 +01:00
|
|
|
struct MeshPairRemap;
|
|
|
|
|
|
|
|
using eCustomDataMask = uint64_t;
|
2006-08-28 03:12:36 +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
|
|
|
/* These names are used as prefixes for UV layer names to find the associated boolean
|
2023-09-14 05:25:24 +02:00
|
|
|
* layers. They should never be longer than 2 chars, as #MAX_CUSTOMDATA_LAYER_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
|
|
|
* has 4 extra bytes above what can be used for the base layer name, and these
|
|
|
|
* prefixes are placed between 2 '.'s at the start of the layer name.
|
2023-09-14 05:25:24 +02:00
|
|
|
* For example The uv vert selection layer of a layer named `UVMap.001`
|
|
|
|
* will be called `.vs.UVMap.001`. */
|
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
|
|
|
#define UV_VERTSEL_NAME "vs"
|
|
|
|
#define UV_EDGESEL_NAME "es"
|
|
|
|
#define UV_PINNED_NAME "pn"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* UV map related customdata offsets into BMesh attribute blocks. See #BM_uv_map_get_offsets.
|
2023-11-16 11:41:55 +01:00
|
|
|
* Defined in #BKE_customdata.hh to avoid including bmesh.h in many unrelated areas.
|
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
|
|
|
* An offset of -1 means that the corresponding layer does not exist.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
struct BMUVOffsets {
|
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
|
|
|
int uv;
|
|
|
|
int select_vert;
|
|
|
|
int select_edge;
|
|
|
|
int pin;
|
2023-11-16 12:00:12 +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
|
|
|
|
2021-06-26 13:35:18 +02:00
|
|
|
/* A data type large enough to hold 1 element from any custom-data layer type. */
|
2023-11-16 12:00:12 +01:00
|
|
|
struct CDBlockBytes {
|
2012-05-12 22:39:39 +02:00
|
|
|
unsigned char data[64];
|
2023-11-16 12:00:12 +01:00
|
|
|
};
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
extern const CustomData_MeshMasks CD_MASK_BAREMESH;
|
|
|
|
extern const CustomData_MeshMasks CD_MASK_BAREMESH_ORIGINDEX;
|
|
|
|
extern const CustomData_MeshMasks CD_MASK_MESH;
|
|
|
|
extern const CustomData_MeshMasks CD_MASK_DERIVEDMESH;
|
|
|
|
extern const CustomData_MeshMasks CD_MASK_BMESH;
|
|
|
|
extern const CustomData_MeshMasks CD_MASK_EVERYTHING;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
/* for ORIGINDEX layer type, indicates no original index for this element */
|
|
|
|
#define ORIGINDEX_NONE -1
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2012-03-09 01:41:09 +01:00
|
|
|
/* initializes a CustomData object with the same layer setup as source and
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
* memory space for totelem elements. mask must be an array of length
|
|
|
|
* CD_NUMTYPES elements, that indicate if a layer can be copied. */
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2019-04-18 07:21:26 +02:00
|
|
|
/** Add/copy/merge allocation types. */
|
2018-05-30 10:28:24 +02:00
|
|
|
typedef enum eCDAllocType {
|
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
|
|
|
/** Allocate and set to default, which is usually just zeroed memory. */
|
|
|
|
CD_SET_DEFAULT = 2,
|
|
|
|
/**
|
|
|
|
* Default construct new layer values. Does nothing for trivial types. This should be used
|
|
|
|
* if all layer values will be set by the caller after creating the layer.
|
|
|
|
*/
|
|
|
|
CD_CONSTRUCT = 5,
|
2018-05-30 10:28:24 +02:00
|
|
|
} eCDAllocType;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2022-06-01 06:38:06 +02:00
|
|
|
#define CD_TYPE_AS_MASK(_type) (eCustomDataMask)((eCustomDataMask)1 << (eCustomDataMask)(_type))
|
2011-12-23 21:30:23 +01:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void customData_mask_layers__print(const CustomData_MeshMasks *mask);
|
2012-09-15 03:52:28 +02:00
|
|
|
|
2015-02-23 03:51:55 +01:00
|
|
|
typedef void (*cd_interp)(
|
|
|
|
const void **sources, const float *weights, const float *sub_weights, int count, void *dest);
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
typedef void (*cd_copy)(const void *source, void *dest, int count);
|
2022-01-07 01:38:08 +01:00
|
|
|
typedef bool (*cd_validate)(void *item, uint totitems, bool do_fixes);
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Update mask_dst with layers defined in mask_src (equivalent to a bit-wise OR).
|
|
|
|
*/
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
void CustomData_MeshMasks_update(CustomData_MeshMasks *mask_dst,
|
|
|
|
const CustomData_MeshMasks *mask_src);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Return True if all layers set in \a mask_required are also set in \a mask_ref
|
|
|
|
*/
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
bool CustomData_MeshMasks_are_matching(const CustomData_MeshMasks *mask_ref,
|
|
|
|
const CustomData_MeshMasks *mask_required);
|
|
|
|
|
2012-03-18 08:38:51 +01:00
|
|
|
/**
|
|
|
|
* Checks if the layer at physical offset \a layer_n (in data->layers) support math
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
* the below operations.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_layer_has_math(const CustomData *data, int layer_n);
|
|
|
|
bool CustomData_layer_has_interp(const CustomData *data, int layer_n);
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
|
2012-10-20 19:31:07 +02:00
|
|
|
/**
|
2021-12-07 07:19:15 +01:00
|
|
|
* Checks if any of the custom-data layers has math.
|
2012-10-20 19:31:07 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_has_math(const CustomData *data);
|
|
|
|
bool CustomData_has_interp(const CustomData *data);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* A non bmesh version would have to check `layer->data`.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_bmesh_has_free(const CustomData *data);
|
2012-10-20 19:31:07 +02:00
|
|
|
|
2015-02-18 20:00:23 +01:00
|
|
|
/**
|
2021-12-07 07:19:15 +01:00
|
|
|
* Checks if any of the custom-data layers is referenced.
|
2015-02-18 20:00:23 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_has_referenced(const CustomData *data);
|
2015-02-18 20:00:23 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-03-27 03:08:14 +02:00
|
|
|
* Copies the "value" (e.g. `mloopuv` UV or `mloopcol` colors) from one block to
|
2012-03-03 21:19:11 +01:00
|
|
|
* another, while not overwriting anything else (e.g. flags). probably only
|
2023-03-27 03:08:14 +02:00
|
|
|
* implemented for `mloopuv/mloopcol`, for now.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
void CustomData_data_copy_value(eCustomDataType type, const void *source, void *dest);
|
|
|
|
void CustomData_data_set_default_value(eCustomDataType type, void *elem);
|
2009-08-12 05:51:28 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-03-27 03:08:14 +02:00
|
|
|
* Mixes the "value" (e.g. `mloopuv` UV or `mloopcol` colors) from one block into
|
2021-12-07 07:19:15 +01:00
|
|
|
* another, while not overwriting anything else (e.g. flags).
|
|
|
|
*/
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
void CustomData_data_mix_value(
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type, const void *source, void *dest, int mixmode, float mixfactor);
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-03-27 03:08:14 +02:00
|
|
|
* Compares if data1 is equal to data2. type is a valid #CustomData type
|
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
|
|
|
* enum (e.g. #CD_PROP_FLOAT). the layer type's equal function is used to compare
|
2021-12-07 07:19:15 +01:00
|
|
|
* the data, if it exists, otherwise #memcmp is used.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
bool CustomData_data_equals(eCustomDataType type, const void *data1, const void *data2);
|
|
|
|
void CustomData_data_initminmax(eCustomDataType type, void *min, void *max);
|
|
|
|
void CustomData_data_dominmax(eCustomDataType type, const void *data, void *min, void *max);
|
|
|
|
void CustomData_data_multiply(eCustomDataType type, void *data, float fac);
|
|
|
|
void CustomData_data_add(eCustomDataType type, void *data1, const void *data2);
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-04-13 14:57:57 +02:00
|
|
|
* Initializes a CustomData object with the same layer setup as source. `mask` is a bit-field where
|
|
|
|
* `(mask & (1 << (layer type)))` indicates if a layer should be copied or not. Data layers using
|
|
|
|
* implicit-sharing will not actually be copied but will be shared between source and destination.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_copy(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataMask mask,
|
2018-05-30 10:28:24 +02:00
|
|
|
int totelem);
|
2023-04-13 14:57:57 +02:00
|
|
|
/**
|
|
|
|
* Initializes a CustomData object with the same layers as source. The data is not copied from the
|
|
|
|
* source. Instead, the new layers are initialized using the given `alloctype`.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_copy_layout(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2023-04-13 14:57:57 +02:00
|
|
|
eCustomDataMask mask,
|
|
|
|
eCDAllocType alloctype,
|
|
|
|
int totelem);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2023-07-31 03:50:54 +02:00
|
|
|
/* BMESH_TODO, not really a public function but `readfile.cc` needs it. */
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_update_typemap(CustomData *data);
|
2011-05-11 04:14:43 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-04-13 14:57:57 +02:00
|
|
|
* Copies all layers from source to destination that don't exist there yet.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_merge(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataMask mask,
|
2018-05-30 10:28:24 +02:00
|
|
|
int totelem);
|
2023-04-13 14:57:57 +02:00
|
|
|
/**
|
|
|
|
* Copies all layers from source to destination that don't exist there yet. The layer data is not
|
|
|
|
* copied. Instead the newly created layers are initialized using the given `alloctype`.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_merge_layout(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2023-04-13 14:57:57 +02:00
|
|
|
eCustomDataMask mask,
|
|
|
|
eCDAllocType alloctype,
|
|
|
|
int totelem);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2022-09-12 18:35:33 +02:00
|
|
|
* Reallocate custom data to a new element count. If the new size is larger, the new values use
|
|
|
|
* the #CD_CONSTRUCT behavior, so trivial types must be initialized by the caller. After being
|
|
|
|
* resized, the #CustomData does not contain any referenced layers.
|
2015-08-25 10:29:40 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_realloc(CustomData *data,
|
2023-10-16 18:41:07 +02:00
|
|
|
int old_size,
|
|
|
|
int new_size,
|
|
|
|
eCDAllocType alloctype = CD_CONSTRUCT);
|
2015-08-25 10:29:40 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-04-13 14:57:57 +02:00
|
|
|
* BMesh version of CustomData_merge_layout; merges the layouts of source and `dest`,
|
2021-12-07 07:19:15 +01:00
|
|
|
* then goes through the mesh and makes sure all the custom-data blocks are
|
|
|
|
* consistent with the new layout.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_bmesh_merge_layout(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2023-04-13 14:57:57 +02:00
|
|
|
eCustomDataMask mask,
|
|
|
|
eCDAllocType alloctype,
|
2023-11-16 12:00:12 +01:00
|
|
|
BMesh *bm,
|
2023-04-13 14:57:57 +02:00
|
|
|
char htype);
|
2009-06-23 07:35:49 +02:00
|
|
|
|
2022-10-13 19:42:12 +02:00
|
|
|
/**
|
|
|
|
* Remove layers that aren't stored in BMesh or are stored as flags on BMesh.
|
|
|
|
* The `layers` array of the returned #CustomData must be freed, but may be null.
|
|
|
|
* Used during conversion of #Mesh data to #BMesh storage format.
|
|
|
|
*/
|
|
|
|
CustomData CustomData_shallow_copy_remove_non_bmesh_attributes(const CustomData *src,
|
|
|
|
eCustomDataMask mask);
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* NULL's all members and resets the #CustomData.typemap.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_reset(CustomData *data);
|
2012-10-31 10:50:24 +01:00
|
|
|
|
2019-11-24 15:14:39 +01:00
|
|
|
/**
|
|
|
|
* Frees data associated with a CustomData object (doesn't free the object itself, though).
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_free(CustomData *data, int totelem);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Same as above, but only frees layers which matches the given mask.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_free_typemask(CustomData *data, int totelem, eCustomDataMask mask);
|
2015-02-18 20:00:23 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-04-13 14:57:57 +02:00
|
|
|
* Adds a layer of the given type to the #CustomData object. The new layer is initialized based on
|
|
|
|
* the given alloctype.
|
|
|
|
* \return The layer data.
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_add_layer(CustomData *data,
|
2023-03-14 15:30:26 +01:00
|
|
|
eCustomDataType type,
|
|
|
|
eCDAllocType alloctype,
|
|
|
|
int totelem);
|
2023-04-13 14:57:57 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds a layer of the given type to the #CustomData object. The new layer takes ownership of the
|
|
|
|
* passed in `layer_data`. If a #ImplicitSharingInfoHandle is passed in, its user count is
|
|
|
|
* increased.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const void *CustomData_add_layer_with_data(CustomData *data,
|
2023-03-14 15:30:26 +01:00
|
|
|
eCustomDataType type,
|
|
|
|
void *layer_data,
|
2023-04-13 14:57:57 +02:00
|
|
|
int totelem,
|
|
|
|
const ImplicitSharingInfoHandle *sharing_info);
|
2023-03-14 15:30:26 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Same as above but accepts a name.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_add_layer_named(
|
|
|
|
CustomData *data, eCustomDataType type, eCDAllocType alloctype, int totelem, const char *name);
|
2023-04-13 14:57:57 +02:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
const void *CustomData_add_layer_named_with_data(CustomData *data,
|
2023-03-14 15:30:26 +01:00
|
|
|
eCustomDataType type,
|
|
|
|
void *layer_data,
|
|
|
|
int totelem,
|
2023-04-13 14:57:57 +02:00
|
|
|
const char *name,
|
|
|
|
const ImplicitSharingInfoHandle *sharing_info);
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_add_layer_anonymous(CustomData *data,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
2021-09-09 12:54:20 +02:00
|
|
|
eCDAllocType alloctype,
|
|
|
|
int totelem,
|
2023-01-05 14:05:30 +01:00
|
|
|
const AnonymousAttributeIDHandle *anonymous_id);
|
2023-04-13 14:57:57 +02:00
|
|
|
const void *CustomData_add_layer_anonymous_with_data(
|
2023-11-16 12:00:12 +01:00
|
|
|
CustomData *data,
|
2023-04-13 14:57:57 +02:00
|
|
|
eCustomDataType type,
|
|
|
|
const AnonymousAttributeIDHandle *anonymous_id,
|
|
|
|
int totelem,
|
|
|
|
void *layer_data,
|
|
|
|
const ImplicitSharingInfoHandle *sharing_info);
|
2006-11-11 17:38:37 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Frees the active or first data layer with the give type.
|
2013-11-19 17:38:18 +01:00
|
|
|
* returns 1 on success, 0 if no layer with the given type is found
|
2006-11-12 00:23:15 +01:00
|
|
|
*
|
2021-12-07 07:19:15 +01:00
|
|
|
* In edit-mode, use #EDBM_data_layer_free instead of this function.
|
2006-11-11 17:38:37 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_free_layer(CustomData *data, eCustomDataType type, int totelem, int index);
|
|
|
|
bool CustomData_free_layer_named(CustomData *data, const char *name, const int totelem);
|
2006-12-23 18:07:02 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Frees the layer index with the give type.
|
|
|
|
* returns 1 on success, 0 if no layer with the given type is found.
|
2006-12-23 18:07:02 +01:00
|
|
|
*
|
2021-12-07 07:19:15 +01:00
|
|
|
* In edit-mode, use #EDBM_data_layer_free instead of this function.
|
2006-12-23 18:07:02 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_free_layer_active(CustomData *data, eCustomDataType type, int totelem);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Same as above, but free all layers with type.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_free_layers(CustomData *data, eCustomDataType type, int totelem);
|
2006-11-11 17:38:37 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns true if a layer with the specified type exists.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_has_layer(const CustomData *data, eCustomDataType type);
|
|
|
|
bool CustomData_has_layer_named(const CustomData *data, eCustomDataType type, const char *name);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Returns the number of layers with this type.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
int CustomData_number_of_layers(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_number_of_anonymous_layers(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_number_of_layers_typemask(const CustomData *data, eCustomDataMask mask);
|
2006-12-12 22:29:09 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Set the #CD_FLAG_NOCOPY flag in custom data layers where the mask is
|
|
|
|
* zero for the layer type, so only layer types specified by the mask will be copied
|
2006-12-05 18:42:03 +01:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_set_only_copy(const CustomData *data, eCustomDataMask mask);
|
2006-12-05 18:42:03 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Copies data from one CustomData object to another
|
2006-08-28 03:12:36 +02:00
|
|
|
* objects need not be compatible, each source layer is copied to the
|
2021-12-07 07:19:15 +01:00
|
|
|
* first dest layer of correct type (if there is none, the layer is skipped).
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_copy_data(
|
|
|
|
const CustomData *source, CustomData *dest, int source_index, int dest_index, int count);
|
|
|
|
void CustomData_copy_data_layer(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2021-02-21 23:57:03 +01:00
|
|
|
int src_layer_index,
|
|
|
|
int dst_layer_index,
|
|
|
|
int src_index,
|
|
|
|
int dst_index,
|
|
|
|
int count);
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_copy_data_named(
|
|
|
|
const CustomData *source, CustomData *dest, int source_index, int dest_index, int count);
|
2023-03-29 17:10:49 +02:00
|
|
|
void CustomData_copy_elements(eCustomDataType type,
|
|
|
|
void *src_data_ofs,
|
|
|
|
void *dst_data_ofs,
|
|
|
|
int count);
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_copy_data(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2018-06-17 17:05:51 +02:00
|
|
|
void *src_block,
|
2011-12-28 10:14:09 +01:00
|
|
|
void **dest_block);
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_copy_data_exclude_by_type(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2019-11-26 06:19:56 +01:00
|
|
|
void *src_block,
|
|
|
|
void **dest_block,
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataMask mask_exclude);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Copies data of a single layer of a given type.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_copy_layer_type_data(const CustomData *source,
|
|
|
|
CustomData *destination,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
2018-09-25 12:27:43 +02:00
|
|
|
int source_index,
|
|
|
|
int destination_index,
|
|
|
|
int count);
|
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-10-11 11:34:29 +02:00
|
|
|
* Frees data in a #CustomData object. This is only expected to be called if the data layers are
|
|
|
|
* not shared (#CustomData_ensure_layers_are_mutable).
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_free_elem(CustomData *data, int index, int count);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Interpolate given custom data source items into a single destination one.
|
2006-08-28 03:12:36 +02:00
|
|
|
*
|
2021-12-07 07:19:15 +01:00
|
|
|
* \param src_indices: Indices of every source items to interpolate into the destination one.
|
|
|
|
* \param weights: The weight to apply to each source value individually. If NULL, they will be
|
|
|
|
* averaged.
|
|
|
|
* \param sub_weights: The weights of sub-items, only used to affect each corners of a
|
|
|
|
* tessellated face data (should always be and array of four values).
|
|
|
|
* \param count: The number of source items to interpolate.
|
|
|
|
* \param dest_index: Index of the destination item, in which to put the result of the
|
|
|
|
* interpolation.
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_interp(const CustomData *source,
|
|
|
|
CustomData *dest,
|
2016-05-16 19:07:40 +02:00
|
|
|
const int *src_indices,
|
|
|
|
const float *weights,
|
|
|
|
const float *sub_weights,
|
2015-02-23 03:51:55 +01:00
|
|
|
int count,
|
|
|
|
int dest_index);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* \note src_blocks_ofs & dst_block_ofs
|
|
|
|
* must be pointers to the data, offset by layer->offset already.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_interp_n(CustomData *data,
|
2015-02-23 03:51:55 +01:00
|
|
|
const void **src_blocks,
|
|
|
|
const float *weights,
|
2015-02-23 03:43:09 +01:00
|
|
|
const float *sub_weights,
|
|
|
|
int count,
|
|
|
|
void *dst_block_ofs,
|
|
|
|
int n);
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_interp(CustomData *data,
|
2015-02-23 03:51:55 +01:00
|
|
|
const void **src_blocks,
|
|
|
|
const float *weights,
|
|
|
|
const float *sub_weights,
|
|
|
|
int count,
|
2015-02-23 03:43:09 +01:00
|
|
|
void *dst_block);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Swap data inside each item, for all layers.
|
|
|
|
* This only applies to item types that may store several sub-item data
|
|
|
|
* (e.g. corner data [UVs, VCol, ...] of tessellated faces).
|
|
|
|
*
|
|
|
|
* \param corner_indices: A mapping 'new_index -> old_index' of sub-item data.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_swap_corners(CustomData *data, int index, const int *corner_indices);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2023-09-12 13:03:01 +02:00
|
|
|
/**
|
|
|
|
* Custom data layers can be shared through implicit sharing (`BLI_implicit_sharing.h`). This
|
|
|
|
* function makes sure that the layer is unshared if it was shared, which makes it mutable.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_ensure_data_is_mutable(CustomDataLayer *layer, int totelem);
|
|
|
|
void CustomData_ensure_layers_are_mutable(CustomData *data, int totelem);
|
2023-09-12 13:03:01 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-01-14 00:21:20 +01:00
|
|
|
* Retrieve a pointer to an element of the active layer of the given \a type, chosen by the
|
|
|
|
* \a index, if it exists.
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_get_for_write(CustomData *data, int index, eCustomDataType type, int totelem);
|
2023-01-14 00:21:20 +01:00
|
|
|
/**
|
|
|
|
* Retrieve a pointer to an element of the \a nth layer of the given \a type, chosen by the
|
|
|
|
* \a index, if it exists.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
void *CustomData_get_n_for_write(
|
2023-11-16 12:00:12 +01:00
|
|
|
CustomData *data, eCustomDataType type, int index, int n, int totelem);
|
2021-12-07 07:19:15 +01:00
|
|
|
|
|
|
|
/* BMesh Custom Data Functions.
|
|
|
|
* Should replace edit-mesh ones with these as well, due to more efficient memory alloc. */
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_bmesh_get(const CustomData *data, void *block, eCustomDataType type);
|
|
|
|
void *CustomData_bmesh_get_n(const CustomData *data, void *block, eCustomDataType type, int n);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Gets from the layer at physical index `n`,
|
|
|
|
* \note doesn't check type.
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void *CustomData_bmesh_get_layer_n(const CustomData *data, void *block, int n);
|
Brought Extrude all the way back. The contextual menu works,
as does only edges and individual faces extrude (individual vert
extrude already did).
Note that I need to port this, after we all figure out how to handle
operators with variable transform follow-ons.
I also implemented the merge->collapse function, which is currently
accessable under ctrl->v, Bmesh Test Operator. I still need to
implement the other merge modes, and properly hook everything into
the merge menu tool, which I plan on doing soon (tomorrow hopefully).
The cool thing about the collapse tool, is not only does it handle (all)
UV layers, it handles vcols as well. To do this, I had to add a few math
functions to the customdata API, which seem to be working well.
2009-08-11 09:49:35 +02:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_set_layer_name(CustomData *data, eCustomDataType type, int n, const char *name);
|
|
|
|
const char *CustomData_get_layer_name(const CustomData *data, eCustomDataType type, int n);
|
2011-05-10 19:01:26 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2023-01-14 00:21:20 +01:00
|
|
|
* Retrieve the data array of the active layer of the given \a type, if it exists. Return null
|
|
|
|
* otherwise.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const void *CustomData_get_layer(const CustomData *data, eCustomDataType type);
|
|
|
|
void *CustomData_get_layer_for_write(CustomData *data, eCustomDataType type, int totelem);
|
2023-01-14 00:21:20 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Retrieve the data array of the \a nth layer of the given \a type, if it exists. Return null
|
|
|
|
* otherwise.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const void *CustomData_get_layer_n(const CustomData *data, eCustomDataType type, int n);
|
|
|
|
void *CustomData_get_layer_n_for_write(CustomData *data, eCustomDataType type, int n, int totelem);
|
2023-01-14 00:21:20 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Retrieve the data array of the layer with the given \a name and \a type, if it exists. Return
|
|
|
|
* null otherwise.
|
2006-08-28 03:12:36 +02:00
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const void *CustomData_get_layer_named(const CustomData *data,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
|
|
|
const char *name);
|
2023-01-14 00:21:20 +01:00
|
|
|
void *CustomData_get_layer_named_for_write(CustomData *data,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
2023-01-14 00:21:20 +01:00
|
|
|
const char *name,
|
|
|
|
int totelem);
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
int CustomData_get_offset(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_offset_named(const CustomData *data, eCustomDataType type, const char *name);
|
|
|
|
int CustomData_get_n_offset(const CustomData *data, eCustomDataType type, int n);
|
2023-03-29 17:10:49 +02:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
int CustomData_get_layer_index(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_layer_index_n(const CustomData *data, eCustomDataType type, int n);
|
|
|
|
int CustomData_get_named_layer_index(const CustomData *data,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
|
|
|
const char *name);
|
2023-11-16 12:00:12 +01:00
|
|
|
int CustomData_get_named_layer_index_notype(const CustomData *data, const char *name);
|
|
|
|
int CustomData_get_active_layer_index(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_render_layer_index(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_clone_layer_index(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_stencil_layer_index(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_named_layer(const CustomData *data, eCustomDataType type, const char *name);
|
|
|
|
int CustomData_get_active_layer(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_render_layer(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_clone_layer(const CustomData *data, eCustomDataType type);
|
|
|
|
int CustomData_get_stencil_layer(const CustomData *data, eCustomDataType type);
|
2006-12-13 01:50:02 +01:00
|
|
|
|
USD Preview Surface material export.
Add `USD Preview Surface From Nodes` export option, to convert a
Principled BSDF material node network to an approximate USD Preview
Surface shader representation. If this option is disabled, the original
material export behavior is maintained, where viewport setting are saved
to the Preview Surface shader.
Also added the following options for texture export.
- `Export Textures`: If converting Preview Surface, export textures
referenced by shader nodes to a 'textures' directory which is a
sibling of the USD file.
- `Overwrite Textures`: Allow overwriting existing texture files when
exporting textures (this option is off by default).
- `Relative Texture Paths`: Make texture asset paths relative to the
USD.
The entry point for the new functionality is
`create_usd_preview_surface_material()`, called from
`USDAbstractWriter::ensure_usd_material()`. The material conversion
currently handles a small subset of Blender shading nodes,
`BSDF_DIFFUSE`, `BSDF_PRINCIPLED`, `TEX_IMAGE` and `UVMAP`.
Texture export is handled by copying texture files from their original
location to a `textures` folder in the same directory as the USD.
In-memory and packed textures are saved directly to the textures folder.
This patch is based, in part, on code in Tangent Animation's USD
exporter branch.
Reviewed By: sybren, HooglyBoogly
Differential Revision: https://developer.blender.org/D13647
2022-01-27 15:43:14 +01:00
|
|
|
/**
|
|
|
|
* Returns name of the active layer of the given type or NULL
|
|
|
|
* if no such active layer is defined.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const char *CustomData_get_active_layer_name(const CustomData *data, eCustomDataType type);
|
USD Preview Surface material export.
Add `USD Preview Surface From Nodes` export option, to convert a
Principled BSDF material node network to an approximate USD Preview
Surface shader representation. If this option is disabled, the original
material export behavior is maintained, where viewport setting are saved
to the Preview Surface shader.
Also added the following options for texture export.
- `Export Textures`: If converting Preview Surface, export textures
referenced by shader nodes to a 'textures' directory which is a
sibling of the USD file.
- `Overwrite Textures`: Allow overwriting existing texture files when
exporting textures (this option is off by default).
- `Relative Texture Paths`: Make texture asset paths relative to the
USD.
The entry point for the new functionality is
`create_usd_preview_surface_material()`, called from
`USDAbstractWriter::ensure_usd_material()`. The material conversion
currently handles a small subset of Blender shading nodes,
`BSDF_DIFFUSE`, `BSDF_PRINCIPLED`, `TEX_IMAGE` and `UVMAP`.
Texture export is handled by copying texture files from their original
location to a `textures` folder in the same directory as the USD.
In-memory and packed textures are saved directly to the textures folder.
This patch is based, in part, on code in Tangent Animation's USD
exporter branch.
Reviewed By: sybren, HooglyBoogly
Differential Revision: https://developer.blender.org/D13647
2022-01-27 15:43:14 +01:00
|
|
|
|
2022-08-26 18:15:32 +02:00
|
|
|
/**
|
|
|
|
* Returns name of the default layer of the given type or NULL
|
|
|
|
* if no such active layer is defined.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
const char *CustomData_get_render_layer_name(const CustomData *data, eCustomDataType type);
|
2022-08-26 18:15:32 +02:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_layer_is_anonymous(const CustomData *data, eCustomDataType type, int n);
|
2023-03-17 09:41:52 +01:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_set(const CustomData *data,
|
2015-02-23 05:55:48 +01:00
|
|
|
void *block,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
2015-02-23 05:55:48 +01:00
|
|
|
const void *source);
|
2008-07-04 19:59:16 +02:00
|
|
|
|
2015-02-23 05:55:48 +01:00
|
|
|
void CustomData_bmesh_set_n(
|
2023-11-16 12:00:12 +01:00
|
|
|
CustomData *data, void *block, eCustomDataType type, int n, const void *source);
|
2006-12-12 22:29:09 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Sets the nth layer of type as active.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_set_layer_active(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_render(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_clone(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_stencil(CustomData *data, eCustomDataType type, int n);
|
2006-12-12 22:29:09 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* For using with an index from #CustomData_get_active_layer_index and
|
|
|
|
* #CustomData_get_render_layer_index.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_set_layer_active_index(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_render_index(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_clone_index(CustomData *data, eCustomDataType type, int n);
|
|
|
|
void CustomData_set_layer_stencil_index(CustomData *data, eCustomDataType type, int n);
|
2007-09-12 04:13:35 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Adds flag to the layer flags.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_set_layer_flag(CustomData *data, eCustomDataType type, int flag);
|
|
|
|
void CustomData_clear_layer_flag(CustomData *data, eCustomDataType type, int flag);
|
2006-11-11 17:38:37 +01:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_set_default(CustomData *data, void **block);
|
|
|
|
void CustomData_bmesh_free_block(CustomData *data, void **block);
|
|
|
|
void CustomData_bmesh_alloc_block(CustomData *data, void **block);
|
2023-02-13 20:52:02 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Same as #CustomData_bmesh_free_block but zero the memory rather than freeing.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_free_block_data(CustomData *data, void *block);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* A selective version of #CustomData_bmesh_free_block_data.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_free_block_data_exclude_by_type(CustomData *data,
|
2019-11-26 06:19:56 +01:00
|
|
|
void *block,
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataMask mask_exclude);
|
2008-07-04 19:59:16 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Query info over types.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
void CustomData_file_write_info(eCustomDataType type,
|
|
|
|
const char **r_struct_name,
|
|
|
|
int *r_struct_num);
|
|
|
|
int CustomData_sizeof(eCustomDataType type);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Get the name of a layer type.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
const char *CustomData_layertype_name(eCustomDataType type);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Can only ever be one of these.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
bool CustomData_layertype_is_singleton(eCustomDataType type);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Has dynamically allocated members.
|
|
|
|
* This is useful to know if operations such as #memcmp are
|
|
|
|
* valid when comparing data from two layers.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
bool CustomData_layertype_is_dynamic(eCustomDataType type);
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* \return Maximum number of layers of given \a type, -1 means 'no limit'.
|
|
|
|
*/
|
2023-03-29 17:10:49 +02:00
|
|
|
int CustomData_layertype_layers_max(eCustomDataType type);
|
2006-12-05 18:42:03 +01:00
|
|
|
|
2023-06-10 09:21:24 +02:00
|
|
|
/** \return The maximum size in bytes needed for a layer name with the given prefix. */
|
|
|
|
int CustomData_name_maxncpy_calc(blender::StringRef 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
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Make sure the name of layer at index is unique.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_set_layer_unique_name(CustomData *data, int index);
|
2006-12-21 14:47:27 +01:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_validate_layer_name(const CustomData *data,
|
2023-03-29 17:10:49 +02:00
|
|
|
eCustomDataType type,
|
2012-08-04 00:12:57 +02:00
|
|
|
const char *name,
|
|
|
|
char *outname);
|
2011-10-13 22:00:22 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* For file reading compatibility, returns false if the layer was freed,
|
|
|
|
* only after this test passes, `layer->data` should be assigned.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_verify_versions(CustomData *data, int index);
|
2008-07-08 04:22:37 +02:00
|
|
|
|
2022-07-08 05:33:57 +02:00
|
|
|
/* BMesh specific custom-data stuff. */
|
2021-12-07 07:19:15 +01:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_bmesh_init_pool(CustomData *data, int totelem, char htype);
|
2009-11-25 15:27:50 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Validate and fix data of \a layer,
|
|
|
|
* if possible (needs relevant callback in layer's type to be defined).
|
|
|
|
*
|
|
|
|
* \return True if some errors were found.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
bool CustomData_layer_validate(CustomDataLayer *layer, uint totitems, bool do_fixes);
|
2018-12-03 16:19:08 +01:00
|
|
|
|
2009-11-25 15:27:50 +01:00
|
|
|
/* External file storage */
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_external_add(
|
|
|
|
CustomData *data, ID *id, eCustomDataType type, int totelem, const char *filepath);
|
|
|
|
void CustomData_external_remove(CustomData *data, ID *id, eCustomDataType type, int totelem);
|
|
|
|
bool CustomData_external_test(CustomData *data, eCustomDataType type);
|
2009-11-25 15:27:50 +01:00
|
|
|
|
|
|
|
void CustomData_external_write(
|
2023-11-16 12:00:12 +01:00
|
|
|
CustomData *data, ID *id, eCustomDataMask mask, int totelem, int free);
|
|
|
|
void CustomData_external_read(CustomData *data, ID *id, eCustomDataMask mask, int totelem);
|
|
|
|
void CustomData_external_reload(CustomData *data, ID *id, eCustomDataMask mask, int totelem);
|
2009-11-25 15:27:50 +01:00
|
|
|
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
/* Mesh-to-mesh transfer data. */
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
using cd_datatransfer_interp = void (*)(const CustomDataTransferLayerMap *laymap,
|
|
|
|
void *dest,
|
|
|
|
const void **sources,
|
|
|
|
const float *weights,
|
|
|
|
int count,
|
|
|
|
float mix_factor);
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
|
|
|
/**
|
2019-04-27 04:07:07 +02:00
|
|
|
* Fake CD_LAYERS (those are actually 'real' data stored directly into elements' structs,
|
|
|
|
* or otherwise not (directly) accessible to usual CDLayer system). */
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
enum {
|
|
|
|
CD_FAKE = 1 << 8,
|
|
|
|
|
|
|
|
/* Vertices. */
|
2021-07-23 08:56:00 +02:00
|
|
|
CD_FAKE_MDEFORMVERT = CD_FAKE | CD_MDEFORMVERT, /* *sigh* due to how vgroups are stored :(. */
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
CD_FAKE_SHAPEKEY = CD_FAKE |
|
|
|
|
CD_SHAPEKEY, /* Not available as real CD layer in non-bmesh context. */
|
|
|
|
|
|
|
|
/* Edges. */
|
2022-09-23 16:02:05 +02:00
|
|
|
CD_FAKE_SEAM = CD_FAKE | 100, /* UV seam flag for edges. */
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
|
|
|
/* Multiple types of mesh elements... */
|
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
|
|
|
CD_FAKE_UV =
|
|
|
|
CD_FAKE |
|
2023-07-24 22:06:55 +02:00
|
|
|
CD_PROP_FLOAT2, /* UV flag, because we handle both loop's UVs and face's textures. */
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
2015-02-05 14:38:59 +01:00
|
|
|
CD_FAKE_LNOR = CD_FAKE |
|
|
|
|
CD_CUSTOMLOOPNORMAL, /* Because we play with clnor and temp lnor layers here. */
|
|
|
|
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
CD_FAKE_SHARP = CD_FAKE | 200, /* Sharp flag for edges, smooth flag for faces. */
|
2023-05-19 14:31:31 +02:00
|
|
|
|
2023-06-13 20:23:39 +02:00
|
|
|
CD_FAKE_BWEIGHT = CD_FAKE | 300,
|
|
|
|
CD_FAKE_CREASE = CD_FAKE | 400,
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
ME_VERT = 1 << 0,
|
|
|
|
ME_EDGE = 1 << 1,
|
|
|
|
ME_POLY = 1 << 2,
|
|
|
|
ME_LOOP = 1 << 3,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* How to filter out some elements (to leave untouched).
|
|
|
|
* Note those options are highly dependent on type of transferred data! */
|
|
|
|
enum {
|
|
|
|
CDT_MIX_NOMIX = -1, /* Special case, only used because we abuse 'copy' CD callback. */
|
|
|
|
CDT_MIX_TRANSFER = 0,
|
|
|
|
CDT_MIX_REPLACE_ABOVE_THRESHOLD = 1,
|
|
|
|
CDT_MIX_REPLACE_BELOW_THRESHOLD = 2,
|
|
|
|
CDT_MIX_MIX = 16,
|
|
|
|
CDT_MIX_ADD = 17,
|
|
|
|
CDT_MIX_SUB = 18,
|
|
|
|
CDT_MIX_MUL = 19,
|
2021-06-28 07:44:12 +02:00
|
|
|
/* Etc. */
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
};
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
struct CustomDataTransferLayerMap {
|
|
|
|
CustomDataTransferLayerMap *next, *prev;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-06-09 17:10:40 +02:00
|
|
|
int data_type;
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
int mix_mode;
|
|
|
|
float mix_factor;
|
2019-04-27 04:07:07 +02:00
|
|
|
/** If non-NULL, array of weights, one for each dest item, replaces mix_factor. */
|
|
|
|
const float *mix_weights;
|
|
|
|
|
2023-01-16 03:57:10 +01:00
|
|
|
/** Data source array (can be regular CD data, vertices/edges/etc., key-blocks...). */
|
2019-04-27 04:07:07 +02:00
|
|
|
const void *data_src;
|
|
|
|
/** Data dest array (same type as dat_src). */
|
|
|
|
void *data_dst;
|
|
|
|
/** Index to affect in data_src (used e.g. for vgroups). */
|
|
|
|
int data_src_n;
|
|
|
|
/** Index to affect in data_dst (used e.g. for vgroups). */
|
|
|
|
int data_dst_n;
|
|
|
|
/** Size of one element of data_src/data_dst. */
|
|
|
|
size_t elem_size;
|
|
|
|
|
|
|
|
/** Size of actual data we transfer. */
|
|
|
|
size_t data_size;
|
|
|
|
/** Offset of actual data we transfer (in element contained in data_src/dst). */
|
|
|
|
size_t data_offset;
|
2022-08-17 07:43:17 +02:00
|
|
|
/** For bit-flag transfer, flag(s) to affect in transferred data. */
|
2019-04-27 04:07:07 +02:00
|
|
|
uint64_t data_flag;
|
|
|
|
|
2023-01-16 03:57:10 +01:00
|
|
|
/** Opaque pointer, to be used by specific interp callback (e.g. transform-space for normals). */
|
2019-04-27 04:07:07 +02:00
|
|
|
void *interp_data;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
cd_datatransfer_interp interp;
|
2023-11-16 12:00:12 +01:00
|
|
|
};
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
|
|
|
* Those functions assume src_n and dst_n layers of given type exist in resp. src and dst.
|
|
|
|
*/
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_data_transfer(const MeshPairRemap *me_remap,
|
Transfer Data: add main core code and operators.
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
2015-01-09 19:11:40 +01:00
|
|
|
const CustomDataTransferLayerMap *laymap);
|
|
|
|
|
2020-08-28 14:30:19 +02:00
|
|
|
/* .blend file I/O */
|
2021-12-07 07:19:15 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Prepare given custom data for file writing.
|
|
|
|
*
|
2022-05-29 11:02:10 +02:00
|
|
|
* \param data: The custom-data to tweak for .blend file writing (modified in place).
|
|
|
|
* \param layers_to_write: A reduced set of layers to be written to file.
|
2021-12-07 07:19:15 +01:00
|
|
|
*
|
2022-05-29 11:02:10 +02:00
|
|
|
* \warning This function invalidates the custom data struct by changing the layer counts and the
|
|
|
|
* #layers pointer, and by invalidating the type map. It expects to work on a shallow copy of
|
|
|
|
* the struct.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2022-05-29 11:02:10 +02:00
|
|
|
void CustomData_blend_write_prepare(CustomData &data,
|
Mesh: Move hide flags to generic attributes
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. The `.` prefix
means they are "UI attributes", so they still contain original data
edited by users, but they aren't meant to be accessed procedurally by
the user in arbitrary situations. They are also be hidden in the
spreadsheet and the attribute list by default,
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
2022-08-11 18:54:24 +02:00
|
|
|
blender::Vector<CustomDataLayer, 16> &layers_to_write,
|
2022-08-23 19:50:47 +02:00
|
|
|
const blender::Set<std::string> &skip_names = {});
|
2020-09-09 12:38:33 +02:00
|
|
|
|
2021-12-07 07:19:15 +01:00
|
|
|
/**
|
2022-05-29 11:02:10 +02:00
|
|
|
* \param layers_to_write: Layers created by #CustomData_blend_write_prepare.
|
2021-12-07 07:19:15 +01:00
|
|
|
*/
|
2022-05-29 11:02:10 +02:00
|
|
|
void CustomData_blend_write(BlendWriter *writer,
|
|
|
|
CustomData *data,
|
|
|
|
blender::Span<CustomDataLayer> layers_to_write,
|
2020-08-28 14:30:19 +02:00
|
|
|
int count,
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataMask cddata_mask,
|
2022-05-29 11:02:10 +02:00
|
|
|
ID *id);
|
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_blend_read(BlendDataReader *reader, CustomData *data, int count);
|
2020-08-28 14:30:19 +02:00
|
|
|
|
2023-11-16 12:00:12 +01:00
|
|
|
size_t CustomData_get_elem_size(const CustomDataLayer *layer);
|
2022-09-16 21:20:28 +02:00
|
|
|
|
2022-01-19 05:09:48 +01:00
|
|
|
#ifndef NDEBUG
|
|
|
|
struct DynStr;
|
|
|
|
/** Use to inspect mesh data when debugging. */
|
2023-11-16 12:00:12 +01:00
|
|
|
void CustomData_debug_info_from_layers(const CustomData *data, const char *indent, DynStr *dynstr);
|
2022-01-19 05:09:48 +01:00
|
|
|
#endif /* NDEBUG */
|
|
|
|
|
2022-03-19 10:57:40 +01:00
|
|
|
namespace blender::bke {
|
2022-06-01 07:06:21 +02:00
|
|
|
const CPPType *custom_data_type_to_cpp_type(eCustomDataType type);
|
2022-06-01 06:38:06 +02:00
|
|
|
eCustomDataType cpp_type_to_custom_data_type(const CPPType &type);
|
2022-03-19 10:57:40 +01:00
|
|
|
} // namespace blender::bke
|