The issue

tl;dr not all per-material state is being reset each time.

Specifically, by rule, if a material specifies map_Kd but doesn't specify kd, it should use a default white. However, if a previous material in the file has specified a kd value, than the subsequent material that only specifies the map picks a black color. This is because the diffuse color gets reset, but the parser's understanding of whether the material has defined the diffuse color is not reset. Therefore, it mistakenly believes the last material has defined the diffuse color and the default-initialized black is used instead of what should be white.

To Reproduce
Obj:

  mtllib mem.mtl
  v 0 0 0
  v 1 0 0
  v 0 1 0
  vn 0 0 1
  usemtl has_map
  f 1//1 2//1 3//1
  usemtl has_kd
  f 1//1 2//1 3//1

Material library bad_diffuse.mtl

  newmtl has_kd
  Kd 1 0 0
  newmtl has_map
  map_Kd test.png

(Use arbitrary file for test.png -- it must exist.)

The material associated with has_map will have an all-black diffuse.

-- EDITED block --

I realized the initial problem statement was incomplete, so I've added the following:

On the other hand, if the declaration of the two materials is reversed, so that the has_map material comes first, then the resulting material will have a white-ish diffuse color.

So, the defect has two symptoms:

1. Parsed materials change based on declaration order.
2. Materials which use map_Kd but not kd may end up black because the diffuse color defaults to black.

-- End of EDITED block --

Expected behavior
The material should have the default diffuse color (0.6, 0.6, 0.6).

Environment

• TinyObjLoader version: sha fe9e713
• OS: linux
• Compiler: gcc 11.4.0
• Other environment n/a