2024 / Version 2.0 Plan about gltf

[alteous]

A substantial amount work has been going on over the last month or so. New macros have been added to gltf-derive which have simplified the main crate code considerably. The JSON data structures are much friendlier to use. I expect the whole crate code will be reduced by ~70% when it's ready.

I'm planning to open a large PR soon. There will be a final 1.4.1 release for the latest fixes before a 2.0 release is entertained.

[ShaddyDC]

Any plans to take other 3d-formats and export to glTF? (perhaps even visa-versa)

My use case is that I would like to serve .stp, .stl and .3mf files to a renderer in the frontend. My infrastructure is all rust, and would like to stay in rust if possible.

I'm not sure about the scope of what I'm asking. From what I managed to glean from basic research, it would seem that there isn't really any libraries to do this, just software features. I think it would be a great contribution to the community at large if there was a single library that managed this, so instead of it becoming absorbed into the codebase of blender, for example, it exists as part of a pseudo-standard library that can be integrated into any software that needs to work with gltf.

I think you might want to create a new issue for this. That being said, while I'd love to have that functionality, the scope of what you're asking about is pretty big.
If I understand you correctly, you mainly care about converting 3d formats to glTF, right?
Without going into the other possible formats you might care about (usd, 3dxml, collada ...) each file format has its own unique quirks and features that don't map cleanly to glTF and vice versa. Each will have special cases that you have to handle one way or another with annoying trade-offs, or even information that you have to drop altogether because it isn't cleanly supported (say comments, or multiple levels of details etc).
If you want to allow conversions in both directions, you double this complexity. If you want to allow converting from any format to any format, you now either have to support an exponential number of converters ($n\cdot n$), or you build and maintain an internal super format that supports all features across all formats that all conversions use as an intermediate step.
That being said, I'd really appreciate it too if such a library existed, but I don't think you can reasonably expect it to be added to this crate.

[torokati44]

A new release with #414 in it is now the only thing blocking emilk/egui#4160.

[scottmcnab]

Have you got any plans to support the EXT_mesh_features and EXT_structural_metadata extensions?

Having support for writing/reading these extensions would be very useful now they are fully supported in Cesium Ion.
Thanks

[alteous]

@scottmcnab, if the only requirement is to be able to read the JSON then these objectives will make supporting new extensions much easier. Having said that, there are no plans to support any particular extension in the near future. If you need a quick solution in the meantime then you might want to consider using #395.

[alteous]

I've come up with a neat (albeit slightly cursed) way of auto-generating the top-level glTF crate: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=516e6a2c73525eb5efbd0412789923e1
The generated document suffers a bit but perhaps the type references could be generated too.

[alteous]

serde-rs/serde#2677

[Ben-PH]

Any plans to take other 3d-formats and export to glTF? (perhaps even visa-versa)

My use case is that I would like to serve .stp, .stl and .3mf files to a renderer in the frontend. My infrastructure is all rust, and would like to stay in rust if possible.

I'm not sure about the scope of what I'm asking. From what I managed to glean from basic research, it would seem that there isn't really any libraries to do this, just software features. I think it would be a great contribution to the community at large if there was a single library that managed this, so instead of it becoming absorbed into the codebase of blender, for example, it exists as part of a pseudo-standard library that can be integrated into any software that needs to work with gltf.

[Ben-PH]

Thanks for the feedback. I can now see the nature of my question better, and see that is probably well out-of-scope of this project.

[torokati44]

Looking forward to the 1.4.1 release with the dependency bumps! 🤞
Thank you for your work!