MakeGLTF for Linux (based on GLTF Packer)

[Gabriele Graves]

Hi All,

I wanted a Linux version of the excellent GLTF Packer by @Extrude Ragu to create materials for PBR as I don't run Windows.  So I created one and it's called MakeGLTF.  It is based on the source code published for GLTF Packer in the sense that I learned how GLTF Packer works and made the UI look and feel similar but MakeGLTF has been written entirely from scratch with a completely different toolkit (Avalonia) using that knowledge.  It uses the same MIT License as GLTF Packer and comes with all sources for others to build on.

It is hosted on GitHub with full instructions and should be accessible to anyone.

MakeGLTF (GitHub)

I hope it is useful to people and my thanks go to @Extrude Ragu for their generosity in making GLTF Packer available to learn from in the first place.

 

[Extrude Ragu]

Glad I could help even the linux community, if just through providing the source. I like the layout switcher

[Gabriele Graves]

I've just pushed an update that provides a Windows build of MakeGLTF as well.  I hope this is OK, it was due to a request and only needed one minor modification to make it once I gained access to a Windows machine as the Avalonia toolkit is cross-platform.

Edited January 19 by Gabriele Graves

[Frionil Fang]

Thank you for this tool, and a feature improvement request: update the images automatically before building the gltf file. I do most of my materials fiddling in an image editor so this tool is very handy, but I have to manually unload and reload the image every time it changes. GLTF Packer seems to lock the files entirely so my image editor (paint.net) is unable to write to them while the Packer is open.

I did manage to make my own build with a hack job accomplishing the auto-updates (just reloads the images from the known paths before processing the save, doesn't check if they've changed or anything), but it might be generally useful too.

[Gabriele Graves]

@Frionil Fang Thank you and I'm glad you are finding it useful.  I liked your improvement suggestion and so I have incorporated it into the application.  The latest code and builds now watch for changes to the files it has loaded and will reload them automatically when a change is detected, including deletions and renaming.  Due to pre-emptively reloading the changed files, there was no need to do any re-reading at save time as they will always be the latest copy from the disk.

I have fixed the issue with locking the files which happened on Windows only and Paint.Net should be able to update the images now.

Please, let me know if you find any bugs with my updates and I hope you enjoy the changes

[Coffee Pancake]

Can this be operated from the command line ?

(trying to automate my workflow)

[Gabriele Graves]

26 minutes ago, Coffee Pancake said:

Can this be operated from the command line ?

(trying to automate my workflow)

Unfortunately no, it's UI only currently.  I'll put it on my list of things to do but I'm not making any promises about when.

[Frionil Fang]

13 hours ago, Gabriele Graves said:

The latest code and builds now watch for changes to the files it has loaded and will reload them automatically when a change is detected, including deletions and renaming.

Thank you!

Sadly the new version crashes (Win 11) when it has some material slots filled in (tested with base color + normal) and you change the associated file. No message or anything, it just hangs for a second or two and closes.

Also re: the file locking, sorry about the confusion. I meant the Other GLTF Packer program this is based on locking files, yours never did which (along with yours having a comfortable UI for me) is why the other one wasn't really an option.

Edit to brainstorm why it crashes: maybe it tries to load the files before the writing is finished? I've seen similar when saving a very large texture from Blender into local files in the viewer: it detects a change and starts loading the file before it's actually been fully rewritten, determines it can no longer be read and stops updating.

Edited June 25 by Frionil Fang

[Gabriele Graves]

Hmmm, that's strange.  On Windows 10 it didn't crash for me doing this but it's possible there's something specific to Windows 11.  I'll take a look and see if I can reproduce the problem.  Did you change the base colour or the normal file when the crash happened?  Presumably both files were 2K PNG files?

Edited June 25 by Gabriele Graves

[Frionil Fang]

31 minutes ago, Gabriele Graves said:

Did you change the base colour or the normal file when the crash happened?  Presumably both files were 2K PNG files?

Working on 1024x1024 .png files, happens both on changing the base and normal map textures. MakeGLTF would detect the change when I hit save in paint.net and then crash in a couple seconds -- it takes only a fraction of a second to save the file so it shouldn't be due to any big delay at least.

Gave it a couple more tests and happens on smaller files as well, as well as the other texture slots. On a *rare* occasion it would not crash on save and instead change the material name to "basecolor.png~<some kind of string that looked like hexadecimal>" instead of just "basecolor" as it normally uses, and possibly lose the thumbnail of the changed texture slot.

 

Edited June 25 by Frionil Fang

[Gabriele Graves]

Thanks, I can see the issue now.  I'm preparing a fix that should be available later.

[Gabriele Graves]

I've updated the repo and recreated the v1.1 builds.   Please test and let me know if this is working for you now.  Thanks.

[Frionil Fang]

28 minutes ago, Gabriele Graves said:

Please test and let me know if this is working for you now. 

Almost works now, no more crashing! The program sometimes gets confused when a file is saved, leaving a .tmp file behind in the directory and and can't update the affected texture slot any longer. If the texture is the base color, it will rename the material to the temp file:

It happens most reliably if you have only the base color populated, but in this case I had base, normal and emission filled in, with base color and emission using the same texture. The emission thumbnail matches the image editor's thumbnail at the top (I was just flipping the gradient colors between saves) but the base color's is gone and the name has changed. Trying to resave the image at this point causes an I/O error in the image editor and changes the material name to the image editor's temp file instead ("testx.png.0.pdnSave").

[Gabriele Graves]

Thank you for your testing and detailed information. I have been looking in to this as well as finding a few other bugs.  I haven't got a fix yet but I'm working on it.  I'll give another update once I have something to share.

[Gabriele Graves]

