Faster MeshletMesh deserialization

[JMS55]

Objective

• Using bincode to deserialize binary into a MeshletMesh is expensive (~77ms for a 5mb file).

Solution

• Write a custom deserializer using bytemuck's Pod types and slice casting.
  • Total asset load time has gone from ~102ms to ~12ms.
• Change some types I never meant to be public to private and other misc cleanup.

Testing

• Ran the meshlet example and added timing spans to the asset loader.

---

Changelog

• Improved MeshletMesh loading speed
• The MeshletMesh disk format has changed, and MESHLET_MESH_ASSET_VERSION has been bumped
• MeshletMesh fields are now private
• Renamed MeshletMeshSaverLoad to MeshletMeshSaverLoader
• The Meshlet, MeshletBoundingSpheres, and MeshletBoundingSphere types are now private
• Removed MeshletMeshSaveOrLoadError::SerializationOrDeserialization
• Added MeshletMeshSaveOrLoadError::WrongFileType

Migration Guide

• Regenerate your MeshletMesh assets, as the disk format has changed, and MESHLET_MESH_ASSET_VERSION has been bumped
• MeshletMesh fields are now private
• MeshletMeshSaverLoad is now named MeshletMeshSaverLoader
• The Meshlet, MeshletBoundingSpheres, and MeshletBoundingSphere types are now private
• MeshletMeshSaveOrLoadError::SerializationOrDeserialization has been removed
• Added MeshletMeshSaveOrLoadError::WrongFileType, match on this variant if you match on MeshletMeshSaveOrLoadError

[fintelia]

Does LZ4 compression actually help? You might have to use delta encoding (i.e. instead of storing indices you'd store the wrapping difference from the previous index) if you want it to have much impact

[JMS55]

It did when I used bincode, I should probably double check again.

Nanite has a whole bunch of tricks they use for compressing disk and in-memory asset data, but they're low priority for me vs runtime performance at the moment, and I don't really have much experience with this field https://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf.

[JMS55]

9.73mb without compression, 4.97mb with.

[JMS55]

I wish I could directly wrap Bevy's &mut dyn Reader in a FrameDecoder, rather than read to a Vec first, but it's not possible as Reader doesn't implement the typical std::io::Read sync trait - only Bevy's custom async traits :(

@cart any thoughts?

[JMS55]

We can make adapters like so:

struct AsyncWriteSyncAdapter<'a>(&'a mut Writer);

impl Write for AsyncWriteSyncAdapter<'_> {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        block_on(self.0.write(buf))
    }

    fn flush(&mut self) -> std::io::Result<()> {
        block_on(self.0.flush())
    }
}

struct AsyncReadSyncAdapter<'a>(&'a mut dyn Reader);

impl Read for AsyncReadSyncAdapter<'_> {
    fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> {
        block_on(self.0.read(buf))
    }
}

[JMS55]

Not having to allocate an intermediate vec was a nice perf/memory win.

[pcwalton]

Looks fine, just a couple of suggestions.