I spent a week (!) thinking the extra remapping array is not necessary.
Actually, it is (though with a non-shitty hashmap the allocation could
be done for both) -- this was an university assignment almost a decade
ago and it wouldn't pass if it would be wasting time.

But the english of past me was horrible. Yes.

…t also.

…ere.

It's still extremely bad, but at least something.

Also vastly improved tests and docs.

…type.

The templated version had the unfortunate "feature" of not being able to
figure out the type when an array view or a C array got passed to it.
That led to worse-than-ideal UX and even though it's now a bit more
verbose on the implementation side, it's the preferred solution.

…view.

This also allowed me to move all the complexity and assertions into a
cpp file, no longer polluting the header.

I wonder what was I doing back then.

We have new less shitty APIs, so use them!

The subdivideInPlace() alone wasn't convenient enough.

And rename them to *InPlace(), since that's what they do. The original
STL variants are now deprecated wrappers over the new names. Not
adapting the test yet in order to test everything is alright.

There's a lot to change with the current version -- the bloaty tuple,
the useless min/max, and compressing all the way down to 8 bits is not
desirable anymore either. The new function allows to specify a minimal
type to compress to and works also on 8- and 16-byte types, which makes
it possible to also inflate a smaller type into a larger one.

The old function is now deprecated.

Useful when consuming the indices straight from MeshData.

Better for checking accidents, as picking a wrong primitive / index type
can lead to *serious* rendering issues. Similarly to a change done to
(Compressed)PixelFormat in 2019.10.

This deliberately doesn't follow the PixelFormat enum naming, as RGBA
components make no sense for most vertex data. Checking Metal and
WebGPU, they seem to have arrived at a similar conclusion, only VkFormat
is an outlier.

Otherwise they take up too much space.

With API analogous to the (relatively) new AnimationData -- with one
buffer containing all index data and one buffer containing all vertex
data, both meant to be uploaded as-is to the GPU.

This will eventually replace MeshData2D and MeshData3D, backwards
compatibility and wiring up to other APIs will be done in follow-up
commits.

Deprecating of the old ones comes later.

Will be used for MeshData that don't own the memory.

Turns out the design wasn't so simple after all. AnimationData and
ImageData classes will follow with similar changes.

Follows the change done in 954798a.

Follows the change done in MeshData.

So users aren't force to specify everything on their own. It makes the
test code a bit less painful. But just a bit.

Easier to write. Need to take extra care with default deleters.

First step towards an ability to expose data compiled into an executable
through MeshData without having to allocate anything.

This makes it possible to have fully allocation-less MeshData, with
statically defined indices and attributes. Only the final MeshData
construction needs to be done at runtime because Array is not constexpr,
but that isn't anything heavy anyway.

There's a ton of parameters and it's just unreadable without.

Similarly to ImageData::pixels() which return a strided array view of
one dimension more.

It made testing and everything harder than strictly necessary. OTOH
still keeping MeshData as a friend and accessing members directly since
those are heavily interconnected anyway.

Will be used in MeshTools algorithms. Also harden the MeshData
constructor to reject such instances.

Again useful for MeshTools algos.

Like with attributes, it returns a 2D strided view with the second
dimension having the same size as the index type.

Allow to make:

 - an indexed mesh with zero indices
 - a mesh with non-zero attribute count but zero vertices
 - a mesh with non-zero vertex count but zero attributes

All of these are valid use cases as explained in the tests, and will
also make the release*() behavior defined better.

…a().

It only resets count of released thing to zero, not going all nuclear.
Otherwise it wouldn't be possible to release attribute data and then
vertex data as releasing one would wipe the other.

Useful for quick localization of named attribs when dealing with
attributeData() (for example in MeshTools).

Will be used to distinguish if the data need to be repacked or not in
various tools.

This was originally meant to be an interleave() that operates on
MeshData, but later I realized I need the same logic in duplicate(), so
turned it into a private function. Now I am pretty sure I'll be using
this function in *many* importer plugins :D

Also add new variants that allow for external buffers.

For backwards compatibility these will delegate to the new MeshData
interfaces for 3D (and nothing for 2D, because so far there were no 2D
scene importers).

The internals don't use any std::vector anymore, only the icosphere
needs an std::unordered_map to do duplicate removal. Additionally, the
most simple primitives are now simply views on constant data,
being completely zero-allocation.

On a Mac this resulted in the dylib going down from 1.5 MB to 418 kB in
Debug, and from 129 kB to 90 kB in Release. Quite nice.

The tests are not ported away from MeshDataXD yet as I want to ensure
the behavior is *exactly* as before.

Improving the tests a bit for trivial primitives to ensure the attribute
layouts are correct, not just counts.

Intentionally not enabling / documenting the double types for use with
positions / normals / ... yet. Might come later (or never).

This was a LONG unexpected detour... I mean, I expected it, but not so
soon.

Hur hur.

Before it was a 32-byte structure with 3 bytes free (or a 20-byte
structure with 3 bytes free), now it's a 24-byte structure with 5 bytes
free. Exploiting the fact that strides can't be too high for a GPU
anyway (so 2 bytes is enough instead of 8), and vertex count is capped
to 32bit by MeshData anyway (so no need for 8 also), saving 10 bytes on
a 64-bit build.

Originally this was done in order to make handling of deserialized data
much simpler (as for those attributes also need to only contain an
offset into some unknown data array), but seems this could be very
useful elsewhere as well -- for example when the layout is known
beforehand but the actual data not yet -- such as in the Line and
Gradient primitives (going to switch them to this in the next commit).

What still unfortunately has to be known in advance is the actual vertex
count (as supplying it directly to MeshData would mean adding 6 new
constructor overloads, and there's enough of those already). Might
revisit later.

One less allocation for each.

Similarly to PixelFormat. Will be useful for Vulkan, unfortunately not
so much for GL because there the format is specified by three orthogonal
values and it's a terrible mess.

GL was missing a check whether given format is available on a target
(for example double types are not on ES), and for Vulkan we need something
similar to pixel format mapping as well.

The last major bit needed for meshlet support.

…ues.

And also handle them specially in GL::meshPrimitive() and
Vk::vkPrimitiveTopology().

To support meshes that are not so GPU-friendly. And also meshlets at a
later point.

Similar to image mip level import, but this is largely left to be
importer-specific. For example PLY defines per-face data and sometimes
one might want to import them as-is, without them being turned into a
per-vertex property.

I need to put the resulting index array into a pre-existing allocation.

Not the tests yet -- those will get done in the next round.

Replaces the STL-heavy combineIndexedArrays(), but in a less extremely
horrendous way.

The combineIndexArrays() and combineIndexedArrays() API is replaced with
a more generic combineIndexedAttributes(), and thanks to that we also
don't need STL-based duplicate() and removeDuplicates().

Those work without modifying the input data. The *Indexed and fuzzy
variants are missing as I don't need those right now, but might get
added later.

Less code and complexity than first creating a StridedArrayView in
data() and then extracting offset/stride from there.

Until now, except for an attribute-less index-less mesh, the vertex
count was only implicitly taken from passed attributes, but it was
severely limiting:

 - There was no way to set vertex count for an attribute-less
   indexed mesh, which didn't make sense
 - All code that made non-owning MeshData instances referencing another
   MeshData had to explicitly handle the attribute-less corner case to
   avoid vertex count getting lost
 - Offset-only attributes couldn't be used to specify static layout of
   meshes with dynamic vertex count, causing unnecessary extra
   allocations especially in the Primitives library.

Now possible in all cases, except for grid, where the combination count
is too large to be practical, even more so with the introduction of
tangents in the future.