Loading materials

[latencyhiding]

Not an issue per se, but I just wanted to get an update on some of the contributors' plans for completing this.

Scanning through the code, it seems like the thing that needs to be done to wrap up the material loading is mapping material IDs for each face. Is it worth implementing a hashmap right in the file, or should it suffice to just keep a list of hashed material names that you search through linearly?

[syoyo]

Thanks for pointing out.

As you noticed,

https://github.com/syoyo/tinyobjloader-c/blob/master/tinyobj_loader_c.h#L1081

Updating material_id is TODO because I was a bit troublesome to implement string-to-int hash function :-)

The best way is to implement (portable) string hash table like this,

http://stackoverflow.com/questions/20462826/hash-function-for-strings-in-c

But for a while, simple linear search should be enough since the number of materials are usually small(~100)

[latencyhiding]

I haven't very fully tested it yet but I made a pull request at https://github.com/syoyo/tinyobjloader-c/pull/5 where I implemented a simple hashtable with quadratic probing and added it to parse_obj and parse_mtl (I renamed parse_mtl to parse_and_index_mtl, which fills a hash table with the material names and their indices and their names, and created parse_mtl which calls parse_and_index without providing a hash table (parameter is NULL)).

[latencyhiding]

Also I forgot to mention this before, but shouldn't tinyobj_parse_obj have the material file's data as a parameter? If tinyobj_parse_obj's intention is to allow the user to load their file however they want (hence the buf and len parameters, but no filename parameter), then perhaps it should also allow the user to feed it the data from the material file, rather than designing the function to not use fopen but then requiring it once a material filename is encountered.

I have a couple of ideas:

• The user could provide a callback (a "functor" struct containing a function pointer and a pointer to some data) that allows them to load the mtl file their way if a name is found.
• tinyobj_parse_obj could be split into one function that scans for a mtl filename and another function that actually loads the obj. The user would find the mtl filename by calling the first function, load the file data how they wish, then provide that file's data and the obj file's data to the second function.
• tinyobj_parse_obj would store the material names and the mtllib files, and a separate function would patch in the indices. Or, the library doesn't patch in the indicies at all and lets the user link faces to materials.

Again this is an API decision, would be great to get some feedback!

[syoyo]

Thanks for hashing feature!

For API, yes, you can implement callback based API like tinyobj_parse_obj_with_callbacks

Please see example in C++ version: https://github.com/syoyo/tinyobjloader/blob/master/tiny_obj_loader.h#L316

Callback based API also make it possible to read .mtl data from memory.

[syoyo]

So, possible API design is

tinyobj_parse_obj_with_mtl_callback

I will consider to rewrite tinyobj_parse_and_index_mtl_file so that it could read .mtl data from user supplied callback function and memory.