Incomplete Texture Embedding in usd2gltf: Only One of Two Textures Processed

[MadeByDouglas]

Ok so I'm trying to convert pretty simple models that have two images attached as textures, but it seems one of them is being lost so the conversion uses one image for both sides. Below is Claude's summary of the situation.

Bug Summary

The usd2gltf library is only embedding one texture (texgen_0.png) instead of both available textures
(texgen_0.png and texgen_1.png) when converting USDZ files to GLB format. This results in incomplete
material conversion where multiple materials that should have distinct textures end up sharing the same
texture.

Expected vs Actual Behavior

Expected: Both texgen_0.png and texgen_1.png should be embedded in the GLB file and assigned to their
respective materials (Material_0 and Material_2).

Actual: Only texgen_0.png is embedded and processed, while texgen_1.png is ignored during conversion.

Technical Analysis

USDZ File Structure

The source USDZ contains both texture files:
Archive: test.usdz
Length Date Time Name

---

  40879  08-30-2025 17:51   model.usdc
3177081  08-30-2025 17:51   0/texgen_1.png  ← Missing from GLB output
2923317  08-30-2025 17:51   0/texgen_0.png  ← Successfully embedded

Debug Output Analysis

The conversion process correctly identifies multiple materials with texture references:

DEBUG:usd2gltf.converters.usd_material: - material[0]: /model/Materials/Material_0 : Material_0
DEBUG:usd2gltf.converters.usd_material: - diffuse: TextureInfo(extensions={}, extras=None, index=0,
texCoord=0)

DEBUG:usd2gltf.converters.usd_material: - material[1]: /model/Materials/Material_1 : Material_1
DEBUG:usd2gltf.converters.usd_material: - diffuse: (0.8509804, 0.84705883, 0.80784315)

DEBUG:usd2gltf.converters.usd_material: - material[2]: /model/Materials/Material_2 : Material_2
DEBUG:usd2gltf.converters.usd_material: - diffuse: TextureInfo(extensions={}, extras=None, index=1,
texCoord=0)

Key observations:

• Material_0 has diffuse: TextureInfo(..., index=0, ...)
• Material_2 has diffuse: TextureInfo(..., index=1, ...)
• Both materials reference different texture indices (0 and 1)
• Both materials have diffuseColor_texture primitives detected

Texture Embedding Issue

However, only one texture is actually embedded:
DEBUG:usd2gltf.converter:Embeded res: FileResource("texgen_0.png")
DEBUG:usd2gltf.converter:Embeded res: FileResource("debug-analysis_geometry.bin")

Missing: No embedding log for texgen_1.png despite Material_2 referencing index=1.

Material Binding Warnings

The conversion process generates numerous warnings about MaterialBindingAPI:
Warning: in BindingsAtPrim at line 671 of
/Users/runner/work/OpenUSD/OpenUSD/pxr/usd/usdShade/materialBindingAPI.cpp -- Found material bindings
on prim at path (/model/Geom/Node_0/Material_0_meshGroup) but MaterialBindingAPI is not applied on the
prim

This suggests potential issues with how the library handles material binding relationships in USDZ
files.

Reproduction Steps

1. Create or obtain a USDZ file with multiple materials using different textures
2. Run conversion: usd2gltf -i test.usdz -o output.glb --debug
3. Observe debug output showing multiple materials with different texture indices
4. Check embedded resources - only first texture is processed

Environment

• usd2gltf version: 0.3.5
• Python: 3.11
• Platform: macOS
• Source: USDZ files with multiple PNG textures

Impact

This bug affects any USDZ file with multiple textured materials, resulting in:

• Incorrect visual appearance (duplicate textures instead of distinct ones)
• Loss of material variety and detail
• Incomplete asset conversion

Suggested Investigation Areas

1. Texture indexing logic: The code correctly identifies TextureInfo(..., index=1, ...) but may not be
   processing texture index 1
2. File resource handling: The embedding process may have a limitation in processing multiple texture
   files from the USDZ archive
3. Material binding: The MaterialBindingAPI warnings suggest potential issues with how materials are
   connected to their textures

Related Issues

This appears connected to existing texture processing issues:

• Skipping texture processing as converter.dirname is empty or invalid #12: "Skipping texture processing as converter.dirname is empty or invalid"
• Getting error in handle_texture #9: "Getting error in handle_texture"

Both suggest ongoing challenges with texture handling in the conversion pipeline.