Hi all,
My question is the same as in my old post but it automatically closed - Adding your own material to the existing Omniverse materials library - #4
I exported the material by right clicking and selecting Export to .mdl to my Nucleus server location and the I added its folder as new collection.
But after re-importing it back to the scene it doesn’t work.
btw I can’t upload the screenshot, it says ony woff,pdf, docs files are accepted.
I just tried it here and it successfully added the custom folder. However it does appear blank until you refresh the materials browser. That is a bug. For me, I had to restart the app, and there were my custom materials in the custom folder I added. I will report the bug. Thanks
Hi @Richard3D thanks for a quick reply. I can see the added materials but when I apply it to the object it is missing all the maps…I wanted to make screen recording but suddenly I cannot upload any pictures / videos here, not sure what happened…
@karol.osinski from my previous tests a while back, i’ve had issues related to how the sub-identifier initializes when bringing MDLs back in through the material browser.
for the sake of this convo, if you’ve exported MDLs from any OmniPBR/SimPBR and bind them to other prims via the browser, you would probably end up with a red shader. when this happens, try to traverse down the stack of your material and find the shader prim. this is where you will quickly notice the sub-identifier field setting displaying as “not found” as seen below:
the way to get around it is to click on the drop down and pick the first option that’s available to you; and it’ll either be OmniPBR or SimPBR. once this was set correctly, you should see the missing textures pop up again. that said, the same MDL dragged from content browser seems to work fine out of the gate.
what about other types of materials? when i tried exporting UsdPreviewSurfaces into MDLs, i never had any luck recovering the textures because associated prim (UsdUVTexture) connections would’ve gotten lost during the export process despite the textures being exported along with the MDL.
so i have been assigning materials via the content browser these days in the interim (and when needed, using the ‘material’ filter to limit the array of items visible). it could be a bug but can’t say for certain. there were other bugs i’ve ran into when using the material browser, but will probably post it with a new thread instead.
Hi @Richard3D , Hi @Simplychenable, thanks for your input!
When exporting the new material its shader changes from original OmniSurfaceLite.mdl to the new one automatically created during the export, for example MARBLE_CALACATTA_EXPORT.mdl , I don’t know what is the point of that.
During the export, all the material’s textures are copied to its folder, also their paths are changing… it is creating a lot of redunancy and messing up the folders structure.
i have always seen the exporter pushing out textures to the location of the MDL file, so i believe it’s by design. in a way, it’s the easiest way to make sure you don’t lose track of where the textures are since it’ll always be found where you exported the MDL. you could write your own extension to export textures to an alternative location, but that’ll certainly be a separate effort.
regarding how shaders change at the time of the export, i haven’t experienced it yet (maybe because i haven’t checked after export every single time). but i could confirm that the resulting MDL would have its related assets be repathed to where the new textures are. that’s partially why i often have to use the USD Paths extension in conjunction. perhaps Richard could shed some light on this.
This is normal expected behavior by design yes. If you are exporting an mdl to a new library and folder location, all associated textures will also be copied and repathed automatically. I cannot think of a time you would want to export an mdl and leave behind the critical textures. Either export a new mdl with new textures and paths, or create your mdl library and mdls where your texture library already exists and nothing will need to get moved. The mdl must live locally with the textures, unless you want to manually repath everything back.
I would stick to the main shaders like OmniPBR and OmniSurface
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
