Closed digama0 closed 1 year ago
A bit worrying to see a PR like this, which is well written with a great description, proven to be needed (based on the issue discussion), and has been left without any answer for 9 months.
@kvark, you are right, it is an unreasonable delay and not a good situation for all parties. The delay is due to my own life commitments taking priority than for any other reason. I am working in this space professionally now so you should expect more updates in the near future. @digama0, I apologise for not addressing your PR sooner.
I have been hesitant to extend the import functionality in the past. This is because previous attempts to cater to every possible import scenario (for example, as described in #324) turned out to be overly complicated. Given this is something that is heavily requested, I will reconsider for this use case.
I have some reservations about the proposed API (I would prefer to re-export as suggested) but, given the length of time since the PR was opened, it would only be fair to merge as-is and make cosmetic changes myself.
Fixes #222. New public API:
gltf::import
module (debatable: it would also be possible to keep this private and re-export the other functions)gltf::import::import
andgltf::import::import_slice
: These were already available asgltf::import
andgltf::import_slice
but now you can also see them at this pathgltf::import::{import_buffer_data, import_image_data}
: These already existed but they are nowpub
. This is the part that actually fixes #222.gltf::buffer::Data::{from_source, from_source_and_blob}
: This allows importing just one buffer and getting errors about it. Note thatimport::Scheme
is not made public here.gltf::image::Data::from_source
: Same thing but for images. Most of the logic fromimport_image_data
is now in this function.