Tested in Omniverse 107.3,110 and Isaac sim 5.1
Bottom object is a mesh containing 4 materials. It imports into omniverse correctly.
Top object is an animated mesh containing the same 4 materials. It imports with all materials as the first material instead.
The tea_a model imports correctly into all other applications (Blender, 3ds max, online usd viewers)
We suspect this is an Omniverse bug
See attached files for replication
animated_model_materials_broken.zip (219.7 KB)
Hi and thanks for posting. I will download and look into this.
Were you able to confirm this visual bug?
Our team has done more investigating and we are unsure if this is a 3dsmax exporter issue causing this bug or if it is omniverse’s rendering system. It is just strange that other applications are able to render the materials correctly from the same 3dxmax exported usd file.
I can escalate this into the enterprise support portal if it would help as it is impacting client work.
Hi there. Yes I have run some extensive tests. I am happy to report, that this is a bug I can detect with the Autodesk 2026 USD Exporter. In fact I am seeing several bugs with it. I have attached some test files here. You can see a max file for a simple cube and in the material editor is both a single material and a multi material for testing. Also you will see 4 files, two fbxs, two usds, each for single and multi material.
The first test you must always do, is self re-import. This is crucial. If you cannot successfully self-reimport, you have no need to test further in other software. So take these four files and reimport into a fresh 3dsmax scene. You can see that the FBX versions work perfectly for both animation and for multi materials. However, the USD files, not only do not work for multi materials, but they have a really bad keyframe animation glitch.
So I will investigate further but it looks like this is an issue with Autodesk’s USD Exporter. For now your work around is to just use FBX, which is totally fine. You do not need to use USD.
Here are the files
test.zip (62.7 KB)
If you are Enterprise you should still run this up to them as well. What company are you with?
I will let our technical art team know that the bug is within Autodesk’s exporter as I am the lead developer on the technical side of Omniverse for Kinetic Vision.
I will also create a case in the Nvidia portal for visibility. We will also report the bug to Autodesk though our technical support with them as well.
Thanks again for the help!
Great thanks. Check out the files and get back to me.
We also see the same issues with the example files you provided. We do need to stick to usd files as that is the file type our Client requires currently.
I reviewed the corrupt usda files and was able to create a python script that fixed models with varying success.
It looks like the 3ds max exporter corrupts time sample animation data that then happens to cause materials/shaders not to load correctly in some render engines.
Incorrect indices
And missing “MaterialBindingAPI” line
We did create a ticket with Autodesk for a fix to the exporter but in the mean time using the built in Omniverse usd validator’s animation samples fix converts the time sample data and fixes the corrupt files for both usd and usda files.
Autodesk has confirmed it is a bug in their exporter and a fix will be available in a future release.
I just wanted to clarify something you said. “Our client requires USD files”. Files are files and can be converted back and forth, no problem. If you can export to fbx, you only need to convert it to usd with kit, which happens automatically when you import it without using “reference”. It will just auto convert it to usd. They you simply can use that usd file moving forward. So whether you export as usd or export as usd via fbx, makes totally no difference to kit. They are both crushed meshed model with mdl materials.
Therefore, please move forward with fbx export from 3dsmax, and import into kit, which will auto-convert it to a usd file, which you can save. Same exact thing.
