Obj2gltf ignores mtl materials

CesiumJS
1

I have some model on obj+mtl format. When I import this model to Blender, I see nice materials of different colors. When, however, I convert this model to gltf (or glb) format, using obj2gltf, I get some grey object. This is how I do conversion:

$ obj2gltf -i 9c556d01-c477-46b1-94be-87803ee2a59e.obj -o 9c556d01-c477-46b1-94be-87803ee2a59e.gltf

These files are available through these links (obj, mtl) and this is the resulting gltf file.

I ivestigated the contents of both mtl and gltf files and see, for example, that this material from mtl:

newmtl surface-style-42644--------------------------,---------------------(ral-9010)
Kd 0.945098039215686 0.925490196078431 0.882352941176471
Ks 0.5 0.5 0.5
Ns 64

corresponds to this material in gltf:

{
      "name": "surface-style-42644--------------------------,---------------------(ral-9010)",
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          0.5,
          0.5,
          0.5,
          1
        ],
        "metallicFactor": 0,
        "roughnessFactor": 1
      },
      "emissiveFactor": [
        0,
        0,
        0
      ],
      "alphaMode": "OPAQUE",
      "doubleSided": false
    }

And in fact all materials in gltf file looks absolutely identical. What may be wrong with that and how can I fix it?

2

The OBJ file does not refer to the MTL file.

Apparently, it is often the case that the OBJ and the MTL file have the same name. And maybe some tools make the assumption that when they load an OBJ file, then the MTL file that should be used will have the same name. But the “specification” at Object Files (.obj) says

mtllib filename1 filename2 . . .

[…]

Specifies the material library file for the material definitions
[…]

filename is the name of the library file that defines the
materials. There is no default.

(Emphasis by me)

When you add the line
mtllib 9c556d01-c477-46b1-94be-87803ee2a59e.mtl
as the first line in the OBJ file (you can just do this with a text editor, in doubt), then it should work as expected.

3

@Marco13 Thank you so much! That seems to solve the problem. However, it is strange a little bit, because these files are produced by IfcOpenShell. Looks like a bug.

4

I don’t know that toolkit, but you might consider to (look through the issues to see whether it is already discussed, and if not, then) bring it up as an issue in GitHub - IfcOpenShell/IfcOpenShell: Open source IFC library and geometry engine