2023-01-18 11:52:27 +01:00
|
|
|
/* 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>
|
|
|
|
|
2023-01-18 11:52:27 +01:00
|
|
|
#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:
|
2023-03-21 21:53:46 +01:00
|
|
|
OffsetIndices() = default;
|
2023-01-18 11:52:27 +01:00
|
|
|
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. */
|
2023-01-19 20:48:20 +01:00
|
|
|
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();
|
2023-01-19 20:48:20 +01:00
|
|
|
}
|
|
|
|
|
2023-03-20 18:34:04 +01:00
|
|
|
/**
|
|
|
|
* Return the number of ranges encoded by the offsets, not including the last value used
|
|
|
|
* internally.
|
|
|
|
*/
|
|
|
|
int64_t size() const
|
2023-01-19 20:48:20 +01:00
|
|
|
{
|
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);
|
2023-01-19 20:48:20 +01:00
|
|
|
}
|
|
|
|
|
2023-03-20 18:34:04 +01:00
|
|
|
bool is_empty() const
|
|
|
|
{
|
|
|
|
return this->size() == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
IndexRange index_range() const
|
|
|
|
{
|
|
|
|
return IndexRange(this->size());
|
|
|
|
}
|
|
|
|
|
2023-01-18 11:52:27 +01:00
|
|
|
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-19 20:48:20 +01:00
|
|
|
|
|
|
|
/**
|
2023-01-20 05:19:32 +01:00
|
|
|
* Return a subset of the offsets describing the specified range of source elements.
|
2023-01-19 20:48:20 +01:00
|
|
|
* 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();
|
|
|
|
}
|
2023-01-18 11:52:27 +01:00
|
|
|
};
|
|
|
|
|
2023-05-24 13:16:57 +02:00
|
|
|
/**
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2023-01-18 11:52:27 +01:00
|
|
|
/**
|
|
|
|
* Turn an array of sizes into the offset at each index including all previous sizes.
|
|
|
|
*/
|
2023-05-24 13:16:57 +02:00
|
|
|
OffsetIndices<int> accumulate_counts_to_offsets(MutableSpan<int> counts_to_offsets,
|
|
|
|
int start_offset = 0);
|
2023-01-18 11:52:27 +01:00
|
|
|
|
2023-04-04 22:12:17 +02:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2023-05-24 13:16:57 +02:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
|
2023-01-18 11:52:27 +01:00
|
|
|
} // namespace blender::offset_indices
|
|
|
|
|
|
|
|
namespace blender {
|
2023-05-24 13:16:57 +02:00
|
|
|
using offset_indices::GroupedSpan;
|
2023-01-18 11:52:27 +01:00
|
|
|
using offset_indices::OffsetIndices;
|
2023-05-24 13:16:57 +02:00
|
|
|
} // namespace blender
|