tornavis/source/blender/blenlib/BLI_offset_indices.hh

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

157 lines
4.3 KiB
C++
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
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
#include <algorithm>
#include "BLI_index_range.hh"
#include "BLI_span.hh"
namespace blender::offset_indices {
/**
* References an array of ascending indices. A pair of consecutive indices encode an index range.
* Another common way to store the same kind of data is to store the start and size of every range
* separately. Using offsets instead halves the memory consumption. The downside is that the
* array has to be one element longer than the total number of ranges. The extra element is
* necessary to be able to get the last index range without requiring an extra branch for the case.
*
* This class is a thin wrapper around such an array that makes it easy to retrieve the index range
* at a specific index.
*/
template<typename T> class OffsetIndices {
private:
static_assert(std::is_integral_v<T>);
Span<T> offsets_;
public:
OffsetIndices() = default;
OffsetIndices(const Span<T> offsets) : offsets_(offsets)
{
BLI_assert(std::is_sorted(offsets_.begin(), offsets_.end()));
}
2023-03-29 05:16:26 +02:00
/** Return the total number of elements in the referenced arrays. */
T total_size() const
{
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
return offsets_.size() == 1 ? 0 : offsets_.last();
}
/**
* Return the number of ranges encoded by the offsets, not including the last value used
* internally.
*/
int64_t size() const
{
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
return std::max<int64_t>(offsets_.size() - 1, 0);
}
bool is_empty() const
{
return this->size() == 0;
}
IndexRange index_range() const
{
return IndexRange(this->size());
}
IndexRange operator[](const int64_t index) const
{
BLI_assert(index >= 0);
BLI_assert(index < offsets_.size() - 1);
const int64_t begin = offsets_[index];
const int64_t end = offsets_[index + 1];
const int64_t size = end - begin;
return IndexRange(begin, size);
}
IndexRange operator[](const IndexRange indices) const
{
const int64_t begin = offsets_[indices.start()];
const int64_t end = offsets_[indices.one_after_last()];
const int64_t size = end - begin;
return IndexRange(begin, size);
}
/**
2023-01-20 05:19:32 +01:00
* Return a subset of the offsets describing the specified range of source elements.
* This is a slice into the source ranges rather than the indexed elements described by the
* offset values.
*/
OffsetIndices slice(const IndexRange range) const
{
BLI_assert(offsets_.index_range().drop_back(1).contains(range.last()));
return OffsetIndices(offsets_.slice(range.start(), range.one_after_last()));
}
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
const T *data() const
{
return offsets_.data();
}
};
/**
* References many separate spans in a larger contiguous array. This gives a more efficient way to
* store many grouped arrays, without requiring many small allocations, giving the general benefits
* of using contiguous memory.
*
* \note If the offsets are shared between many #GroupedSpan objects, it will still
* be more efficient to retrieve the #IndexRange only once and slice each span.
*/
template<typename T> struct GroupedSpan {
OffsetIndices<int> offsets;
Span<T> data;
GroupedSpan() = default;
GroupedSpan(OffsetIndices<int> offsets, Span<T> data) : offsets(offsets), data(data)
{
BLI_assert(this->offsets.total_size() == this->data.size());
}
Span<T> operator[](const int64_t index) const
{
return this->data.slice(this->offsets[index]);
}
int64_t size() const
{
return this->offsets.size();
}
IndexRange index_range() const
{
return this->offsets.index_range();
}
bool is_empty() const
{
return this->data.size() == 0;
}
};
/**
* Turn an array of sizes into the offset at each index including all previous sizes.
*/
OffsetIndices<int> accumulate_counts_to_offsets(MutableSpan<int> counts_to_offsets,
int start_offset = 0);
/**
* Create a map from indexed elements to the source indices, in other words from the larger array
* to the smaller array.
*/
void build_reverse_map(OffsetIndices<int> offsets, MutableSpan<int> r_map);
/**
* Build offsets to group the elements of \a indices pointing to the same index.
*/
void build_reverse_offsets(Span<int> indices, MutableSpan<int> r_map);
} // namespace blender::offset_indices
namespace blender {
using offset_indices::GroupedSpan;
using offset_indices::OffsetIndices;
} // namespace blender