Files
test/source/blender/editors/mesh/editmesh_undo.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1080 lines
35 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
2016-05-25 19:12:43 +10:00
/** \file
* \ingroup edmesh
2016-05-25 19:12:43 +10:00
*/
#include <algorithm>
#include <variant>
2016-05-25 19:12:43 +10:00
#include "MEM_guardedalloc.h"
#include "CLG_log.h"
#include "DNA_key_types.h"
#include "DNA_layer_types.h"
2016-05-25 19:12:43 +10:00
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
2016-05-25 19:12:43 +10:00
#include "DNA_object_types.h"
#include "DNA_scene_types.h"
2016-05-25 19:12:43 +10:00
#include "BLI_array_utils.h"
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
#include "BLI_implicit_sharing.hh"
#include "BLI_listbase.h"
#include "BLI_math_base.h"
#include "BLI_string.h"
#include "BLI_task.hh"
#include "BLI_vector.hh"
2016-05-25 19:12:43 +10:00
#include "BKE_context.hh"
#include "BKE_customdata.hh"
#include "BKE_editmesh.hh"
2024-01-30 14:42:07 -05:00
#include "BKE_key.hh"
2024-01-23 15:18:09 -05:00
#include "BKE_layer.hh"
2024-01-15 12:44:04 -05:00
#include "BKE_lib_id.hh"
#include "BKE_main.hh"
#include "BKE_mesh.hh"
#include "BKE_object.hh"
2024-01-15 12:26:09 -05:00
#include "BKE_undo_system.hh"
2016-05-25 19:12:43 +10:00
#include "DEG_depsgraph.hh"
#include "ED_mesh.hh"
#include "ED_object.hh"
#include "ED_undo.hh"
#include "ED_util.hh"
2016-05-25 19:12:43 +10:00
#include "WM_api.hh"
#include "WM_types.hh"
#define USE_ARRAY_STORE
2016-05-25 19:12:43 +10:00
#ifdef USE_ARRAY_STORE
// # define DEBUG_PRINT
// # define DEBUG_TIME
# ifdef DEBUG_TIME
# include "BLI_time_utildefines.h"
# endif
2016-05-25 19:12:43 +10:00
# include "BLI_array_store.h"
# include "BLI_array_store_utils.h"
/**
* This used to be much smaller (256), but this caused too much overhead
* when selection moved to boolean arrays. Especially with high-poly meshes
* where managing a large number of small chunks could be slow, blocking user interactivity.
* Use a larger value (in bytes) which calculates the chunk size using #array_chunk_size_calc.
* See: #105046 & #105205.
*/
# define ARRAY_CHUNK_SIZE_IN_BYTES 65536
# define ARRAY_CHUNK_NUM_MIN 256
# define USE_ARRAY_STORE_THREAD
#endif
#ifdef USE_ARRAY_STORE_THREAD
# include "BLI_task.h"
#endif
/** We only need this locally. */
static CLG_LogRef LOG = {"ed.undo.mesh"};
/* -------------------------------------------------------------------- */
/** \name Undo Conversion
* \{ */
#ifdef USE_ARRAY_STORE
static size_t array_chunk_size_calc(const size_t stride)
{
/* Return a chunk size that targets a size in bytes,
* this is done so boolean arrays don't add so much overhead and
* larger arrays aren't so big as to waste memory, see: #105205. */
return std::max(ARRAY_CHUNK_NUM_MIN, ARRAY_CHUNK_SIZE_IN_BYTES / power_of_2_max_i(stride));
}
/* Single linked list of layers stored per type */
struct BArrayCustomData {
BArrayCustomData *next;
eCustomDataType type;
blender::Array<std::variant<BArrayState *, blender::ImplicitSharingInfoAndData>> states;
};
#endif
2016-05-25 19:12:43 +10:00
struct UndoMesh {
/**
* This undo-meshes in `um_arraystore.local_links`.
* Not to be confused with the next and previous undo steps.
*/
UndoMesh *local_next, *local_prev;
Mesh mesh;
2016-05-25 19:12:43 +10:00
int selectmode;
char uv_selectmode;
/**
* The active shape key associated with this mesh.
*
* NOTE(@ideasman42): This isn't a perfect solution, if you edit keys and change shapes this
* works well (fixing #32442), but editing shape keys, going into object mode, removing or
* changing their order, then go back into edit-mode and undo will give issues - where the old
* index will be out of sync with the new object index.
2016-05-25 19:12:43 +10:00
*
* There are a few ways this could be made to work but for now its a known limitation with mixing
* object and edit-mode operations.
*/
2016-05-25 19:12:43 +10:00
int shapenr;
#ifdef USE_ARRAY_STORE
2022-10-10 11:21:53 +11:00
/* Null arrays are considered empty. */
struct { /* most data is stored as 'custom' data */
BArrayCustomData *vdata, *edata, *ldata, *pdata;
BArrayState *face_offset_indices;
BArrayState **keyblocks;
BArrayState *mselect;
} store;
#endif /* USE_ARRAY_STORE */
size_t undo_size;
};
2016-05-25 19:12:43 +10:00
#ifdef USE_ARRAY_STORE
/* -------------------------------------------------------------------- */
/** \name Array Store
* \{ */
/**
* Store separate #BArrayStore_AtSize so multiple threads
* can access array stores without locking.
*/
enum {
ARRAY_STORE_INDEX_VERT = 0,
ARRAY_STORE_INDEX_EDGE,
ARRAY_STORE_INDEX_LOOP,
ARRAY_STORE_INDEX_POLY,
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
ARRAY_STORE_INDEX_POLY_OFFSETS,
ARRAY_STORE_INDEX_SHAPE,
ARRAY_STORE_INDEX_MSEL,
};
# define ARRAY_STORE_INDEX_NUM (ARRAY_STORE_INDEX_MSEL + 1)
static struct {
BArrayStore_AtSize bs_stride[ARRAY_STORE_INDEX_NUM];
int users;
/**
* A list of #UndoMesh items ordered from oldest to newest
* used to access previous undo data for a mesh.
*/
ListBase local_links;
# ifdef USE_ARRAY_STORE_THREAD
TaskPool *task_pool;
# endif
} um_arraystore = {{{nullptr}}};
static void um_arraystore_cd_compact(CustomData *cdata,
const size_t data_len,
const bool create,
const int bs_index,
const BArrayCustomData *bcd_reference,
BArrayCustomData **r_bcd_first)
{
using namespace blender;
if (data_len == 0) {
if (create) {
*r_bcd_first = nullptr;
}
}
const BArrayCustomData *bcd_reference_current = bcd_reference;
BArrayCustomData *bcd = nullptr, *bcd_first = nullptr, *bcd_prev = nullptr;
for (int layer_start = 0, layer_end; layer_start < cdata->totlayer; layer_start = layer_end) {
const eCustomDataType type = eCustomDataType(cdata->layers[layer_start].type);
/* Perform a full copy on dynamic layers.
*
* Unfortunately we can't compare dynamic layer types as they contain allocated pointers,
* which burns CPU cycles looking for duplicate data that doesn't exist.
* The array data isn't comparable once copied from the mesh,
* this bottlenecks on high poly meshes, see #84114.
*
* Ideally the data would be expanded into a format that could be de-duplicated effectively,
* this would require a flat representation of each dynamic custom-data layer.
*
* Instead, these non-trivial custom data layer are stored in the undo system using implicit
* sharing, to avoid the copy from the undo mesh.
*/
const bool layer_type_is_dynamic = CustomData_layertype_is_dynamic(type);
layer_end = layer_start + 1;
while ((layer_end < cdata->totlayer) && (type == cdata->layers[layer_end].type)) {
layer_end++;
}
const int stride = CustomData_sizeof(type);
BArrayStore *bs = create ? BLI_array_store_at_size_ensure(&um_arraystore.bs_stride[bs_index],
stride,
array_chunk_size_calc(stride)) :
nullptr;
const int layer_len = layer_end - layer_start;
if (create) {
if (bcd_reference_current && (bcd_reference_current->type == type)) {
/* common case, the reference is aligned */
}
else {
bcd_reference_current = nullptr;
2021-02-05 16:23:34 +11:00
/* Do a full lookup when unaligned. */
if (bcd_reference) {
const BArrayCustomData *bcd_iter = bcd_reference;
while (bcd_iter) {
if (bcd_iter->type == type) {
bcd_reference_current = bcd_iter;
break;
}
bcd_iter = bcd_iter->next;
}
}
}
}
if (create) {
bcd = MEM_new<BArrayCustomData>(__func__);
bcd->next = nullptr;
bcd->type = type;
bcd->states.reinitialize(layer_end - layer_start);
if (bcd_prev) {
bcd_prev->next = bcd;
bcd_prev = bcd;
}
else {
bcd_first = bcd;
bcd_prev = bcd;
}
}
CustomDataLayer *layer = &cdata->layers[layer_start];
for (int i = 0; i < layer_len; i++, layer++) {
if (create) {
if (layer->data) {
if (layer_type_is_dynamic) {
/* See comment on `layer_type_is_dynamic` above. */
const ImplicitSharingInfo *sharing_info;
if (layer->sharing_info) {
sharing_info = layer->sharing_info;
sharing_info->add_user();
}
else {
sharing_info = implicit_sharing::info_for_mem_free(layer->data);
}
bcd->states[i] = ImplicitSharingInfoAndData{sharing_info, layer->data};
}
else {
BArrayState *state_reference = nullptr;
if (bcd_reference_current && i < bcd_reference_current->states.size()) {
state_reference = std::get<BArrayState *>(bcd_reference_current->states[i]);
}
bcd->states[i] = BLI_array_store_state_add(
bs, layer->data, size_t(data_len) * stride, state_reference);
}
}
else {
bcd->states[i] = nullptr;
}
}
if (layer->data) {
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
if (layer->sharing_info) {
layer->sharing_info->remove_user_and_delete_if_last();
layer->sharing_info = nullptr;
layer->data = nullptr;
}
else {
MEM_SAFE_FREE(layer->data);
Custom Data: support implicit sharing for custom data layers This integrates the new implicit-sharing system (from fbcddfcd68adc72f) with `CustomData`. Now the potentially long arrays referenced by custom data layers can be shared between different systems but most importantly between different geometries. This makes e.g. copying a mesh much cheaper because none of the attributes has to be copied. Only when an attribute is modified does it have to be copied. Also see the original design task: #95845. This reduces memory and improves performance by avoiding unnecessary data copies. For example, the used memory after loading a highly subdivided mesh is reduced from 2.4GB to 1.79GB. This is about 25% less which is the expected amount because in `main` there are 4 copies of the data: 1. The original data which is allocated when the file is loaded. 2. The copy for the depsgraph allocated during depsgraph evaluation. 3. The copy for the undo system allocated when the first undo step is created right after loading the file. 4. GPU buffers allocated for drawing. This patch only gets rid of copy number 2 for the depsgraph. In theory the other copies can be removed as part of follow up PRs as well though. ----- The patch has three main components: * Slightly modified `CustomData` API to make it work better with implicit sharing: * `CD_REFERENCE` and `CD_DUPLICATE` have been removed because they are meaningless when implicit-sharing is used. * `CD_ASSIGN` has been removed as well because it's not an allocation type anyway. The functionality of using existing arrays as custom data layers has not been removed though. * This can still be done with `CustomData_add_layer_with_data` which also has a new argument that allows passing in information about whether the array is shared. * `CD_FLAG_NOFREE` has been removed because it's no longer necessary. It only existed because of `CD_REFERENCE`. * `CustomData_copy` and `CustomData_merge` have been split up into a functions that do copy the actual attribute values and those that do not. The latter functions now have the `_layout` suffix (e.g. `CustomData_copy_layout`). * Changes in `customdata.cc` to make it actually use implicit-sharing. * Changes in various other files to adapt to the changes in `BKE_customdata.h`. Pull Request: https://projects.blender.org/blender/blender/pulls/106228
2023-04-13 14:57:57 +02:00
}
}
}
if (create) {
if (bcd_reference_current) {
bcd_reference_current = bcd_reference_current->next;
}
}
}
if (create) {
*r_bcd_first = bcd_first;
}
}
/**
* \note There is no room for data going out of sync here.
* The layers and the states are stored together so this can be kept working.
*/
static void um_arraystore_cd_expand(const BArrayCustomData *bcd,
CustomData *cdata,
const size_t data_len)
{
using namespace blender;
CustomDataLayer *layer = cdata->layers;
while (bcd) {
const int stride = CustomData_sizeof(bcd->type);
for (int i = 0; i < bcd->states.size(); i++) {
BLI_assert(bcd->type == layer->type);
if (std::holds_alternative<BArrayState *>(bcd->states[i])) {
BArrayState *state = std::get<BArrayState *>(bcd->states[i]);
if (state) {
size_t state_len;
layer->data = BLI_array_store_state_data_get_alloc(state, &state_len);
BLI_assert(stride * data_len == state_len);
UNUSED_VARS_NDEBUG(stride, data_len);
}
else {
layer->data = nullptr;
}
}
else {
ImplicitSharingInfoAndData state = std::get<ImplicitSharingInfoAndData>(bcd->states[i]);
layer->data = const_cast<void *>(state.data);
layer->sharing_info = state.sharing_info;
layer->sharing_info->add_user();
}
layer++;
}
bcd = bcd->next;
}
}
static void um_arraystore_cd_free(BArrayCustomData *bcd, const int bs_index)
{
using namespace blender;
while (bcd) {
BArrayCustomData *bcd_next = bcd->next;
const int stride = CustomData_sizeof(bcd->type);
BArrayStore *bs = BLI_array_store_at_size_get(&um_arraystore.bs_stride[bs_index], stride);
for (int i = 0; i < bcd->states.size(); i++) {
if (std::holds_alternative<BArrayState *>(bcd->states[i])) {
if (BArrayState *state = std::get<BArrayState *>(bcd->states[i])) {
BLI_array_store_state_remove(bs, state);
}
}
else {
ImplicitSharingInfoAndData state = std::get<ImplicitSharingInfoAndData>(bcd->states[i]);
state.sharing_info->remove_user_and_delete_if_last();
}
}
MEM_delete(bcd);
bcd = bcd_next;
}
}
/**
* \param create: When false, only free the arrays.
* This is done since when reading from an undo state, they must be temporarily expanded.
* then discarded afterwards, having this argument avoids having 2x code paths.
*/
static void um_arraystore_compact_ex(UndoMesh *um, const UndoMesh *um_ref, bool create)
{
Mesh *mesh = &um->mesh;
/* Compacting can be time consuming, run in parallel.
*
* NOTE(@ideasman42): this could be further parallelized with every custom-data layer
2023-03-24 08:34:21 -04:00
* running in its own thread. If this is a bottleneck it's worth considering.
* At the moment it seems fast enough to split by domain.
* Since this is itself a background thread, using too many threads here could
* interfere with foreground tasks. */
blender::threading::parallel_invoke(
4096 < (mesh->verts_num + mesh->edges_num + mesh->corners_num + mesh->faces_num),
[&]() {
um_arraystore_cd_compact(&mesh->vert_data,
mesh->verts_num,
create,
ARRAY_STORE_INDEX_VERT,
um_ref ? um_ref->store.vdata : nullptr,
&um->store.vdata);
},
[&]() {
um_arraystore_cd_compact(&mesh->edge_data,
mesh->edges_num,
create,
ARRAY_STORE_INDEX_EDGE,
um_ref ? um_ref->store.edata : nullptr,
&um->store.edata);
},
[&]() {
um_arraystore_cd_compact(&mesh->corner_data,
mesh->corners_num,
create,
ARRAY_STORE_INDEX_LOOP,
um_ref ? um_ref->store.ldata : nullptr,
&um->store.ldata);
},
[&]() {
um_arraystore_cd_compact(&mesh->face_data,
mesh->faces_num,
create,
ARRAY_STORE_INDEX_POLY,
um_ref ? um_ref->store.pdata : nullptr,
&um->store.pdata);
},
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
[&]() {
if (mesh->face_offset_indices) {
BLI_assert(create == (um->store.face_offset_indices == nullptr));
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
if (create) {
BArrayState *state_reference = um_ref ? um_ref->store.face_offset_indices : nullptr;
const size_t stride = sizeof(*mesh->face_offset_indices);
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
BArrayStore *bs = BLI_array_store_at_size_ensure(
&um_arraystore.bs_stride[ARRAY_STORE_INDEX_POLY_OFFSETS],
stride,
array_chunk_size_calc(stride));
um->store.face_offset_indices = BLI_array_store_state_add(bs,
mesh->face_offset_indices,
size_t(mesh->faces_num + 1) *
stride,
state_reference);
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
}
blender::implicit_sharing::free_shared_data(&mesh->face_offset_indices,
&mesh->runtime->face_offsets_sharing_info);
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
}
},
[&]() {
if (mesh->key && mesh->key->totkey) {
const size_t stride = mesh->key->elemsize;
BArrayStore *bs = create ? BLI_array_store_at_size_ensure(
&um_arraystore.bs_stride[ARRAY_STORE_INDEX_SHAPE],
stride,
array_chunk_size_calc(stride)) :
nullptr;
if (create) {
um->store.keyblocks = static_cast<BArrayState **>(
MEM_mallocN(mesh->key->totkey * sizeof(*um->store.keyblocks), __func__));
}
KeyBlock *keyblock = static_cast<KeyBlock *>(mesh->key->block.first);
for (int i = 0; i < mesh->key->totkey; i++, keyblock = keyblock->next) {
if (create) {
BArrayState *state_reference = (um_ref && um_ref->mesh.key &&
(i < um_ref->mesh.key->totkey)) ?
um_ref->store.keyblocks[i] :
nullptr;
um->store.keyblocks[i] = BLI_array_store_state_add(
bs, keyblock->data, size_t(keyblock->totelem) * stride, state_reference);
}
if (keyblock->data) {
MEM_freeN(keyblock->data);
keyblock->data = nullptr;
}
}
}
},
[&]() {
if (mesh->mselect && mesh->totselect) {
BLI_assert(create == (um->store.mselect == nullptr));
if (create) {
BArrayState *state_reference = um_ref ? um_ref->store.mselect : nullptr;
const size_t stride = sizeof(*mesh->mselect);
BArrayStore *bs = BLI_array_store_at_size_ensure(
&um_arraystore.bs_stride[ARRAY_STORE_INDEX_MSEL],
stride,
array_chunk_size_calc(stride));
um->store.mselect = BLI_array_store_state_add(
bs, mesh->mselect, size_t(mesh->totselect) * stride, state_reference);
}
/* keep mesh->totselect for validation */
MEM_freeN(mesh->mselect);
mesh->mselect = nullptr;
}
});
if (create) {
um_arraystore.users += 1;
}
}
/**
* Move data from allocated arrays to de-duplicated states and clear arrays.
*/
static void um_arraystore_compact(UndoMesh *um, const UndoMesh *um_ref)
{
um_arraystore_compact_ex(um, um_ref, true);
}
static void um_arraystore_compact_with_info(UndoMesh *um, const UndoMesh *um_ref)
{
# ifdef DEBUG_PRINT
size_t size_expanded_prev = 0, size_compacted_prev = 0;
for (int bs_index = 0; bs_index < ARRAY_STORE_INDEX_NUM; bs_index++) {
size_t size_expanded_prev_iter, size_compacted_prev_iter;
BLI_array_store_at_size_calc_memory_usage(
&um_arraystore.bs_stride[bs_index], &size_expanded_prev_iter, &size_compacted_prev_iter);
size_expanded_prev += size_expanded_prev_iter;
size_compacted_prev += size_compacted_prev_iter;
}
# endif
# ifdef DEBUG_TIME
TIMEIT_START(mesh_undo_compact);
# endif
um_arraystore_compact(um, um_ref);
# ifdef DEBUG_TIME
TIMEIT_END(mesh_undo_compact);
# endif
# ifdef DEBUG_PRINT
{
size_t size_expanded = 0, size_compacted = 0;
for (int bs_index = 0; bs_index < ARRAY_STORE_INDEX_NUM; bs_index++) {
size_t size_expanded_iter, size_compacted_iter;
BLI_array_store_at_size_calc_memory_usage(
&um_arraystore.bs_stride[bs_index], &size_expanded_iter, &size_compacted_iter);
size_expanded += size_expanded_iter;
size_compacted += size_compacted_iter;
}
const double percent_total = size_expanded ?
2023-01-11 13:03:53 +11:00
((double(size_compacted) / double(size_expanded)) * 100.0) :
-1.0;
size_t size_expanded_step = size_expanded - size_expanded_prev;
size_t size_compacted_step = size_compacted - size_compacted_prev;
const double percent_step = size_expanded_step ?
2023-01-11 13:03:53 +11:00
((double(size_compacted_step) / double(size_expanded_step)) *
100.0) :
-1.0;
printf("overall memory use: %.8f%% of expanded size\n", percent_total);
printf("step memory use: %.8f%% of expanded size\n", percent_step);
}
# endif
}
# ifdef USE_ARRAY_STORE_THREAD
struct UMArrayData {
UndoMesh *um;
const UndoMesh *um_ref; /* can be nullptr */
};
static void um_arraystore_compact_cb(TaskPool *__restrict /*pool*/, void *taskdata)
{
UMArrayData *um_data = static_cast<UMArrayData *>(taskdata);
um_arraystore_compact_with_info(um_data->um, um_data->um_ref);
}
# endif /* USE_ARRAY_STORE_THREAD */
/**
* Remove data we only expanded for temporary use.
*/
static void um_arraystore_expand_clear(UndoMesh *um)
{
um_arraystore_compact_ex(um, nullptr, false);
}
static void um_arraystore_expand(UndoMesh *um)
{
Mesh *mesh = &um->mesh;
um_arraystore_cd_expand(um->store.vdata, &mesh->vert_data, mesh->verts_num);
um_arraystore_cd_expand(um->store.edata, &mesh->edge_data, mesh->edges_num);
um_arraystore_cd_expand(um->store.ldata, &mesh->corner_data, mesh->corners_num);
um_arraystore_cd_expand(um->store.pdata, &mesh->face_data, mesh->faces_num);
if (um->store.keyblocks) {
const size_t stride = mesh->key->elemsize;
KeyBlock *keyblock = static_cast<KeyBlock *>(mesh->key->block.first);
for (int i = 0; i < mesh->key->totkey; i++, keyblock = keyblock->next) {
BArrayState *state = um->store.keyblocks[i];
size_t state_len;
keyblock->data = BLI_array_store_state_data_get_alloc(state, &state_len);
BLI_assert(keyblock->totelem == (state_len / stride));
UNUSED_VARS_NDEBUG(stride);
}
}
if (um->store.face_offset_indices) {
const size_t stride = sizeof(*mesh->face_offset_indices);
BArrayState *state = um->store.face_offset_indices;
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
size_t state_len;
mesh->face_offset_indices = static_cast<int *>(
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
BLI_array_store_state_data_get_alloc(state, &state_len));
mesh->runtime->face_offsets_sharing_info = blender::implicit_sharing::info_for_mem_free(
mesh->face_offset_indices);
BLI_assert((mesh->faces_num + 1) == (state_len / stride));
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
UNUSED_VARS_NDEBUG(stride);
}
if (um->store.mselect) {
const size_t stride = sizeof(*mesh->mselect);
BArrayState *state = um->store.mselect;
size_t state_len;
mesh->mselect = static_cast<MSelect *>(
BLI_array_store_state_data_get_alloc(state, &state_len));
BLI_assert(mesh->totselect == (state_len / stride));
UNUSED_VARS_NDEBUG(stride);
}
}
static void um_arraystore_free(UndoMesh *um)
{
Mesh *mesh = &um->mesh;
um_arraystore_cd_free(um->store.vdata, ARRAY_STORE_INDEX_VERT);
um_arraystore_cd_free(um->store.edata, ARRAY_STORE_INDEX_EDGE);
um_arraystore_cd_free(um->store.ldata, ARRAY_STORE_INDEX_LOOP);
um_arraystore_cd_free(um->store.pdata, ARRAY_STORE_INDEX_POLY);
if (um->store.keyblocks) {
const size_t stride = mesh->key->elemsize;
BArrayStore *bs = BLI_array_store_at_size_get(
&um_arraystore.bs_stride[ARRAY_STORE_INDEX_SHAPE], stride);
for (int i = 0; i < mesh->key->totkey; i++) {
BArrayState *state = um->store.keyblocks[i];
BLI_array_store_state_remove(bs, state);
}
MEM_freeN(um->store.keyblocks);
um->store.keyblocks = nullptr;
}
if (um->store.face_offset_indices) {
const size_t stride = sizeof(*mesh->face_offset_indices);
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
BArrayStore *bs = BLI_array_store_at_size_get(
&um_arraystore.bs_stride[ARRAY_STORE_INDEX_POLY_OFFSETS], stride);
BArrayState *state = um->store.face_offset_indices;
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
BLI_array_store_state_remove(bs, state);
um->store.face_offset_indices = nullptr;
Mesh: Replace MPoly struct with offset indices Implements #95967. Currently the `MPoly` struct is 12 bytes, and stores the index of a face's first corner and the number of corners/verts/edges. Polygons and corners are always created in order by Blender, meaning each face's corners will be after the previous face's corners. We can take advantage of this fact and eliminate the redundancy in mesh face storage by only storing a single integer corner offset for each face. The size of the face is then encoded by the offset of the next face. The size of a single integer is 4 bytes, so this reduces memory usage by 3 times. The same method is used for `CurvesGeometry`, so Blender already has an abstraction to simplify using these offsets called `OffsetIndices`. This class is used to easily retrieve a range of corner indices for each face. This also gives the opportunity for sharing some logic with curves. Another benefit of the change is that the offsets and sizes stored in `MPoly` can no longer disagree with each other. Storing faces in the order of their corners can simplify some code too. Face/polygon variables now use the `IndexRange` type, which comes with quite a few utilities that can simplify code. Some: - The offset integer array has to be one longer than the face count to avoid a branch for every face, which means the data is no longer part of the mesh's `CustomData`. - We lose the ability to "reference" an original mesh's offset array until more reusable CoW from #104478 is committed. That will be added in a separate commit. - Since they aren't part of `CustomData`, poly offsets often have to be copied manually. - To simplify using `OffsetIndices` in many places, some functions and structs in headers were moved to only compile in C++. - All meshes created by Blender use the same order for faces and face corners, but just in case, meshes with mismatched order are fixed by versioning code. - `MeshPolygon.totloop` is no longer editable in RNA. This API break is necessary here unfortunately. It should be worth it in 3.6, since that's the best way to allow loading meshes from 4.0, which is important for an LTS version. Pull Request: https://projects.blender.org/blender/blender/pulls/105938
2023-04-04 20:39:28 +02:00
}
if (um->store.mselect) {
const size_t stride = sizeof(*mesh->mselect);
BArrayStore *bs = BLI_array_store_at_size_get(&um_arraystore.bs_stride[ARRAY_STORE_INDEX_MSEL],
stride);
BArrayState *state = um->store.mselect;
BLI_array_store_state_remove(bs, state);
um->store.mselect = nullptr;
}
um_arraystore.users -= 1;
BLI_assert(um_arraystore.users >= 0);
if (um_arraystore.users == 0) {
# ifdef DEBUG_PRINT
printf("mesh undo store: freeing all data!\n");
# endif
for (int bs_index = 0; bs_index < ARRAY_STORE_INDEX_NUM; bs_index++) {
BLI_array_store_at_size_clear(&um_arraystore.bs_stride[bs_index]);
}
# ifdef USE_ARRAY_STORE_THREAD
BLI_task_pool_free(um_arraystore.task_pool);
um_arraystore.task_pool = nullptr;
# endif
}
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Array Store Utilities
* \{ */
/**
* Create an array of #UndoMesh from `objects`.
*
* where each element in the resulting array is the most recently created
* undo-mesh for the object's mesh.
* When no undo-mesh can be found that array index is nullptr.
*
* This is used for de-duplicating memory between undo steps,
* failure to find the undo step will store a full duplicate in memory.
* define `DEBUG_PRINT` to check memory is de-duplicating as expected.
*/
static UndoMesh **mesh_undostep_reference_elems_from_objects(Object **object, int object_len)
{
/* Map: `Mesh.id.session_uid` -> `UndoMesh`. */
GHash *uuid_map = BLI_ghash_ptr_new_ex(__func__, object_len);
UndoMesh **um_references = static_cast<UndoMesh **>(
MEM_callocN(sizeof(UndoMesh *) * object_len, __func__));
for (int i = 0; i < object_len; i++) {
const Mesh *mesh = static_cast<const Mesh *>(object[i]->data);
BLI_ghash_insert(uuid_map, POINTER_FROM_INT(mesh->id.session_uid), &um_references[i]);
}
int uuid_map_len = object_len;
/* Loop backwards over all previous mesh undo data until either:
* - All elements have been found (where `um_references` we'll have every element set).
* - There are no undo steps left to look for. */
UndoMesh *um_iter = static_cast<UndoMesh *>(um_arraystore.local_links.last);
while (um_iter && (uuid_map_len != 0)) {
UndoMesh **um_p;
if ((um_p = static_cast<UndoMesh **>(
BLI_ghash_popkey(uuid_map, POINTER_FROM_INT(um_iter->mesh.id.session_uid), nullptr))))
{
*um_p = um_iter;
uuid_map_len--;
}
um_iter = um_iter->local_prev;
}
BLI_assert(uuid_map_len == BLI_ghash_len(uuid_map));
BLI_ghash_free(uuid_map, nullptr, nullptr);
if (uuid_map_len == object_len) {
MEM_freeN(um_references);
um_references = nullptr;
}
return um_references;
}
/** \} */
#endif /* USE_ARRAY_STORE */
/* for callbacks */
2016-05-25 19:12:43 +10:00
/* undo simply makes copies of a bmesh */
/**
* \param um_ref: The reference to use for de-duplicating memory between undo-steps.
*/
static void *undomesh_from_editmesh(UndoMesh *um, BMEditMesh *em, Key *key, UndoMesh *um_ref)
2016-05-25 19:12:43 +10:00
{
BLI_assert(BLI_array_is_zeroed(um, 1));
#ifdef USE_ARRAY_STORE_THREAD
/* changes this waits is low, but must have finished */
if (um_arraystore.task_pool) {
BLI_task_pool_work_and_wait(um_arraystore.task_pool);
}
#endif
2016-05-25 19:12:43 +10:00
/* make sure shape keys work */
if (key != nullptr) {
um->mesh.key = (Key *)BKE_id_copy_ex(
nullptr, &key->id, nullptr, LIB_ID_COPY_LOCALIZE | LIB_ID_COPY_NO_ANIMDATA);
}
else {
um->mesh.key = nullptr;
}
2016-05-25 19:12:43 +10:00
/* Uncomment for troubleshooting. */
// BM_mesh_validate(em->bm);
2016-05-25 19:12:43 +10:00
/* Copy the ID name characters to the mesh so code that depends on accessing the ID type can work
* on it. Necessary to use the attribute API. */
STRNCPY(um->mesh.id.name, "MEundomesh_from_editmesh");
/* Runtime data is necessary for some asserts in other code, and the overhead of creating it for
* undo meshes should be low. */
BLI_assert(um->mesh.runtime == nullptr);
um->mesh.runtime = new blender::bke::MeshRuntime();
CustomData_MeshMasks cd_mask_extra{};
cd_mask_extra.vmask = CD_MASK_SHAPE_KEYINDEX;
BMeshToMeshParams params{};
/* Undo code should not be manipulating 'G_MAIN->object' hooks/vertex-parent. */
params.calc_object_remap = false;
params.update_shapekey_indices = false;
params.cd_mask_extra = cd_mask_extra;
params.active_shapekey_to_mvert = true;
BM_mesh_bm_to_me(nullptr, em->bm, &um->mesh, &params);
2016-05-25 19:12:43 +10:00
um->selectmode = em->selectmode;
um->shapenr = em->bm->shapenr;
#ifdef USE_ARRAY_STORE
{
2021-02-14 20:58:04 +11:00
/* Add ourselves. */
BLI_addtail(&um_arraystore.local_links, um);
# ifdef USE_ARRAY_STORE_THREAD
if (um_arraystore.task_pool == nullptr) {
um_arraystore.task_pool = BLI_task_pool_create_background(nullptr, TASK_PRIORITY_LOW);
}
UMArrayData *um_data = static_cast<UMArrayData *>(MEM_mallocN(sizeof(*um_data), __func__));
um_data->um = um;
um_data->um_ref = um_ref;
BLI_task_pool_push(um_arraystore.task_pool, um_arraystore_compact_cb, um_data, true, nullptr);
# else
um_arraystore_compact_with_info(um, um_ref);
# endif
}
#else
UNUSED_VARS(um_ref);
#endif
2016-05-25 19:12:43 +10:00
return um;
}
Fix T44415: Shape keys get out of sync when using undo in edit-mode This is an alternate fix for T35170 since it caused T44415. Having the undo system manipulate the key-block coordinates is error prone as (in the case of T44415) there are situations when it's important to apply the difference with the original shape key. This reverts dab0bd9de65a9be5e8ababba0e2799f994d5d12f, and instead avoids the problem by not using the data in `Mesh.key` as a reference for updating shape-keys when exiting edit-mode. The assumption that the `Mesh.key` in edit-mode won't be modified until leaving edit-mode isn't always true. Leading to synchronization errors. (details noted in code-comments). Resolve this by using shape-key data stored in the BMesh. Resolving both T35170 & T44415. Details: - Remove use of the original vertices when exiting edit mode. - Remove use of the original shape-key coordinates when exiting edit-mode (except as a last resort). - Move shape-key synchronization into a separate function: `bm_to_mesh_key`. - Split the synchronization loop into two branches, depending on the existence of BMesh shape-key coordinates. - Always write shape-key values back to the BMesh CD_SHAPEKEY layers. This was only done in some cases but is now necessary for all shape-keys as these are used to calculate offsets where the `Mesh.key` was previously used. - Report a warning when the shape-key layer isn't found as this uses an imperfect method of restoring coordinates which should only be used as a last resort. Reviewed By: mont29 Ref D14127
2022-02-22 09:57:07 +11:00
static void undomesh_to_editmesh(UndoMesh *um, Object *ob, BMEditMesh *em)
2016-05-25 19:12:43 +10:00
{
BMEditMesh *em_tmp;
2016-05-25 19:12:43 +10:00
BMesh *bm;
#ifdef USE_ARRAY_STORE
# ifdef USE_ARRAY_STORE_THREAD
/* changes this waits is low, but must have finished */
BLI_task_pool_work_and_wait(um_arraystore.task_pool);
# endif
# ifdef DEBUG_TIME
TIMEIT_START(mesh_undo_expand);
# endif
um_arraystore_expand(um);
# ifdef DEBUG_TIME
TIMEIT_END(mesh_undo_expand);
# endif
#endif /* USE_ARRAY_STORE */
const BMAllocTemplate allocsize = BMALLOC_TEMPLATE_FROM_ME(&um->mesh);
2016-05-25 19:12:43 +10:00
em->bm->shapenr = um->shapenr;
EDBM_mesh_free_data(em);
2016-05-25 19:12:43 +10:00
BMeshCreateParams create_params{};
create_params.use_toolflags = true;
bm = BM_mesh_create(&allocsize, &create_params);
2016-05-25 19:12:43 +10:00
BMeshFromMeshParams convert_params{};
/* Handled with tessellation. */
convert_params.calc_face_normal = false;
convert_params.calc_vert_normal = false;
convert_params.active_shapekey = um->shapenr;
BM_mesh_bm_from_me(bm, &um->mesh, &convert_params);
2016-05-25 19:12:43 +10:00
em_tmp = BKE_editmesh_create(bm);
*em = *em_tmp;
/* Calculate face normals and tessellation at once since it's multi-threaded. */
BKE_editmesh_looptris_and_normals_calc(em);
2016-05-25 19:12:43 +10:00
em->selectmode = um->selectmode;
bm->selectmode = um->selectmode;
2018-05-25 22:24:24 +05:30
bm->spacearr_dirty = BM_SPACEARR_DIRTY_ALL;
2016-05-25 19:12:43 +10:00
ob->shapenr = um->shapenr;
MEM_delete(em_tmp);
#ifdef USE_ARRAY_STORE
um_arraystore_expand_clear(um);
#endif
2016-05-25 19:12:43 +10:00
}
static void undomesh_free_data(UndoMesh *um)
2016-05-25 19:12:43 +10:00
{
Mesh *mesh = &um->mesh;
#ifdef USE_ARRAY_STORE
# ifdef USE_ARRAY_STORE_THREAD
/* changes this waits is low, but must have finished */
BLI_task_pool_work_and_wait(um_arraystore.task_pool);
# endif
/* we need to expand so any allocations in custom-data are freed with the mesh */
um_arraystore_expand(um);
BLI_assert(BLI_findindex(&um_arraystore.local_links, um) != -1);
BLI_remlink(&um_arraystore.local_links, um);
um_arraystore_free(um);
#endif
if (mesh->key) {
BKE_key_free_data(mesh->key);
MEM_freeN(mesh->key);
2016-05-25 19:12:43 +10:00
}
BKE_mesh_free_data_for_undo(mesh);
2016-05-25 19:12:43 +10:00
}
static Object *editmesh_object_from_context(bContext *C)
{
ViewLayer: Lazy sync of scene data. When a change happens which invalidates view layers the syncing will be postponed until the first usage. This will improve importing or adding many objects in a single operation/script. `BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing `BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection` or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`. Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out. This patch has been added to discuss the details and consequences of the current approach. For clarity the call to BKE_view_layer_ensure_sync is placed close to the getters. In the future this could be placed in more strategical places to reduce the number of calls or improve performance. Finding those strategical places isn't that clear. When multiple operations are grouped in a single script you might want to always check for resync. Some areas found that can be improved. This list isn't complete. These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer. The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce performance compared to master, but will be fixed by the additional patches. **Object duplication** During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}). **Object add** `BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`). We should make the selection and activation optional. This would make it possible to add multiple objects without having to resync per object. **Postpone Activate Base** Setting the basact is done in many locations. They follow a rule as after an action find the base and set the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which base will be set in the basact during the next sync, reducing the times resyncing needs to happen. Reviewed By: mont29 Maniphest Tasks: T73411 Differential Revision: https://developer.blender.org/D15885
2022-09-14 21:33:51 +02:00
Scene *scene = CTX_data_scene(C);
ViewLayer *view_layer = CTX_data_view_layer(C);
ViewLayer: Lazy sync of scene data. When a change happens which invalidates view layers the syncing will be postponed until the first usage. This will improve importing or adding many objects in a single operation/script. `BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing `BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection` or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`. Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out. This patch has been added to discuss the details and consequences of the current approach. For clarity the call to BKE_view_layer_ensure_sync is placed close to the getters. In the future this could be placed in more strategical places to reduce the number of calls or improve performance. Finding those strategical places isn't that clear. When multiple operations are grouped in a single script you might want to always check for resync. Some areas found that can be improved. This list isn't complete. These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer. The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce performance compared to master, but will be fixed by the additional patches. **Object duplication** During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}). **Object add** `BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`). We should make the selection and activation optional. This would make it possible to add multiple objects without having to resync per object. **Postpone Activate Base** Setting the basact is done in many locations. They follow a rule as after an action find the base and set the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which base will be set in the basact during the next sync, reducing the times resyncing needs to happen. Reviewed By: mont29 Maniphest Tasks: T73411 Differential Revision: https://developer.blender.org/D15885
2022-09-14 21:33:51 +02:00
BKE_view_layer_synced_ensure(scene, view_layer);
Object *obedit = BKE_view_layer_edit_object_get(view_layer);
if (obedit && obedit->type == OB_MESH) {
const Mesh *mesh = static_cast<Mesh *>(obedit->data);
if (mesh->runtime->edit_mesh != nullptr) {
return obedit;
}
}
return nullptr;
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Implements ED Undo System
*
* \note This is similar for all edit-mode types.
* \{ */
struct MeshUndoStep_Elem {
UndoRefID_Object obedit_ref;
UndoMesh data;
};
struct MeshUndoStep {
UndoStep step;
/** See #ED_undo_object_editmode_validate_scene_from_windows code comment for details. */
UndoRefID_Scene scene_ref;
MeshUndoStep_Elem *elems;
uint elems_len;
};
static bool mesh_undosys_poll(bContext *C)
2016-05-25 19:12:43 +10:00
{
return editmesh_object_from_context(C) != nullptr;
}
static bool mesh_undosys_step_encode(bContext *C, Main *bmain, UndoStep *us_p)
{
MeshUndoStep *us = (MeshUndoStep *)us_p;
/* Important not to use the 3D view when getting objects because all objects
* outside of this list will be moved out of edit-mode when reading back undo steps. */
Scene *scene = CTX_data_scene(C);
ViewLayer *view_layer = CTX_data_view_layer(C);
const ToolSettings *ts = scene->toolsettings;
blender::Vector<Object *> objects = ED_undo_editmode_objects_from_view_layer(scene, view_layer);
us->scene_ref.ptr = scene;
us->elems = static_cast<MeshUndoStep_Elem *>(
MEM_callocN(sizeof(*us->elems) * objects.size(), __func__));
us->elems_len = objects.size();
UndoMesh **um_references = nullptr;
#ifdef USE_ARRAY_STORE
um_references = mesh_undostep_reference_elems_from_objects(objects.data(), objects.size());
#endif
for (uint i = 0; i < objects.size(); i++) {
Object *ob = objects[i];
MeshUndoStep_Elem *elem = &us->elems[i];
elem->obedit_ref.ptr = ob;
Mesh *mesh = static_cast<Mesh *>(elem->obedit_ref.ptr->data);
BMEditMesh *em = mesh->runtime->edit_mesh.get();
undomesh_from_editmesh(&elem->data, em, mesh->key, um_references ? um_references[i] : nullptr);
em->needs_flush_to_id = 1;
us->step.data_size += elem->data.undo_size;
elem->data.uv_selectmode = ts->uv_selectmode;
#ifdef USE_ARRAY_STORE
/** As this is only data storage it is safe to set the session ID here. */
elem->data.mesh.id.session_uid = mesh->id.session_uid;
#endif
}
if (um_references != nullptr) {
MEM_freeN(um_references);
}
bmain->is_memfile_undo_flush_needed = true;
return true;
}
static void mesh_undosys_step_decode(
bContext *C, Main *bmain, UndoStep *us_p, const eUndoStepDir /*dir*/, bool /*is_final*/)
{
MeshUndoStep *us = (MeshUndoStep *)us_p;
Scene *scene = CTX_data_scene(C);
ViewLayer *view_layer = CTX_data_view_layer(C);
ED_undo_object_editmode_validate_scene_from_windows(
CTX_wm_manager(C), us->scene_ref.ptr, &scene, &view_layer);
ED_undo_object_editmode_restore_helper(
scene, view_layer, &us->elems[0].obedit_ref.ptr, us->elems_len, sizeof(*us->elems));
BLI_assert(BKE_object_is_in_editmode(us->elems[0].obedit_ref.ptr));
for (uint i = 0; i < us->elems_len; i++) {
MeshUndoStep_Elem *elem = &us->elems[i];
Object *obedit = elem->obedit_ref.ptr;
Mesh *mesh = static_cast<Mesh *>(obedit->data);
if (mesh->runtime->edit_mesh == nullptr) {
/* Should never fail, may not crash but can give odd behavior. */
CLOG_ERROR(&LOG,
"name='%s', failed to enter edit-mode for object '%s', undo state invalid",
us_p->name,
obedit->id.name);
continue;
}
BMEditMesh *em = mesh->runtime->edit_mesh.get();
Fix T44415: Shape keys get out of sync when using undo in edit-mode This is an alternate fix for T35170 since it caused T44415. Having the undo system manipulate the key-block coordinates is error prone as (in the case of T44415) there are situations when it's important to apply the difference with the original shape key. This reverts dab0bd9de65a9be5e8ababba0e2799f994d5d12f, and instead avoids the problem by not using the data in `Mesh.key` as a reference for updating shape-keys when exiting edit-mode. The assumption that the `Mesh.key` in edit-mode won't be modified until leaving edit-mode isn't always true. Leading to synchronization errors. (details noted in code-comments). Resolve this by using shape-key data stored in the BMesh. Resolving both T35170 & T44415. Details: - Remove use of the original vertices when exiting edit mode. - Remove use of the original shape-key coordinates when exiting edit-mode (except as a last resort). - Move shape-key synchronization into a separate function: `bm_to_mesh_key`. - Split the synchronization loop into two branches, depending on the existence of BMesh shape-key coordinates. - Always write shape-key values back to the BMesh CD_SHAPEKEY layers. This was only done in some cases but is now necessary for all shape-keys as these are used to calculate offsets where the `Mesh.key` was previously used. - Report a warning when the shape-key layer isn't found as this uses an imperfect method of restoring coordinates which should only be used as a last resort. Reviewed By: mont29 Ref D14127
2022-02-22 09:57:07 +11:00
undomesh_to_editmesh(&elem->data, obedit, em);
em->needs_flush_to_id = 1;
DEG_id_tag_update(&mesh->id, ID_RECALC_GEOMETRY);
}
/* The first element is always active */
ED_undo_object_set_active_or_warn(
scene, view_layer, us->elems[0].obedit_ref.ptr, us_p->name, &LOG);
/* Check after setting active (unless undoing into another scene). */
BLI_assert(mesh_undosys_poll(C) || (scene != CTX_data_scene(C)));
scene->toolsettings->selectmode = us->elems[0].data.selectmode;
scene->toolsettings->uv_selectmode = us->elems[0].data.uv_selectmode;
bmain->is_memfile_undo_flush_needed = true;
WM_event_add_notifier(C, NC_GEOM | ND_DATA, nullptr);
}
static void mesh_undosys_step_free(UndoStep *us_p)
{
MeshUndoStep *us = (MeshUndoStep *)us_p;
for (uint i = 0; i < us->elems_len; i++) {
MeshUndoStep_Elem *elem = &us->elems[i];
undomesh_free_data(&elem->data);
}
MEM_freeN(us->elems);
2016-05-25 19:12:43 +10:00
}
static void mesh_undosys_foreach_ID_ref(UndoStep *us_p,
UndoTypeForEachIDRefFn foreach_ID_ref_fn,
void *user_data)
{
MeshUndoStep *us = (MeshUndoStep *)us_p;
foreach_ID_ref_fn(user_data, ((UndoRefID *)&us->scene_ref));
for (uint i = 0; i < us->elems_len; i++) {
MeshUndoStep_Elem *elem = &us->elems[i];
foreach_ID_ref_fn(user_data, ((UndoRefID *)&elem->obedit_ref));
}
}
void ED_mesh_undosys_type(UndoType *ut)
{
ut->name = "Edit Mesh";
ut->poll = mesh_undosys_poll;
ut->step_encode = mesh_undosys_step_encode;
ut->step_decode = mesh_undosys_step_decode;
ut->step_free = mesh_undosys_step_free;
ut->step_foreach_ID_ref = mesh_undosys_foreach_ID_ref;
2016-05-25 19:12:43 +10:00
ut->flags = UNDOTYPE_FLAG_NEED_CONTEXT_FOR_ENCODE;
ut->step_size = sizeof(MeshUndoStep);
2016-05-25 19:12:43 +10:00
}
/** \} */