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.
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).
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
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.
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.
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.
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.
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.
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.
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.