{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibetu5ca3fakrehk5gu5qqkvurdtbkjmefloililrbq5k537zgl2a",
    "uri": "at://did:plc:dxjzgxe7cvirxkwfjr2tjspt/app.bsky.feed.post/3milcn5wrkvh2"
  },
  "path": "/t/adding-full-support-for-custom-materials-to-gltfloader/49444#post_4",
  "publishedAt": "2026-04-01T22:29:19.000Z",
  "site": "https://hub.jmonkeyengine.org",
  "textContent": "theMinka:\n\n> Btw, `GltfLoader` already has some public configuration methods (e.g. `registerExtension(...)` and `registerDefaultExtrasLoader(...)`) that are practically inaccessible.\n\nYeah, those are static because they have to be available at loader instantiation time.\n\n\n        public static void registerExtension(String name, Class<? extends ExtensionLoader> ext) {\n\n\nAnd that’s how unlit materials are handled.\n\ntheMinka:\n\n> Custom materials should be completely independent from jME3’s standard materials. This means they can use different material definitions and parameters.\n\nIf this is just about loading a regular GLTF with a different material then I think the only way would be to replace the existing GltfLoader with your own (which could be a subclass if you want most of the behavior and then override createMaterial()).\n\nElse there would have to be something about the gltf file that signaled the customization… or you’d pass it in the AssetKey (which could also be custom) if it needs to be something set per model.",
  "title": "Adding full support for custom materials to GltfLoader"
}