-
Notifications
You must be signed in to change notification settings - Fork 58
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
Presumably broken hashmap for material listing #37
Comments
Could you post reproducible .obj(and .mtl) file? |
Hi, |
I have tested with your .obj, but material_ids works well.
You should not use I have added an comment how to access tinyobjloader-c/examples/viewer/viewer.c Line 313 in 1fa6cd7
|
I have checked that solution, but I get weird results. |
.obj can have multiple material ids(per-face material). If you use tinyobjloader-c for OpenGL/DirectX application, you first need to re-arrange vertex data by iterating material ids. |
Got it, thanks. For now so using a workaround to instead to get per-face material IDs, use per-object materials by merging them before-hand. |
Hi,
Well firstly I am very grateful to the developers of the C version of Tinyobjloader, and Tinyobjloader itself being a real lifesaver.
So I've been experimenting the library for my own usage, and recently started to add materials support to my program. However, it looks like the Hashmap implementation that handles the material IDs is broken, as it firstly work well with like 1500 triangles, but then returns a large random number that doesn't seem correct.
It happened on 2 different models, with relatively low numbers of materials (2 and 6), and so by printing
printf("Texture mat ID = %d\n", attrib.material_ids[face_offset + 1]);
on every triangle, and at some (random) point in a middle of a shape, the material_id starts to behave strangely:I hope this can be fixed, and I would to thank you very much for all what have been already done :)
The text was updated successfully, but these errors were encountered: