-
Notifications
You must be signed in to change notification settings - Fork 594
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
Experimental loader uses a different API than stable one #174
Comments
Optimized loader lacks some features(e.g. parsing texture options), and at time moment I found it is difficult to replace the stable one without breaking API. So I think I may be better to create new repo for optimized loader, say |
Any update on this? I'm importing multiple textured meshes for a project and it's taking a long time. I was hoping this could be an addition or replacement for loading each model in a separate thread, didn't get this working yet because each thread requires the active GL context... |
No update. I've recently started to introduce v2 API(still in release candidate) https://github.com/syoyo/tinyobjloader/blob/master/tiny_obj_loader.h#L468 So it would be a good chance to merge multi-threaded parser to tinyobjloader master(and change v2 API if required) |
...and it's not documented. I can use the optimized loader for basic model loading, but I'm having some difficulties doing something a bit more sophisticated (e.g. why doesn't the experimental loader use
mesh_t
?).My questions are: is the experimental loader API going to replace the stable one, or the other way around, or will they stay different? Do you plan on making the optimized loader the default one or will it remain experimental? Is there a particular reason why I shouldn't prefer using the faster one?
The text was updated successfully, but these errors were encountered: