Maya Exporter: Map AO to UV2


Is it possible to map the Ambient Occlusion texture to UV channel 2 using the Maya Babylon GLTF exporter?

We want Base Color, Normal, Roughness and Metallic to tile across the surface using UV1 and to apply a unwrapped, non-overlapping AO map using UV2.

There doesn´t seem to be any information on how to do this in the documentation, and when I switch to the Stingray PBS shader to set up the materials, assigning the AO texture to UV2 using the relationship editor is disabled.

cc @PatrickRyan

@psqv, the stingray shader in Maya has been long deprecated, but I am also seeing your issue in Maya 2023. If you are using an Arnold Standard Surface material, you can use the Relationship Editor to link textures to UV sets, but it appears that Stingray materials are either bugged or have been deprecated from working with the relationship editor. There is a work-around, however, and you can do it one of two ways.

If you export your scene as a glb and load into Babylon, you can simply assign the loaded AO texture to the correct UV set by using Texture.coordinatesIndex. Simply query the ambient texture from the PBRMaterial of your asset and set the coordinatesIndex to the correct UV set. This would likely be 1 if you have two UV sets and are using the second UV set for the AO.

If you need to supply the glb without wanting to change the UV set on the texture in code, there is a second way to do this. You will want to export the asset as a glTF file, not a glb, so that you have access to the json for the glTF. Open that glTF file in VSCode and you are looking for the texCoords of the material using your AO map. Simply set the texCoord parameter to 1 (again for the second set) like this:


You will want to look for the materials within the file and then look for the material in question by name. Then just add the texCoord parameter as you see above. This will tell the texture to use the second UV set. Then the only thing left would be to compress to a glb if you want. You can use this tool written by one of our engineers to compress the glTF to a glb.

I hope this unblocks you, but feel free to ping back with questions.

Thanks for the quick reply @PatrickRyan :slight_smile:

As this will be an automated serverside process, I think we will write a python script that monitors the folder where the .gltf file is output, add the “texCoord”: 1 parameter and then pack it all up as a .glb file.

Another option would be to fork the BabylonJS maya exporter and adjust the exporter code to read the UV set value for occlusionTexture and set this parameter correctly in the gltf/glb file on export. Do you think that would be feasible as well?

@psqv, I think either option is a valid path as the exporter is open source and we encourage users to make it fit their needs if able. The one footnote here is that we are no longer actively developing the Autodesk glTF exporters as we know that Autodesk has native glTF support in their roadmap and we decided to point our limited resources in another direction. While forking and modifying, and even contributing back to the exporter repo would be great, I worry that if Autodesk comes out with a better export pipeline your efforts toward automation may be wasted.

Knowing that the future of the export process in Maya may change, it seems to me that the path that offers the most benefit long term would be the infrastructure to monitor written glTF files as there may be some other need to update a glTF file in the future, while I expect our exporter to be deprecated at some point. I don’t know when that point is, however, so this is a bit of a guessing game for the cost/benefit analysis.