compactBuffer does not preserve glTF alignment requirements

[Kevin Ring]

As explained in detail by @javagl here:
#857 (comment)

[Marco Hutter]

I think that it makes more sense to respond here instead of the PR:

^{From this comment:}

If I have that right, I think we can still deal with it relatively easily just be being conservative about it. If a bufferView is originally aligned to 2 or 4 bytes, whether it needs to be or not, we make sure we preserve that alignment by deleting slightly fewer bytes than we otherwise would.

Usually, you'll be able to get away with maintaining any previous alignment (i.e. when the size of the change is a multiple of 4, the result should be fine). But... only for core glTF:

Are there any bufferViews that need to be aligned to 8 bytes?

Yes. Buffer views that contain 64bit components as part of EXT_structural_metadata :

Each buffer view byteOffset must be aligned to a multiple of its component size.

Implementation note: Authoring tools may choose to align all buffer views to 8-byte boundaries for consistency, but client implementations should only depend on 8-byte alignment for buffer views containing 64-bit component types.

Now... this does not even depend on accessors, so it could be hard to integrate that constraint generically. (I also don't consider this yet in my implementation - it will have to go somewhere here, but there's currently a refactoring going on for that anyhow...)

I also considered the "lazy" option: When assembling data from accessors into buffer views or buffer views into accessors, one could always pad everything to 8 bytes. No alignment issues. No questions. Everything will always be aligned properly. (Except for, maybe, the columns of matrix types. But this is already tracked in #677 - and one could try to keep this in mind when trying to fix this).

But at this point, I felt some highly irrational form of "pride", and didn't want to create a layout that wastes these bytes. It's probably not worth the effort.

From a quick look, glTF-Transform seems to always apply a 4-byte-padding as well, for example, in the writer, but I haven't read the whole thing yet. But... while scrolling over it, this part caught my attention, and that may also be worth looking at more closely...

[Kevin Ring]

I think I'm pretty happy to keep it simple and align every bufferView to 8 bytes. I guess it's theoretically possible that some future extension could require 16-byte alignment, but hopefully very unlikely, right?