Reuse textures from GLTF while generating USDZ

[gopikrishnachaganti]

@kcoley observed that the textures(png/jpg) are regenerated while building usdc/usdz. saw some specific things like RGBA and Occlusion textures generated. Can we reuse the existing textures which can commonly work for GLTF and USDC(USDZ) as well? i mean not generating any new textures separately. Can you please clarify?

[kcoley]

Hi @gopikrishnachaganti . Currently textures are copied over from the source location to the output directory, unless the texture is already in the output directory.

Regeneration occurs when using Metallic Roughness textures, as the RGB channels would have to split into separate grayscale textures for ARQuicklook to work. Also, if your source texture has alpha values but the glTF is set to opaque, a new texture is generated with the prefix RGB which strips the alpha channel, based on this PR (https://github.com/kcoley/gltf2usd/issues/95).

Are you wanting a way to keep the original paths of the textures without copying to the output directory?

[gopikrishnachaganti]

@kcoley yeah, got it Kacey! the whole problem is, even though my textures (which are used by my gltf) are very less in size, the final USDZ is really big. it would be great if USDZ can reuse the same textures. if this is not possible, can you please compress the textures (in png) while generating USDZ? or is there any way to generate USDZ from USDC with textures?

[gopikrishnachaganti]

@kcoley here is what i am doing. creating usda with textures first, then compressing the textures without loosing the quality(lossless) and then converting usda into usdz using usdzip. this should be good.

[kcoley]

@gopikrishnachaganti I added an --optimize-textures option to gltf2usd which, when enabled, will attempt to reduce the texture size using PIL (https://pillow.readthedocs.io/en/4.1.x/handbook/image-file-formats.html#saving) at the expense of longer export time.

Would this work for you?

[gopikrishnachaganti]

@kcoley tested with --optimize-textures, here is my observation : but there were little changes to texture files in size where some are more than normal and some are less. ideally overall size of the usdz file did not change. i see in the code the flag optimize-textures is enabled and sent as an additional argument to img.save (img.save(self._image_path, optimize=self._optimize_textures)) method, but compression did not happen at all. for some of the textures, its more than original size. Can you please look into this asap?

And if i generate usdc first and then all textures and generate usdz with compressed textures, the quality of usdz is very bad. i dont think so that approach would be ideal.

[gopikrishnachaganti]

@kcoley also can we try with compress_level instead of optimize with PIL? looks like 0 to 9 compression is there with compress_level.

[wave-electron]

@gopikrishnachaganti @kcoley Yes. What you can do is, use xcrun usdz_converter after creating a usda file with the gltf2usd script

But if you have multiple meshes you first find out the mesh names to know which materials apply to which part of the model.

You can this manually by running -v (verbose) handle and looking at the material assignments in the file usda.

xcrun usdz_converter myfile.usda myfile.usdz -v

After finding the material assignments - you can do this type of command

xcrun usdz_converter myfile.usda myfile.usdz -m pbrmaterial_0 -color_map customtexture.png -metallic_map customtexturemetallic.png -roughness_map customtextureroughness.png -m pbrmaterial_1 -color_map customtexture2.png etc

[wave-electron]

@gopikrishnachaganti My command line example was missing -normal_map, emissive_map etc . Just check the usdz_converter using the -h handle for the complete procedure.

[gopikrishnachaganti]

USDZ needs metalness, roughness & occlusion textures in grayscale. when i compressed the textures they converted into indexed mode instead of grayscale. i changed those conversion mode. now it looks good. but if the bin file is heavy, obviously usdc is getting heavier. closing this request for now. thanks @kcoley for your support.