Hi all,
I have an issue of sharing scenes with my collegues, the Nucleus library is installed on shared network but whenever someones who’s local user name is different then my he is missing the material’s shaders because the path is pointing to my local machine with different user name.
In order to avoid this issue, I had to copy all the base .mdl from
C:\Users\s20m\AppData\Local\ov\pkg\create-2023.1.1\kit\mdl\core\Base
to the location on our Nucleus server and manually change the path of every new material…this is far from efficient, is there any way to “force” all newly created materials to point to the shader Nucleus server?
Thanks,
Karol
@karol.osinski i, too, wonder if that’s feasible after looking at the code over the weekend (the closest i came to it was the material_library.py and has something to do with os.path.basename). but, now that you have made a dup of the base MDL’s, i suppose you could drag them from the shared nucleus server into your stage rather than going through the create menu to add materials? that way, the new materials will be pulled from the nucleus server as opposed to your local installation directory from the get-go. it’s not as convenient but could be a workaround.
the other thing to consider is to not put the dups under a specific user’s profile folder unless you are okay having your colleagues accessing to your folder.
Hi @Simplychenable, thanks for tour answer, the direct drag from the library workaround is indeef faster but most of the time what I am doing is I “Select bound objects” with an old material and I create new one from the menu…
yea, what i suggested is mostly for new materials and not so much for modifying old assets paths. not too sure how select bound objects plays into this, though. isn’t it just to get the mesh prim selection from a material prim?
unfortunately the USD Paths extension doesn’t seem to allow you to alter the core base MDL paths either. at least not without using Collect Asset in conjunction (?), which might’ve come in handy. have you been manually repathing the asset or doing it via python scripting?
I will check on the official correct workflow
1 Like
I repath the .mdl manually every time after I create new material, made a bookmark to fast access the folder with all Base materials, not very efficient method I know haha
I have talked to the material experts and they are confused. I think it is related to your opening statement “the Nucleus library is installed on shared network”. First of all, it should not be. That is not how it is designed unless you have Enterprise.
Second, all of those base materials, mdls are CORE, and therefore everyone has them. The program should automatically use the equivalent local resource version in their user folder. I think the fact that you are trying to override the “relative” path to an “absolute” path, it causing issues. Only the added mdls, beyond the base library need to be shared if they are created locally. Using the collect tool will collect those. Again the base materials are not required to be included. In fact you can see in the properties panel, the Omnisurfacelite.mdl has no actual path. It is just the name. We leave it pathless on purpose so it auto finds the equivalent core material on the other person’s local machine.
1 Like
You can see from this basic new scene, that the two materials I created are “pathless”, which is designed that way
The way we reference mdls is with four levels…
material.mdl = Application Core material
./material.mdl = Relative path to loading Usd file
c:/materials/material.mdl = Absolute path
https://amazon.s3.com/materials/material.mdl = Server path
1 Like
Thank you very much for a detailed explained Richard!
However, I have noticed that if another machine does not have the exact version of USD Composer installed then the .mdls are missing causing the “RED” materials in the scene, as the path, even if it seems pathless in the properties window it points to :
C:\Users\s20m\AppData\Local\ov\pkg\create-2023.1.1\kit\mdl\core
if my collegue has another version installed and opens my scene, his paths are pointing to create-2023.2.0 for example.
I know you were having installation issues before for the new 2023.2.0 version. Can you please try to update to the new 2023.2.1. Then try that and we can take another look.