@Frionil Fang

Update: I wasted a lot of time trying to get the auto-reload feature working and itself was a source of additional issues that I just couldn't fix.  So, I've replaced that with a reload button on the UI.  Much simpler.  Just make sure that the image editing application you are using has finished saving before using it.  It's no biggie if you forget, just press it again once it really is.

I fixed a bunch of other bugs and a couple of UI glitches as well, such as the expanding textbox.

I've updated the builds as well so that v1.1 is now the one with reload and the auto-reload mess is all gone.

Hope this works better for you.  If you are still seeing anything not working properly, please let me know.

[Frionil Fang]

10 hours ago, Gabriele Graves said:

If you are still seeing anything not working properly, please let me know.

Works a-ok like this, thanks for all the effort!

[Gabriele Graves]

I've just uploaded v1.2 which adds command line operation on both Linux and Windows:

makegltf v1.2
Copyright (c) 2024 Graven Hearts

  -b, --alb, --base-colour     Required. Base colour image file location.
  -n, --nrm, --normal          Normal image file location.
  -a, --trn, --alpha           Alpha image file location.
  -o, --occ, --occlusion       Occlusion image file location.
  -r, --rgh, --roughness       Roughness image file location.
  -m, --mtl, --metallic        Metallic image file location.
  -e, --ems, --emission        Emission image file location.
  -t, --mat, --material-name   GLTF material name.
  -h, --help                   Display this help screen.

Providing no options will start the application in UI mode.

The application will attempt to load the other image files from the
base colour file location in the same way the UI does.  This goes
for the generation of the material name as well.  The other options
will act as overrides in this case if specified but are optional.

At mimimum a base colour image, a normal image and a material name
are required.  If these are not picked up automatically from the
base colour image file location then they must be specified.

If you find anything that doesn't work as expected, please let me know and I will fix it.

@Coffee Pancake

[Frionil Fang]

@Gabriele Graves I just found out that the occlusion image is not set up properly.

It is appropriately encoded in the _orm texture, but I hadn't actually double-checked before hitting upload and thought the subtle occlusion textures in my stuff were just not being noticeable: when you upload the .gltf file, the red channel is removed entirely, a cyan-white checkerboard turns into plain white. Uploading the file manually without being a part of the .gltf is fine, so there's something wrong with the .gltf template being used and it instructs the viewer to drop the red channel prior to upload.

I tested by uploading a .gltf from Blender and the occlusion channel is preserved there.

[Frionil Fang]

Okay, I analyzed the differences between the output from MakeGLTF and Blender: MakeGLTF is missing the occlusionTexture node in materials and an associated texture that goes with it. By adding the occlusionTexture, pointing it to texture index 3, and then adding texture index 3 that points to the ORM texture source (file #2) seems to have done the trick.

  "materials": [
    {
      "doubleSided": false,
      "name": "base",
      "normalTexture": {
        "index": 0
      },
      "pbrMetallicRoughness": {
        "baseColorTexture": {
          "index": 1
        },
        "metallicFactor": 0.0,
        "metallicRoughnessTexture": {
          "index": 2
        }
      },
      "occlusionTexture":{
          "index":3
      },
      "metallicFactor": 1.0
    }
  ],
  "textures": [
    {
      "source": 0
    },
    {
      "source": 1
    },
    {
      "source": 2
    },
    {
      "source": 2
    }
  ],

Here's a set of test images for convenience, occlusion/rough/metal:

  

Expected output in upload window, as well as the produced _orm file:

Current output:

 

[Gabriele Graves]

Thanks Frionil, I'll get an update out probably tomorrow sometime.

Edited July 9 by Gabriele Graves

[Gabriele Graves]

@Frionil Fang I've fixed the issue you found and regenerated the v1.2 builds now.  Thanks very much for testing and reporting the issues.  I really appreciate your help.

Edited July 10 by Gabriele Graves
spelling

[Frionil Fang]

Thank you for providing the tool, it's invaluable for someone like me who likes to just tinker with general-purpose raw textures.

[Frionil Fang]

Sorry I'm a bit buzzed and just gotta gush over how pleasant looking things you can make just by manually crafting tiling PBR textures without professional tools.

Mostly just layers of filtered tiling simplex noise (I wrote the plugin for paint.net myself, just for this purpose!), put on 3 separate old pieces of mesh that were never meant to work together (and not even on this old body I have!), with completely unique UV maps that weren't meant for tiling textures, and... still pretty solid looking gold boots. When PBR works, it sure does work, glad to have things like this program that facilitate the manual fooling around without needing to bake things in Blender or commercial tools.

[Gabriele Graves]

I've also been using PBR materials to modify existing items, both clothing and land items.  I just love the way how easy it is to give existing items a more convincing textured look.  I'm not a mesher and probably never will be but nevertheless, I think the recent changes have been a "game" changer for me.

[Nyx Onyx]

Hello @Gabriele Graves! I was just recommended to try your program (I'm a Windows user). Specifically because I could then do a batch-job with the CLI. But that will then create a bunch of GLTF:s, when what I actually need is several materials bundled into one file. Now I haven't tested in a while, but I don't think the SL Viewer, nor Firestorm, allow bulk-uploads of Material assets, but they do support uploading of multi-material GLTF/GLB, so it would be a great thing to have! I'm not sure how easy or difficult it would be to make this automatically detected (which files should be in which Material) based on filenames, but perhaps a start would be to allow for defining several materials through the CLI? Also, another way to accomplish it would be to allow for appending a GLTF with more materials. This could go with a switch to fail if a Material name already exists, or update it. One could then create one's own script for interacting with the program, such as detecting UDIM-numbered image files and execute your program with each set. What do you think? Thank you so much!