Please describe the name of unit test function for this: Adds a supporting unit test.

Therefore, we should skip usemtl directives

I'm not sure it is ok to skip. Parsing content of material could ignored, but at least materialId should be assigned to a mesh(face) based on usemtl.

What would it mean to assign the material id if no materials get loaded? The material would have all default values. But the presence of the id would misleadingly suggest that those values are part of the material associated with that id. It seems a material should either be obviously defaulted, or it should be the user specified material, but mixing the two seems odd.

What would it mean to assign the material id if no materials get loaded?

For example there may be a situation that just use usemtl to group faces.

And you are welcome to investigate how other DCC tool(e.g. meshlab, Blender) handle such situation.
I suppose materialId(or material name) will be assigned to the mesh(faces) even no mtllib or material file(.mtl) does not exit.

So, the solution would be to reshuffle things.

If no material reader is available, we can assign the material id, but the material will remain "undefined".

Do I understand your proposal properly?

I was looking at the surrounding code. I was looking at what currently happens.

If there is a material reader, but the user has named a material that isn't defined in a material library, the material id is assigned -1 (and a warning is printed). The PR as it stands seems to be a logical continuation of that. You don't create a fake material ID for that material name, you leave it as the default -1 value. It seems that omitting a material library is the logical extension of that. By definition, if there is no material reader then all of the named materials are not present in the material map and get treated the same. The only difference is that by omoitting a material reader, you're basically saying, "Don't tell me about it". But the parsed result would be the same.

Similarly, if a user calls LoadObjWithCallbac() and they *provideausemtl_cb`, you get the same result as passing a null material reader. The material id stays -1 and no warning gets printed.

I was looking at the surrounding code. I was looking at what currently happens.

Thanks for the investigation! The behavior in tinyobjloader is different what I am expected(I was expected tinyobjloader assign materialId even when no material file or no mtlreader exists)

I have tested .obj without mtllib but usemtl. Blender reads it and construct per-face material.

nomat.zip

(change material color after load)

MeshLab seems failed to load it(assign default materialId to all faces)

Its a bit difficult decision, but I'd like to follow Blender's behavior for tinyobjloader. i.e. assign materialId(or material name) to faces even when failed to load material(or no mtl reader assigned). I'll open an issue to discuss about it.

Alright. It seems to make sense to resolve #384 first and the come back around to this and see if this is necessary/helps.

The primary point of this PR is not to determine what material to use if a material definition is missing, but to control what warnings are emitted. They are independent decisions. If a material reader is provided, and material definitions can't be located, it makes sense to explicitly warn about that. But if no material reader is provided, it makes sense to skip the warnings. The materials assigned, in both cases, would be the same - associated with the name which appears in usemtl but given default properties.

Oh I see. Thanks! so this PR is ready to merge. Please wait a bit for the review.

Sorry, I didn't mean to push for merging. (Although, I'm perfectly happy with moving forward as is.)

As long as you're content that this PR is consistent with tinyobj as it currently is, then I'm in favor of proceeding. It means that the small change introduced here will get touched again when #384 gets resolved (i.e., instead of skipping immediately, we'd wait a bit later to introduce "placeholder" materials).

I defer to you. In our usage, we check out tinyobj and apply patches to it that suit our needs. If we have patches that we feel would benefit upstream code, we submit PRs (like this one) and then eventually upgrade and remove our patch. But our workflow isn't blocked while we wait. So, I'll let you decide on the order you'd like to handle this and #384.

Where did we end up on this?

I know you were interested in implementing new semantics for missing materials (to match blender). If there's no immediate plan for implementing those, I'd propose we go ahead and merge this. What do you think?

You said

Sorry, I didn't mean to push for merging. (Although, I'm perfectly happy with moving forward as is.)

and PR isn't a critical fix, so I lower the priority. I'll revisit this PR at some time(no ETA, may be after a half-year or more)

Also, if you want to increase the priority of merging the PR, please describe the PR in clear and concise manner(your description contains many redundant texts).

Also, if you want to increase the priority of merging the PR, please describe the PR in clear and concise manner(your description contains many redundant texts).

I'm not sure you mean "redundant" texts. There's only about 50 words there. Not much room for redundancy.

I'm happy to modify the PR description if you can tell me in what way it is lacking. The PR is quite small: about 11 lines. It does two things:

1. Interpret the omission of a material reader as an active choice by the caller and infer that the parser shouldn't emit warnings/errors about not finding materials which, by definition, won't be found.
2. Correct an error with macros that prevents building tests on linux. (This wasn't the point of this PR, merely a requirement to evaluate test the change).

Would it help if I separated those two items? Then the purely mechanical bug in the use of macros can pass through without difficulty and you can help me understand what is lacking in the documentation of the other ten lines.

However, I respect your choice if you simply decide to defer this. If there's something I can do to lead to this PR merging, I'll happily do it. If there isn't, then I'll simply adjust my expectations.