Consider adding export or splitting representation into separate crate

[djeedai]

Hi,

It looks like this crate can only load glTF files, but not export/save them. Several projects like Bevy already need or will need sooner or later to save glTF files. At that point, the current limitations will force using a separate export crate, and writing a ton of conversion code between the two memory representations of the two crates.

I'd like to suggest two options to avoid this:

• add support for exporting/saving glTF to the current library, which will make it a one stop shop for glTF handling (provided there's a way to access the glTF representation in memory to modify it)
• defer the common in-memory representation and possibly the editing to a separate crate, which would be consumed by gltf-rs to do loading, and any other crate to do saving, without the need for boilerplate glue code.

I don't know if any of those have been considered already but I couldn't find any relevant issue. Sorry if I missed one.

Thanks!

[FrankenApps]

There already is excellent support for exporting and saving GLTFs. I use this in a lot of my projects. There even is a super simple example to get you started.

Btw.: Even Binary and JSON Based GLTFs can be exported.

[djeedai]

Thanks @FrankenApps ! So can we do load-modify-save this way? It seems like the example manually builds a JSON instead of taking a glTF representation (Gltf object); it even creates its own Vertex type for example. Does that mean this is possible but everything needs to be done manually?

[ShaddyDC]

I believe everything needs to be done manually currently, yes. Fwiw, the crate gltf-json that contains the actual in-memory representation already is separate from the main crate, so it should be possible to consume it and allow interoperation. The Document::from_json and Document::into_json functions are very relevant for that use case, as documented here.

I do not know what the situation will be with #409.

[djeedai]

Thanks for the detailed answer!