Experimental loader uses a different API than stable one

[silverweed]

...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?

[syoyo]

My questions are: is the experimental loader API going to replace the stable one, or the other way around, or will they stay different?

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 tinyobjloader-opt.

[TimTreurniet]

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...

[syoyo]

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)