Greater control over material creation

[ggadwa]

This is a great tool, and works very well. Material creation is the only sticking point, as to be expected because of format differences.

In my engine, the solution is taking the material name as an abstraction and looking up the color, normal, specular, glow etc from that. Workable, and good enough.

It would be nice if there was an option in the converter that stripped any texture uris down to their name, built KHR_materials_pbrSpecularGlossiness where the base, gloss, and normal were named after the original texture name, and within a textures/ folder (like _color, _specular, etc.) . It would be up to the end user to fix any naming/formats and editing any factors in the material definition.

I understand this is very specific and maybe only useful to me, but looking through the issues I can see things like this have come up often, and there's no good solution.

Example, converter encounters a material "~\work\stuff\morestuff\stone.png" while under this flag.

Would generate material:

  "extensions": {
    "KHR_materials_pbrSpecularGlossiness": {
      "diffuseFactor": [1,1,1],   --> user responsible for editing this
      "diffuseTexture": {
        "index": 2,    --> points at uri textures/stone_color.png
        "texCoord": 0
      },
      "glossinessFactor": 1,   --> user responsible for editing this
      "specularFactor": [1,1,1],   --> user responsible for editing this
      "specularGlossinessTexture": {
        "index": 4,     --> points at uri textures/stone_specular.png
        "texCoord": 0
      }
    }
  },
  "name": "stone",
  "normalTexture": {
    "index": 3,       --> points at uri textures/stone_normal.png
    "scale": 1,
    "texCoord": 1
  }
},

[zellski]

Hi @ggadwa,

Thanks for the kind words! I am glad you're finding the tool useful.

I concur with you that there is a functionality gap that the tool ought to fill for power users. I'm not certain your proposed solution is how I'd do it –– rather than parse URLs and require post-processing on the generated glTF, I would be more interested in optionally consuming a file on the side –– maybe JSON or TOML or something –– which would help map FBX materials to generated values in the asset. This approach would retain the pipeline feel of the tool: input in one end, completed output in the other, as little magic as possible in-between. It should be possible (easy) in such a scenario to get the result you suggest in your example, and if done properly it would give a lot of flexibility to the power user.

Unfortunately, neither of these solutions are at all in scope for me at the moment. This tool still has some serious bugs and is lagging in some pretty core functionality, but my available time is very low. If you have any time available, I would propose you could hack up a local fork or even make a pull request to this repo.

[ggadwa]

Understood. Just an FYI for the future, I've bought and or have gotten made for me a number of custom FBX files. The files almost always look like this:

frog.fbx frog.png (or frog_color.png, or frog_diffuse.png) frog_normals.png (or tif, whatever) frog_specular.png eye.png

I've never not seen a delivery like this, but obviously there are probably many different ways. An FBX file and PBR textures, which either reflect the naming of the material or are close (I've seen a lot of frog_01 inside while the file might be frog.)

There probably is some intelligent matching you could do by reading the directory, but I suspect that would be prone to failure.

So, just an FYI as you are thinking about solutions!

Frankly, right now, it's easy enough to just hand edit the glTF. The big problem is doing the reverse lookups from material -> texture but you only really have to do that once. Thanks for listening!