-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple obj/mtl parsing from IO #25
Comments
How about the Is there something else that might be missing? Perhaps this is just a question of documenting this use case? |
Yes, thanks. I understand it's not easy to decouple parsing from file IO when filenames are embedded inside the obj file, but in my opinion it would make the crate more useful when file IO is mostly provided for convenience, if at all. Ideally, Fwiw, I ended up using a proc-macro to embed static mesh data in my binary and inside the proc-macro I can do regular file IO. (Since I'm targeting wasm I try to reduce the number of http requests.) Your crate works great, btw! Thanks! |
I agree with this sentiment. Perhaps we should rename The other action item here I think is to update the docs with an example of loading from a file and loading from a string or byte array. |
Sounds great! Thanks! Please also consider making it possible to remove any file IO via a feature, so that the crate can be used for targets like wasm. (I believe going all no_std doesn't seem viable for this crate due to use of Vecs in a lot of places. I could be wrong.) |
Please consider decoupling of parsing from IO operations. I wanted to use your crate, but noticed that it doesn't provide loading of obj/mtl from &str or byte array. For my current project I cannot use regular file IO.
Maybe in addition to the load_X functions there could be read_X functions that are free of IO.
The text was updated successfully, but these errors were encountered: