Separate meshIO from manifold bundles

[elalish]

meshIO is not really a core part of this Manifold library. It is the only part that depends on Assimp (a large, complicated dependency) and it is unlikely to fit into other libraries well, as they probably have their own mesh input/output anyway. I only included meshIO as a means to quickly test this library, but the functionality is lacking (no texture/property support for one thing). I don't want to focus on that, as it's a complicated area in its own right and others do it better. For C++, it's easy enough to not include that part, but for building bundles like WASM and Python, I think it's important to keep this separate.

I'm fine with either removing meshIO from these bundles to focus only on our core library, or if we find it to be really useful, then making a separate bundle for meshIO. There is no dependency between meshIO and manifold since they communicate via Mesh, so the separation should be pretty clean.

[pca006132]

For testing, I guess we can just write a simple function to read/write ply files? We don't need to support the spec, just make sure that the output can be read by other 3D programs for debugging should be enough.

[elalish]

I think meshIO is working fine for testing our C++. For WASM, I'd prefer to write a bridge to an existing library like three.js that already supports lots of 3D format I/O. For Python, a Blender integration is probably a good equivalent as suggested by @rsaccon, since that's another project with lots of 3D format I/O support. These integration bridges can serve as code samples for anyone who wants to integrate the library elsewhere.

[fire]

https://github.com/ddiakopoulos/tinyply has some good support

https://github.com/nmwsharp/happly is great too. I have personally used nmwsharp's projects!

[makc]

@elalish

For WASM, I'd prefer to write a bridge to an existing library like three.js that already supports lots of 3D format I/O.

as much as I love three.js, I would think this is a user's job to pick a js lib and use it? what they could use is a cpp file for embind that exposes basic Mesh and Manifold methods.

[elalish]

This is now complete for web, since we have a WASM bundle that doesn't include meshIO and has an example linking it to three.js. I'm tempted to remove meshIO from the python bindings too, but that would only make sense if we could find an existing python library for 3D file import/export that we could hook into.

[elalish]

I like the look of https://github.com/nschloe/meshio for a Python library for 3D file import/export. If I can manage to hook that up into our Python examples, then I'll remove our own export function from the bindings and remove the Assimp dependency.